Trabajando con Git de forma local

Podemos usar Git en nuestro sistema, sin necesidad de enviar los cambios a la nube. Esto nos permitirá empezar a trabajar con Git, conocer algunos conceptos nuevos y, al menos, poder versionar los cambios que hacemos localmente.

En este capítulo vas a aprender a iniciar un proyecto desde cero en tu máquina y nos vamos a enfocar en las tres primeras etapas de un proyecto de Git:

El directorio de trabajo, el área temporal transitoria y el repositorio local está todo en nuestra máquina y son las primeras etapas en Git

Si quieres crear un proyecto desde cero (dicho de otra forma, crear un repositorio local), puedes usar el comando git inite indicarle el nombre del proyecto. Esto creará una carpeta configurada y vacía con el nombre que le has indicado.

$ git init nuevo-proyecto
$ cdnuevo-proyecto

Es posible que quieras iniciar un repositorio de una carpeta ya existente. Para ello, simplemente puedes usar el comando git initdentro de la raíz del directorio del proyecto.

$ cd<directorio del proyecto que ya existe>
$ git init

Verás que en cualquiera de los dos casos te ha creado una rama principal por defecto (a día de hoymasteraunque esto se está discutiendo y es posible que pronto pase a llamarsemainpor defecto). Esta rama es la rama principal de tu proyecto y es la que se usará para trabajar.

Si quieres que al crear un repositorio, la rama principal tenga otro nombre, puedes usar el parámetro—initial-branchpara indicar el nombre de la rama que te gustaría usar.git init nuevo-proyecto —initial-branch=main. También puedes cambiar la configuracióninit.defaultBranchpara cambiar el nombre de la rama principal que se usa por defecto.

A partir de aquí ya tienes tu repositorio inicializado. Eso sí, sólo de forma local. Para revisar que todo ha ido bien puedes comprobar que existe el directorio.git dentro de nuestro proyecto. Para ello, en sistemas Unix, podéis usarls -alodiren Windows.

$ ls -a

. assets layouts resources
LICENSE content package.json static
.git README.md public vercel.json

En este directorio es donde git va a guardar toda la información de tu proyecto. Todos los archivos, histórico de cambios, bifurcaciones y más.

Importante: No borres nunca el directorio.gitde tu proyecto. Si lo borras, no podrás acceder a los datos del repositorio y podrías perder todo lo que hayas hecho. Al menos, asegúrate siempre de haber sincronizado todos los cambios y ramas que te interesen con un repositorio remoto (git push) antes de borrarlo… si no quieres perder nada.

Otra forma sencilla de saber si el proyecto actual tiene un repositorio inicializado correctamente es ejecutar el comando git statusen el directorio del proyecto.

# en un directorio que no contiene un repositorio:
git status

fatal: not a git repository(or any of the parent directories): .git

# en un directorio que contiene un repositorio:
git status

On branch main

No commits yet

nothing to commit (create/copy files and use "git add "to track)

¿Qué es el directorio de trabajo?

El directorio de trabajo es simplemente la carpeta de tu sistema de archivos donde tienes todos los ficheros de tu proyecto y en el que has iniciado tu repositorio. Esto es, el directorio que contiene los archivos que has creado o crearás y que han sido modificados.

El directorio de trabajo es la primera etapa en el ciclo de desarrollo de Git

Sitúate en el directorio en el que iniciaste previamente tu repositorio. Ejecuta git statuspara asegurarte que te encuentras en el directorio correcto.

Ahora, crea un archivo en tu directorio de trabajo. Para ello, puedes usar tu editor favorito o, simplemente, puedes utilizar el comando:

$ touch index.html

Con esto, has creado un archivo en el directorio de trabajo. Si vuelves a ejecutar el comando git statusverás que Git te indicará que el archivoindex.htmlno está siendo rastreado.

On branch main

No commits yet

Untracked files:
(use "git add <file>..." to include in what will be committed)
index.html

nothing added to commit but untracked files present
(use "git add "to track)

Con esto, lo que hemos conseguido es dejar nuestro archivoindex.htmlen el estado demodificado.

¿Te parece que git statuses demasiado verboso? No te preocupes, puedes reducir la información que muestra con el comando git status -s. El parámetro-ses la forma corta de usar la opción—shorty hace que la salida del comando se simplifique considerablemente.

$ git status -s
M manuscript/changelog.md
M manuscript/ramas.md
M manuscript/ssh.md

¿Cómo deshacer un archivo modificado?

Acabas de modificar un fichero y te das cuenta quequieres volver a la versión originalqueteníaseneldirectoriodetrabajo. Lo que tendrás que hacer dependerá del estado previo de ese archivo en el directorio de trabajo:

Si has modificado un archivo o directorio que ya había sido
_commiteado_ anteriormente...

Esto significa que has introducido una modificación sobre un archivo que ya había sido grabado en el repositorio previamente con git commit(que más adelante veremos cómo usar).

En ese caso puedes restaurar la versión previa de ese fichero usando el comando git restore:

# restaurar el archivo index.html
$ git restore index.html

# restaurar todo el directorio de trabajo
$ git restore.

# restaurar todos los archivos terminados en *.js
$ git restore '*.js'

¡Ten en cuenta que esto hará que pierdas los cambios que habías realizado en el archivo!

Si intentas ejecutar este comando en un archivo que no había sido grabado con un commit, te encontrarás un error como este:

# creamos un fichero new.html
$ touch new.html
# intentamos restaurar el fichero new.html
$ git restore new.html
error: pathspec 'new.html' did not match any file(s) known to git

Este error es normal, ya que git restoreno puede, obviamente, restaurar un archivo que no existía antes. Para saber cómo puedes deshacerte de un archivo modificado, consulta la siguiente sección.

No te preocupes si todavía no sabes qué es un commit. Más adelante veremos qué significa y cómo hacerlo.

git restorees un comando relativamente nuevo, disponible a partir de la versión de Git 2.23. A día de hoy es la forma recomendable de realizar esta operación pero es posible que todavía no lo tengas disponible. Lo sabrás inmediatamente si ves este mensaje:

git:'restore' is not a git command. See 'git --help'

No te preocupes si es así. Históricamente, para lograr esto mismo, se ha usado git checkoutpero es un comando que hace demasiadas cosas y te puede generar confusión.

Igualmente, en el caso que no tengas disponible git restorete explico cómo puedes lograrlo con git checkout:

# restaurar el archivo styles.css
$ git checkout -- styles.css

# restaurar todos los archivos markdown
$ git checkout -- '*.md'

# restaurar todo el directorio de trabajo
$ git checkout.

Si el archivo o directorio no existía previamente…

Esto significa que queremoslimpiarlo que hemos creado. Una opción sería simplemente borrar manualmente lo que hayas creado pero Git tiene un comando que puede ayudarte.

El comando es git cleany nos permite borrar todos los archivos que todavía no han sido rastreados por Git.

Si ejecutas el comando tal cuál verás que te da un error:

$ git clean
fatal: clean.requireForce defaults to trueand neither -i, -n, nor -f
given;refusing to clean

Vamos a ver lo que nos ofrecen las opciones:

-npara ejecutar undry-run. Esto hará que se ejecute el comando y te diga cuál sería el resultado de borrar los archivos… ¡sin borrarlos! - -fforzar el borrado de los archivos. - -dpara borrar también directorios que no existían antes. - -ipara que te pregunte antes de borrar cada archivo.

Un ejemplo de uso para un fichero que hemos creado en el directorio de trabajo y luego nos damos cuenta que queremos eliminar.

# creamos un fichero en el directorio de trabajo
$ touch nuevo-archivo.js
# ejecutamos git clean con el parámetro -n
$ git clean -n
Would remove nuevo-archivo.js
# ahora que ya sabemos lo que borraría, lo hacemos
$ git clean -f

¿Cómo añadimos archivos al área de staging?

El área de staging es un área temporal transitoria donde podemos mover los archivos modificadosde nuestro directorio de trabajo al estado depreparados. Desde este estado, más adelante, los podremos pasar aconfirmadosy quedarán grabados en el repositorio.

Se llama también Área Temporal, ya que es un estado transitorio por el que pasan los archivos que, más adelante, vamos a querer grabar en el repositorio local

Para lograr el movimiento, tendremos que ejecutar el siguiente comando:

$ git add <archivos>

Esto añadirá los archivos indicados al área de staging. Si quieres añadir más de un fichero, puedes usar una lista de archivos separados por espacio o incluso puedes usar algunos patrones para indicar extensiones o directorios. Aquí tienes algunos ejemplos para que veas cómo lo podrías usar.

# el archivo que hemos creado anteriormente
$ git add index.html

# añade los archivos archivo1.js y archivo2.js
$ git add archivo1.js archivo2.js

También puedes añadir todos los ficheros que terminen con una extensión en
concreto:

# añade todos los archivos que terminen en .js
$ git add *.js

# añade todos los archivos que terminen en .html
$ git add *.html

O directamente añadir todos los ficheros modificados:

$ git add --all
$ git add -A

# si estás en la raíz de directorio de trabajo
$ git add.

# todos los ficheros modificados de la carpeta "resources"
$ git add resources/

Si intentas mover a este estado un archivo que no existe, recibirás un error como el siguiente:

$ git add archivo-que-no-existe.md

fatal: pathspec 'archivo-que-no-existe.md' did not match any files

Recuerde que cada vez que añadas algo alárea de staging, puedes usar git status para comprobar qué archivos están ahí y en qué estado se encuentra cada uno.

¿Cómo puedo sacar un archivo o varios del área de staging?

Es posible que hayas añadido algún archivo al área de staging pero en realidad no quieras grabarlo en el repositorio. Existe un comando que te permite volver del estado depreparadoamodificadouno o varios ficheros.

Vamos a ver un ejemplo completo:

# añadimos el archivo index.html y

$ git add index.html
$ git status
On branch main

No commits yet

Changes to be committed: (use “git rm —cached …“to unstage) new file: index.html

¡Oh no! Hemos añadido el ficheroindex.htmlpero en realidad no queremos que se grabe en el repositorio. Para sacar este fichero tienes que ejecutar el comando git resetde la siguiente forma:

$ git reset index.html

Ahora, si ejecutamos un git statusveremos que el ficheroindex.htmlha quedado en el estado demodificadoy ha salido del área de staging.

On branch main

No commits yet

Untracked files:
(use "git add <file>..." to include in what will be committed)
index.html

nothing added to commit but untracked files present
(use "git add "to track)

Como ves, para usar git resethay que indicar el fichero.

git reset <archivo>

Por ejemplo:

git reset archivo2.js

¿Qué es un commit?

Los commits sirven para registrar los cambios que se han producido en el repositorio. Es una de las piezas más importantes para entender cómo funciona Git.

Piensa en los commits como si fuesen fotografías. Cada fotografía muestra el estado de todos los archivos de tu repositorio en el momento en que se hizo y cada una va firmada con elautor, lafecha, localizacióny otra información útil.

Siguiendo con la analogía, si hicieses más fotos, al final tendrías unálbum de fotos que te contaría la evolución de un viaje o cualquier acontecimiento que estabas registrando con tu cámara.

Esteálbumseríaelhistorialdecambiosdelrepositorio, que te permitiría entender qué hizo cadacommity en qué estado se encontraba el repositorio entonces.

El área de staging sería el encuadre, el commit la fotografía y, para guardarla, el repositorio escanearía la foto para replicarla

Es muy importante que entiendas quecada commit es una fotografía de todo tu repositorio, no sólo de las diferencias que hay entre los archivos que has modificado.

¿Cómo puedo hacer un commit?

Si quieresguardar los cambios que tienes en el área de staging, puedes hacer un commit con el siguiente comando:

$ git commit

Esto creará un nuevo commit en tu repositorio y añadirá una referencia al commit en la rama en la que estás trabajando. Pero antes de hacerlo, tienes que indicar el mensaje del commit. Para ello te abrirá el editor que hayas configurado previamente.

Si quieres añadir directamente un mensaje sin abrir el editor, puedes usar el parámetro-mo—message:

$ git commit -m "Add new search feature"

El mensaje especificado se usará como título del commit para describir los cambios realizados. Si quieres añadir más información a tu commit, más parecido a lo que podías hacer al abrir el editor del mensaje de commit sin parámetro, puedes volver a utilizar el parámetro-mtantas veces como quieras.

$ git commit -m "Add new search feature "-m "This new feature is awesome. Make the search to work faster and better!"

En el capítulo deBuenas prácticas, verás diferentes reglas que puedes seguir para escribir los mejores mensajes de commit posible.

Ahora, es importante que entiendas queestos cambios se van a grabar en tu repositorio local. A partir de aquí, para deshacer estos cambios, tendrás que revertirlos grabando un nuevo commit en el historial de cambios del repositorio.

Una vez hemos confirmado los cambios, éstos se quedan grabados en el repositorio local

¡Recuerda! Hasta ahora estamos trabajando a nivel local y, por lo tanto, estos cambios sólo se quedan disponibles en nuestra máquina. Más adelante veremos cómo podemos enviar estos cambios a la nube para que otras personas puedan recuperarlos y trabajar sobre ellos.

Haz commit y sáltate el área de staging

El proceso natural en Git es que los archivos que has modificado, y quieres que sean grabados en el repositorio, deben estar en el área de staging, tal y como hemos visto antes.

Sin embargo, puedes saltarte directamente la etapa de staging y hacer un commit directamente con los ficheros que han sido modificados.

Para ello, puedes usar git commitpero con el parámetro-ao—all. De esta forma, Git preparará automáticamente todos los ficheros que hayas modificado y los añadirá al commit.

# vemos que tenemos un archivo modificado
$ git status
On branch master
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git checkout -- <file>... "to discard changes in working direct
ory)

modified: CONTRIBUTING.md

no changes added to commit (use "git add "and/or "git commit -a ")

# creamos un commit con los ficheros que hemos modificado

$ git commit -a -m 'Add new files without staging'

[master ad3385f]Add new files without staging
1 file changed, 5 insertions(+), 0 deletions(-)

# también puedes agrupar los parámetros del comando

$ git commit -am 'Add other files without staging'

[master bb2235d]Add changes without staging
1 file changed, 1 insertions(+), 0 deletions(-)

Ten en cuenta queestosólofuncionaparaarchivosmodificados. Si es la primera vez que los has creado, vas a tener que añadirlos manualmente al área de staging con git addantes de poder usar git commit.

¿Qué es el HEAD?

HEADes el puntero que referencia el punto actual del historial de cambios del repositorio en el que estás trabajando.

Normalmente será el últimocommitde la rama en la que te encuentres pero como
también puedes moverte entre commits... es posible que HEADno sea el último
commit.

¿Y por qué se llama HEAD? Como cada cambio que se graba en el repositorio se identifica con unhash, del que hablaremos más adelante, sería muy complicado referirte a un commit concreto para situarte.

Imagina que puedes viajar en el tiempo y en el espacio. Pues el HEADsería la referencia que siempre apunta al punto en el que estás, independientemente de dónde y cuándo te encuentres.

Puedes saber el valor deHEADcon el comando git symbolic-ref HEAD:

$ git symbolic-ref HEAD
refs/heads/main

Otra forma de acceder a él sería mirando el contenido del archivo.git/HEADaunque no es recomendable. Por otro lado, si lo que quieres no es tener la referencia de la rama pero sí el valor del HEADen el que estás, puedes usar el comando git rev-parse HEAD.

$ git rev-parse HEAD
5d689b826e172a7a5b78ce60c30b7d0e0891197c

Ahora te preguntarás…¿por qué es importante saber qué significa HEAD ? Pues bien, más adelante verás que algunos comandos lo utilizan para indicar dónde estás trabajando o hacia dónde quieres moverte.

Entiende HEAD como un “estás aquí” de un mapa. Sólo puedes estar en un sólo lugar y ese lugar es el HEAD(en mayúsculas).

¿Cómo puedo deshacer mis cambios?

Lo mejor que tieneGites quecasisiempre que te equivocas puedes deshacer tu cambio y seguir siendo feliz. Digamos que te proporciona un montón de redes de seguridad para evitar que hagas cosas que… no deberías.

Una de esas veces es cuando hacemos un commit. ¿Qué pasa si nos hemos equivocado? ¿Cómo deshacemos el último commit? ¿Y si ya lo he publicado?

Vamos a ver cómo podemos deshacer un commit que hemos hecho en nuestro repositorio local. Más adelante, veremos cómo podemos conseguir lo mismo si ya hemos llevado nuestros cambios a la nube.

Deshacer el último commit

A vecesqueremos tirar para atrás el último commitque hemos hecho porque hemos añadido más archivos de la cuenta, queremos hacer commit de otra cosa o, simplemente, porque ahora no tocaba.

Si todavía no has llevado tus cambios al repositorio remoto tienes dos formas de hacer esto. Ambas son válidas pero dependerá si quieres, o no, mantener los cambios del commit.

Siquieres mantener los cambios:

$ git reset --soft HEAD~1

Con el comandoresethacemos que la rama actual retroceda a la revisión que le indicamos. En este caso le decimos HEAD 1. Esto significa que queremos volver a la versión inmediatamente anterior a la que estamos ahora.

HEAD 1 es una referencia a la versión anterior a la que estamos ahora. Es equivalente a HEAD^pero en algunos sistemas el uso del carácter^puede ser problemático. Además, creo que HEAD 1 es más fácil de leer.

El parámetro—softes el que va a hacer que los cambios que habíamos hecho en el commit, en lugar de eliminarlos, nos los mantenga como cambios locales en nuestro repositorio.

De hecho, al ejecutar este comando, no se eliminarán los cambios del commit, sino que se mantendrán como cambios locales. Por lo que podrías volver a hacer exactamente el mismo commit que antes.

> git reset --soft HEAD~1
> git status
On branch main
Changes to be committed:
(use "git restore --staged <file>..." to unstage)
modified: README.md
modified: index.js

SiNO quieres mantener los cambios:

$ git reset --hard HEAD~1

Es simplemente el mismo comando pero cambiamos—softpor—hard. Esto eliminará los cambios de los que habíamos hecho commit anteriormente.¡Ojo! ¡Asegúrate que eso es lo que quieres antes de hacerlo!

Si quieres arreglar el último commit

A veces no quieres tirar atrás el último commit que has hecho si no que simplemente quieres arreglarlo. Aquí hay dos opciones:

Sóloquieres arreglar el mensaje que has usado para el último commit:

$ git commit --amend -m "Este es el mensaje correcto"

Quieres añadir más cambios al último commit:

# Añade los archivos con modificaciones

$ git add src/archivo-con-cambios.js
# Vuelve a hacer el commit con el parámetro amend
$ git commit --amend -m "Mensaje del commit"

Ya sea que sólo quieres cambiar el mensaje de commit o que además quieres añadir modificaciones en el último commit, lo importante es queesto NO va a crear un nuevo commit si no que va a solucionar el anterior.

Importante: El parámetro de—amendes muy útil pero sólo funciona con el último commit y siempre y cuando NO esté publicado en el repositorio remoto. Si ya has hechopushde ese commit, esto no va a funcionar. Deberías hacer un git revert en su lugar pero no te preocupes que lo explicaremos más adelante.

¿Cómo puedo ignorar archivos?

No todos los archivos que tienes en tu directorio de trabajo tendrán que ser controlados por Git para ser guardados en el repositorio. A veces tienes ficheros o directorios enteros que no quieres grabar a ningún repositorio, ya que son de configuración o no añaden valor al historial de cambios.

Para que Git los ignore, debes añadirlos a un archivo.gitignoreen tu repositorio. Normalmente se sitúa en la raíz, pero puedes tener uno en cada directorio (además de tener uno global que afectará a todos los repositorios del sistema).

Vamos a ver un ejemplo de que podría ser el contenido de un archivo.gitignore:

node_modules # Ignorar carpeta de módulos
.env # Ignorar fichero con variables de entorno
.DS_Store # Ignorar fichero de sistema
build/ # Ignorar carpeta generada

¿Qué archivos y carpetas deberías colocar aquí? Aquí te dejo una lista:

- Archivos que tengan credenciales o llaves de API (no deberías subirlas al
repositorio, simplemente inyectarlas por variable de entorno)
- Carpetas de configuración de tu editor (/.vscode)
- Archivos de registro (log files)
- Archivos de sistema como.DS_Store
- Carpetas generadas con archivos estáticos o compilaciones como/disto/build
- Dependencias que pueden ser descargadas (/node_modules)
- Coverage del testing (/coverage)

En Visual Studio Code, los archivos ignorados aparecen con un gris oscuro. Como ves, están disponibles en tu directorio de trabajo pero si haces cambios en ellos, Git los ignorará

Te recomiendo que le eches un vistazo agitignore.io¹⁵. Este proyecto genera un archivo .gitignore en base al sistema operativo, editor y proyecto que le indiques y te puede servir de referencia en el futuro.

^¹⁵ https://www.toptal.com/developers/gitignore

¿Cómo consigo ignorar siempre los mismos archivos en todos mis repositorios?

Una forma sería copiar una y otra vez el archivo.gitignoreen todos los repositorios de tu sistema para luego adaptarlo al proyecto al que va dirigido.

Sin embargo, si tienes muy claro que quieres ignorar archivos en todos tus repositorios puedes crear un archivo.gitignoreglobal que te va a ayudar a dejar de preocuparte siempre por los mismos archivos, especialmente aquellos que tienen que ver con tu IDE o sistema operativo.

Para ello, primero creamos el fichero/.gitignore_globalcon el contenido que queremos que se añada a todos los repositorios. Yo tengo algo muy parecido a esto:

# Archivos y directorios de sistema
.DS_Store
Desktop.ini
Thumbs.db
.Spotlight-V100
.Trashes

# Variables de entorno
.env

# Directorios de instalación y caché
node_modules
.sass-cache

# Configuración de editor

.vscode/*
!.vscode/settings.json
!.vscode/tasks.json
!.vscode/launch.json
!.vscode/extensions.json
*.code-workspace

Ahora, vamos a actualizar la configuración decore.excludesfilepara que lea este archivo de forma global en todos los repositorios locales.

git config --global core.excludesfile ~/.gitignore_global

Ten en cuenta que esto es útil para archivos y directorios de tu propio sistema que quieres ignorar. Pero siempre es mejor que estos archivos estén bien definidos en el.gitignorede cada repositorio, puesto que es la referencia única que todo el mundo se descargará del repositorio remoto.

Por si te interesa, la compañía GitHub tiene un repositorio con una colección de archivos de .gitignore¹⁶para diferentes lenguajes y sistemas operativos. No está muy actualizada pero puede ayudarte a entender qué ficheros deberías incluir ahí.

^¹⁶ https://github.com/github/gitignore

¿Cómo le indico a Git que deje de hacer el seguimiento de un archivo (o varios archivos)?

Imagina que has hecho commit de un fichero pero resulta que, más tarde, te has dado cuenta que en realidad no quieres que este archivo sea parte de tu repositorio. ¿Ahora que hacemos?

Ya hemos visto que deberíamos haberlo añadido al.gitignore… pero a veces nos damos cuenta tarde. ¡No pasa nada! Vamos a ver cómo podríamos arreglar esto.

Primero, añade en el.gitignoreel archivo o directorio que quieres que no sea parte de tu repositorio tal y como hemos visto antes.

Cómo conseguirlo manualmente…

Ahora, en el directorio de trabajo, podríamos borrar los ficheros que no queremos que sean parte del repositorio y luego hacer commit de los cambios.

Por ejemplo, imagina que quieres eliminar el archivo config.local.jsde tu repositorio. Para ello, primero debes borrarlo del directorio de trabajo:

$ rm config.local.js
$ git add config.local.js
$ git commit -m "Remove config.local.js as it 's not part of the repository"

Una vez hecho esto, la próxima vez que creemos el fichero config.local.jsen el directorio de trabajo, no podrá incluirse en el repositorio ya que lo tendremos ignorado.

Usando git…

Esto mismo podemos conseguirlo con un simple, y seguramente más acertado comando, usando git. Para ello, debemos usar el comandorme indicarle qué archivos queremos borrar. Siguiendo con el ejemplo anterior:

$ git rm config.local.js
$ git commit -m "Remove config.local.js to ignore it"

¿Por qué usar git rm? Hay varias razones:

Porquermes un comando de sistema y no de git. Por lo que es posible que no esté disponible en todos los sistemas operativos. 2. Porque git rmes un sólo comando y simplifica la tarea de borrar archivos de un repositorio. 3.git rmva a evitar que se borre si el archivo tiene alguna modificación. 4. Puedes usar el parámetro—dry-runpara ver qué archivos se borrarán sin realizar la operación.

Como ves...¡todo ventajas!

Las dos formas eliminan el fichero de tu directorio de trabajo. Pero… ¡Ten en cuenta que esto no elimina el archivo de tu historial! Por lo que aunque el fichero no exista en tu sistema o en el directorio de trabajo, el archivo sigue en el historial de cambios del fichero de Git y alguien podría recuperarlo. Hay otras formas de conseguir sobrescribir el historial para que tampoco esté disponible ahí.

¿Y cómo consigo lo mismo pero manteniendo el fichero

en mi directorio de trabajo?

En ocasiones quieres que un archivo deje de ser parte de tu repositoriopero que no se borre del directorio de trabajo. Por ejemplo, a veces puede ser interesante para archivos de configuración o que han sido generados, y que no quieres volver a generarlos de nuevo localmente.

Puedes lograrlo también con git rmpero añadiendo el parámetro—cached:

$ git rm --cached <nombre-de-archivo>

De esta forma, ese fichero se eliminará del repositorio, se añadirá al historial de cambios, pero no se borrará del directorio de trabajo.

Si necesitas borrar una carpeta y todos los ficheros que lo contiene, puedes utilizar el comando git rm -r. La-rindica que se borrará la carpeta y todos sus ficheros de forma recursiva.