Git: repositorio local

Para inicializar un repositorio de Git, muévete al directorio de trabajo y ejecuta el siguiente comando:

git init

A partir de ahora Git hará un seguimiento de los cambios que se produzcan en el directorio de trabajo, que ahora es un repositorio.

Esta es la opción de Git MÁS IMPORTANTE, ya que te permite conocer el estado en que se encuentra el respositorio y, además, obtendrás información de las acciones que puedes realizar según el estado:

git status

Este comando te informará del estado en que se encuentran los ficheros del repositorio. Además, este comando es fundamental y muy útil porque, en función del estado te informa, además, de los comandos y opciones que puedes usar.

Estas son las posibilidades con las que te pudes encontrar:

• El repositorio está limpio: no hay cambios.
• Hay ficheros sin seguimiento: estos ficheros están en el directorio de trabajo pero Git no sabe nada de ellos, no están en el repositorio.
• Hay cambios no rastreados: hay cambios en los ficheros que se indique, lo que significa que estos ficheros están en Git pero han sufrido cambios en el directorio de trabajo.
• Cambios en el área de preparación o stage: son ficheros que has marcado para que se añadan en el siguiente commit.

Sea cual sea el escenario del cambio, si los quieres confirmar en Git tienes que llevar a cabo 2 pasos:

1. Añadir los cambios al state o área de preparación
2. Crear un commit, que se aplicará sobre el state o área de preparación del paso anterior

Estos dos pasos se llevan a cabo con sendos comandos:

1. git add
2. git commit

En el git add tienes que indicar los cambios que deseas introducir en el stage o área de preparación. Por ejemplo, git add fic1.txt fic2.txt añadaría al stage los cambios en esos dos ficheros. Si quieres añadir todos los ficheros con cambios puedes usar el atajo git add . (fíjate en el último punto).

Tras añadir los cambios en el stage ya puedes llevar a cabo el segundo paso: git commit. Este comando tiene que ir acompañado de una descripción, por ejemplo: git commit -m "Nuevos ficheros añadidos al repositorio".

Para ver el historial de los cambios o commits que has hecho usa el comando:

git log

Este comando tiene un serie de opciones para ver más o menos información. Algunos ejemplos son:

• git log --graph para ver el grafo con el camino de los cambios en el repositorio.
• git log --oneline para ver los commits junto a la descripción, nada más.
• git log --stat para ver qué ficheros fueron cambiados y cuántos cambios se han producido.
• git log --p para ver los detalles de los cambios en los ficheros.
• git log --all para ver el árbol completo con los commits de todas las ramas que se hayan podido crear y existan.

Puedes combinar opciones. Por ejemplo: para ver el resumen en una línea de todos los commits en forma de árbol o grafo, puedes usar esta combinación de opciones:

git log --oneline --graph --all

Otra opción que nos ofrece Git es la de ver estos logs formateados de tal manera que podamos usar dicha información para liberar una nueva versión de nuestro software:

git shortlog

Existe un comando muy útil de Git que nos permite ver los cambios que se han hecho. Existen varios escenarios que se describen en los siguientes apartados pero, en general, la sintaxis del comando es:

git diff [--staged] [<path>] [<commit1>] [<commit2>]

Donde, si indicas la opción --staged solo verás los cambios de los ficheros que hay en el área de preparación y el repositorio, y si añades un path entonces solo verás los cambios de ese fichero con respecto al repositorio.

Por último, si añades la referencia a dos commits verás los cambios que se han producido entre dichos commits.

En los siguientes apartados se muestran los posibles escenarios en que podemos usar el comando git diff:

El commit sobre el que estamos trabajando tiene un puntero llamado HEAD.

Podemos usar el puntero o referencia HEAD de Git para identificar commits. En vez de usar el hash del commit podemos usar el HEAD:

• HEAD apunta al último commit.
• HEAD^ apunta al penúltimo commit.
• HEAD^^ apunta a dos commits atrás.
• HEAD^^^ apunta a tres commits atrás… vas entendiendo, ¿verdad?

Si quieres apuntar a muchos commits atrás o, si lo prefires, puedes usar esta otra alternativa:

• HEAD~1 apunta al penúltimo commit.
• HEAD~2 apunta a dos commits atrás.
• HEAD~10 apunta a diez commits atrás.

Sabiendo esto, podemos comparar los últimos dos commits así:

git diff HEAD^ HEAD

O, podemos ver los cambios que se han producido en los últimos tres commits así:

git diff HEAD~3 HEAD

Otra opción útil en Git es git restore, con el que podemos descargar los cambios que hay en el directorio de trabajo con respecto al repositorio.

La sintaxis, en general, es:

git restore [--staged] [<path>]

Donde:

• <path> es una o varias rutas a los ficheros cuyos cambios quieres descartar y es opcional (si no se indica se descartan los cambios de todos los ficheros), y
• --staged es una opción que, si se indica, descarta los cambios de los ficheros que están en el ára de preparación.

Es un comando MUY PELIGROSO porque descarta los cambios que has hecho sin posibilidad de recuperarlos.

Podemos indicar a Git qué ficheros queremos que ignore y, por tanto, que no haga un seguimiento de ellos.

Se utiliza un fichero llamado .gitignore que se crea en la raíz del proyecto para indicar en él, a través de reglas, qué ficheros queremos ignorar. ¿Por qué? Entre otras cosas:

• Porque contienen información sensible
• Porque son ficheros temporales
• Porque no son relevantes para el proyecto

En este fichero indicamos, por cada línea, qué fichero o ficheros ignorar, usando patrones. Algunos ejemplos:

• message.log ignorará todos aquellos ficheros que se llamen message.log estén donde estén.
• /message.log ignorará el fichero llamado message.log que está en la raíz del proyecto.
• logs/message.log ignorará el fichero llamado message.log que está dentro de la carpeta logs.
• logs/ ignorará todos los ficheros que haya en la carpeta logs.
• *.log ignorará todos los ficheros que acaben con la extensión .log, estén donde estén.
• logs/*.txt ignorará todos los ficheros que acaben con .txt dentro de la carpeta logs.

Recuerda configurar tu rama principal con el nombre main que es el nombre que se usa como convención hoy en día para la rama principal de trabajo:

$ git config --global init.defaultBranch main

Recordada esta configuración, ya podemos hablar de ramas: las ramas son diferentes líneas de desarrollo en Git. Nos permite trabajar de forma independiente y sin colisionar en proyectos colaborativos.

También es útil usar ramas aunque trabajemos en un proyecto en solitario porque esto nos permitirá trabajar en características nuevas y hacer pruebas sin estropear la línea principal de trabajo.

Aquí te doy la lista de las opciones, lo que puedes hacer con las ramas y el comando git branch:

• git branch para ver las ramas actuales.
• git branch <nombre de la rama> para crear una nueva rama con el nombre indicado.
• git branch -d <nombre de la rama> para borrar de forma segura un rama ya que no se hará si hay cambios por mezclar.
• git branch -D <nombre de la rama> para borrar la rama, se encuentre como se encuentre (¡¡¡CUIDADO!!!).
• git branch -m <nuevo nombre de la rama> para cambiar el nombre de la rama actual por el nuevo nombre indicado.
• git branch -a para ver las ramas remotas (todavía no hemos entrado al trabajo remoto con Git pero podemos adelantar este comando, para que lo tengas presente).

La opción checkout de Git la podemos usar para movernos de rama o de commit.

Puedes mezclar ramas haciendo un merge o un rebase. Te resumo en los siguientes apartados cómo hacerlo.

Un rebase interactivo te permite reorganizar y editar el historial de commits de manera flexible y controlada. Por ejemplo, con un rebase interactio puedes:

• Reordenar commits: puedes cambiar el orden en que se aplicaron los commits.
• Aplastar commits: puedes combinar varios commits en uno solo.
• Dividir commits: puedes dividir un commit en varios commits más pequeños.
• Editar commits: puedes editar el mensaje de commit o incluso el contenido del commit.
• Eliminar commits: puedes eliminar commits que ya no sean necesarios.
• Reorganizar commits para que tengan un orden lógico y coherente.

Para dar comienzo a un commit interactivo tienes que ejecutar el comando git commit -i <commit> donde <commit> es la referencia del commit a partir del cual das comienzo al rebase interactivo. Por ejemplo:

git rebase -i HEAD~5

Das comienzo al commit interactivo a partir del commit HEAD~5 (este no se incluye).

Al iniciar un commit interactivo se abrirá el editor de textos y aparecen la referencia a todos los commits junto a un comentario con todas las opciones disponibles.

Aquí puedes ver la captura del editor de textos que muestra información de un rebase interactivo: