Conceptos de Git

¿Qué es una rama?

Una rama en Git es simplemente un puntero móvil que referencia a un commit. Cuando hacemos un commit, el puntero de la rama avanza automáticamente al último commit confirmado.

Las ramas son mutables, es decir, pueden cambiar a lo largo del tiempo. En Git, cada rama representa una línea de desarrollo que puede evolucionar de manera independiente. Esto permite realizar cambios, agregar nuevas funcionalidades o corregir errores sin afectar directamente la rama principal (usualmente denominada master o main). Las ramas pueden ser modificadas, eliminadas o fusionadas con otras ramas según sea necesario.

También, podemos afirmar que una rama es una forma más sencilla de referirse a un commit. En lugar de utilizar un hash complicado y dificil de recordar, los desarrolladores utilizan nombres o palabras clave (como por ejemplo: hotfix-home-button, hero-landing-feature, entre otros).

Las ramas pueden tener cualquier nombre y podes crear tantas como necesites. Para crear una rama nueva, escribimos en la terminal git branch name. Este comando creará una nueva rama llamada “name” que apuntará al commit actualmente confirmado. Otro comando muy útil es git branch -d name, que nos permite eliminar una rama (name) que ya no necesitamos.

Las ramas surgen de la necesidad de trabajar en paralelo en diferentes características o versiones de un proyecto, son muy útiles para trabajar en equipos distribuidos o para mantener un flujo de trabajo organizado. Como estándar en la industria del software se suele utilizar Git flow, un modelo de ramificación que define cómo se deben crear y fusionar las ramas en un proyecto. Si te interesa conocer más sobre Git flow, te recomiendo leer este artículo.

¿Cómo moverse entre ramas?

Para movernos entre ramas (punteros que hacen referencia a un commit) o commits particulares, utilizamos el comando git checkout. Por ejemplo, para pasar de la rama master a la rama dev, escribimos git checkout dev o si queres ir a un commit en específico utilizamos git checkout e088135.

Combinando comandos

Git es flexible y ha incorporado atajos para optimizar ciertas operaciones recurrentes como la creación de nuevas ramas y moverse hacía ellas. Surge entonces la posibilidad de combinar git branch y git checkout con git checkout -b branchname. Esto creará la rama (si no existe) y cambiará a ella inmediatamente.

¿Qué es una etiqueta?

Una etiqueta en Git es una referencia a un commit específico. Se utilizan para marcar puntos importantes en la historia del proyecto, como versiones de lanzamiento (v1.0, v2.0, entre otros). Las etiquetas son inmutables, es decir, una vez creadas no pueden ser modificadas.

Tipos de etiquetas

En Git existen dos tipos de etiquetas: anotadas y ligeras.

• Etiquetas anotadas: son almacenadas como objetos completos en la base de datos de Git. Tienen un checksum; contienen el nombre del etiquetador, correo electrónico, fecha y un mensaje asociado. Para crear una etiqueta anotada, se utiliza el comando git tag -a name (podemos agregar la bandera -m como en los mensajes de los commits). Normalmente, se recomienda utilizar este tipo de etiquetas.

• Etiquetas ligeras: son simplemente un puntero a un commit específico, es decir, es el checksum de un commit guardado en un archivo. No contienen información adicional. Para crear una etiqueta ligera, se utiliza el comando git tag name. Son similares a las ramas, pero no cambian de posición. Este tipo de etiquetas se utilizan de forma temporal o si por alguna razón no necesitas información adicional. De lo contrario, es recomendable utilizar etiquetas anotadas.

Para ver el contenido de una etiqueta, utilizamos el comando git show name. Si es una etiqueta ligera, solamente veremos el contenido del commit al que hace referencia, en cambio, si es anotada veremos la información adicional. Puede ocurrir que nos olvidemos de agregar una etiqueta a un commit anterior al último confirmado. Para ello, utilizamos el comando git tag -a name hash-del-commit.

Por defecto, el comando git push no transfiere las etiquetas a los servidores remotos. Debemos enviarlas de forma explícita al servidor luego de que las hayamos creado. Para ello, ejecutamos git push origin [etiqueta] o git push --tags (para enviar todas las etiquetas); este proceso es similar al de compartir ramas remotas.

🚨 Atención: tenes que tener cuidado al enviar etiquetas al servidor remoto, porque podría causar conflictos o problemas si otras personas ya están trabajando en ese mismo commit sin la etiqueta.

Para eliminar una etiqueta de forma local, utilizamos el comando git tag -d name. Si deseamos eliminar una del servidor remoto, ejecutamos el comando git push origin --delete name.

Parte 1: Volver atras el historial

El comando git reset se utiliza para "rebobinar" el historial de commits y, dependiendo de la opción usada, para modificar también el área de preparación y el directorio de trabajo. Es importante notar que git reset mueve el puntero de HEAD y de la rama actual, afectando directamente la "historia" del proyecto.

Cuando corremos git reset, Git realiza las siguientes acciones:

• Actualiza el historial de commits (HEAD): el puntero se mueve al commit indicado. Esto es fundamental, ya que define el punto de "rebobinado" en la historia.
• Modifica el índice del área de preparación y/o directorio de trabajo: dependiendo de las opciones usadas, Git decide si los cambios en el área de preparación y en los archivos de trabajo se mantienen, se deshacen o se eliminan.

Existen tres formas de utilizar este comando: --hard, --soft y --mixed.

• Modo --hard: este modo mueve el puntero del commit (HEAD y la rama actual) al commit especificado. Además, restablece tanto el índice del área de preparación como el directorio de trabajo para que coincidan exactamente con ese commit. Como resultado, todos los cambios no confirmados se pierden, ya que el área de preparación y los archivos de trabajo se sobrescriben. Esta opción se utiliza generalmente cuando queremos descartar por completo los cambios locales y regresar a un estado anterior conocido.
• Modo --mixed (opción por defecto): esta alternativa a diferencia de la primera mueve el puntero del commit al commit especificado, reinicia el índice del área de preparación para que refleje el estado de ese commit, pero deja intacto el directorio de trabajo. Los cambios que se habían preparado (staged) se "despreparan" y quedan como modificaciones en el directorio de trabajo. Esta opción esta definida por defecto en Git porque es ideal para reorganizar o refinar los cambios antes de hacer un nuevo commit.
• Modo --soft: este modo solo mueve el puntero del commit al commit indicado, sin tocar el índice de la área de preparación ni el directorio de trabajo. Por ende, los cambios preparados y los archivos modificados permanecen intactos, listos para ser confirmados nuevamente. Es útil para combinar o reorganizar commits sin perder el trabajo que ya has preparado. Por ejemplo, cuando queres deshacer commits recientes pero mantener los cambios listos para un nuevo commit.

Para utilizar un modo debemos ejecutar el siguiente comando: git reset --[modo] [hash-commit]

ℹ️ Info: “HEAD^” se refiere al commit anterior a HEAD; “HEAD^^” es dos commits atrás, y así sucesivamente.

En el playground solamente se puede utilizar el modo --hard.

Parte 2: Deshacer commits compartidos

El comando git git revert es una herramienta para "deshacer" cambios en Git, pero a diferencia de otros métodos, no elimina el commit problemático del historial. En lugar de borrarlo, Git invierte los cambios realizados por ese commit y crea un nuevo commit con la acción inversa. Esto garantiza que el historial completo del proyecto se mantenga intacto, lo que es esencial para la integridad y la colaboración en equipo.

Como mencionamos, este comando crea un nuevo commit que revierte los cambios del commit indicado. El puntero de la rama se mueve al nuevo commit, manteniendo el historial lineal y completo. Así, se conserva la trazabilidad de todas las modificaciones. Dado que el historial no se altera, esta es la opción ideal para deshacer cambios en commits que ya han sido compartidos en un repositorio remoto.

Diferencias entre reset y revert

La primera diferencia, es que git revert no altera el historial del proyecto ; se considera una acción "segura" para revertir cambios en repositorios compartidos.

La segunda es que git revert permite hacer foco en commit particular en un punto arbitrario de la historia del repositorio. Mientras que, git reset solamente puede trabajar hacia atrás en la historia desde el commit actual. Por ejemplo, si queremos deshacer un commit que ocurrió hace 5 commits atrás, git revert es la opción correcta. De lo contrario, si utilizaramos git reset estaríamos eliminando los commits posteriores a ese commit.

Imagen de comparación entre git revert y git reset - Bitbucket

¿Qué es una fusión?

La fusión en Git es el proceso de combinar ramas o commits en la rama actual. Git toma los cambios realizados en otra rama (o en commits específicos) desde que se separó de la rama actual y los integra en ésta. La fusión es una operación fundamental en Git, ya que permite combinar el trabajo de diferentes desarrolladores que trabajan en paralelo.

El proceso puede dar lugar a dos situaciones principales:

• Fusión por avance rápido ("fast-forward"): si la rama actual es un ancestro directo de la rama que se quiere unir, Git simplemente actualiza el puntero (HEAD) de la rama actual al commit más reciente de la otra rama. En este caso, no se crea un nuevo commit de merge.
• Fusión de ramas divergentes: cuando las ramas han divergido, es decir, han tenido cambios diferentes, Git "reproduce" los cambios realizados en la rama que se une y crea un nuevo commit que tiene dos padres (uno para cada rama). Este commit de merge refleja la integración de ambos conjuntos de cambios.

ℹ️ Aclaración: siempre que se debe realizar un merge surge confusión sobre qué rama es la que se va a fusionar y va a tener los cambios. Es por ello que la rama que desean que tenga los cambios se debe encontrar en la rama actual, luego realizan el merge con la rama que posee los cambios. La fusión TRAE los cambios de una rama a otra.

Es recomendable que todos tus cambios locales estén confirmados (o guardados usando git stash) para evitar que se sobrescriban durante el merge. También, Git abortará la fusión si hay cambios sin confirmar en el área de staging que puedan interferir con el proceso.

Si los cambios en ambas ramas afectan la misma parte de un archivo, Git no puede decidir automáticamente cuál versión usar. En ese caso, se produce un conflicto y el archivo se marcará con indicadores (<<<<<<<,=======,>>>>>>>). En estos casos podrás: resolver el conflicto manualmente y luego agregar los cambios con git add, o utilizar herramientas de fusión gráfica.

Es posible abortar el merge con git merge --abort si prefieres cancelar la operación.

git merge crea un commit con dos padres, combinando los cambios de ambas ramas.

Estrategías de merge

Git permite seleccionar distintas estrategias para combinar los cambios. Algunas de las más utilizadas son:

• Fast-Forward: actualiza el puntero de la rama actual si no hay cambios divergentes. Se puede forzar la creación de un commit de merge usando la opción --no-ff.
• Merge tradicional (3-way): compara la base común y las dos ramas para integrar los cambios, creando un commit de merge que une ambas historias.
• Estrategias especializadas: Git ofrece opciones como ours, theirs, y opciones para tratar diferencias en espacios en blanco o renombres, que pueden ayudar a resolver conflictos específicos.

Cada estrategia tiene sus propias opciones, pero en la mayoría de los casos la estrategia predeterminada (ort o recursive) es suficiente para la fusión de ramas. Si te interesa conocer más al respecto, te recomiendo leer el siguiente artículo.

¿Qué es un rebase?

El rebase en Git permite mover o combinar una serie de commits a una nueva "base" (commit inicial) . Esto ayuda a mantener un historial lineal y limpio, como si hubieras trabajado siempre desde la versión más reciente del proyecto.

De esta forma, mantenemos un historial lineal lo cual evita commits de merge innecesarios. Nos ayuda a sincronizar nuestra rama con los últimos cambios de main o una rama principal. Por último, nos permite limpiar commits, es decir, podemos combinar, editar o eliminar commits antes de fusionarlos.

Modos de rebase

Al igual que con el comando git reset, el comando git rebase tiene distintos modos de uso:

• Rebase estándar: mueve automáticamente los commits de tu rama actual a la nueva base.
• Rebase interactivo: permite editar, combinar o eliminar commits antes de aplicarlos. Los comandos más usados son:
  • pick: mantiene el commit.
  • reword: cambia el mensaje del commit.
  • edit: modifica el contenido del commit.
  • squash: combina commits anteriores.
  • drop: elimina el commit.

ℹ️ Nota: el rebase reescribe la historia del proyecto, por lo que no se recomienda en ramas compartidas. Siempre es mejor utilizarlo en ramas locales. Si hay cambios contradictorios, Git detendrá el rebase, podes resolver los conflictos y continuar con git rebase --continue o cancelar con git rebase --abort.

Usos avanzados

• Rebase --onto: útil para mover una rama que depende de otra. Por ejemplo, si featureB se basó en featureA pero debe moverse a main: git rebase --onto main featA featB.
• Recuperar commits perdidos: si accidentalmente borraste algunos commits, usa git reflog para encontrar su hash y restaurarlos.

Este comando es ideal para limpiar ramas locales antes de fusionarlas con la rama principal. También es útil para mantener un historial limpio y fácil de seguir. En el playground solamente se puede utilizar el modo estándar de rebase.

¿Qué es un fetch?

El comando git fetch es una herramienta esencial que te permite descargar commits, archivos y referencias de un repositorio remoto a tu repositorio local. Este sólo trae la información remota sin modificar tu entorno de trabajo actual. Esto lo convierte en una opción segura para revisar lo que han hecho otros antes de integrar esos cambios en tu proyecto.

Los cambios descargados se almacenan de forma separada en tu repositorio local. No afectan tu trabajo actual hasta que decidas revisarlos o fusionarlos con comandos como git checkout o git merge.

Ramas remotas

Git organiza las ramas remotas en una estructura distinta a las locales. Las ramas locales se encuentran en ./.git/refs/heads/ y las remotas en ./.git/refs/remotes/. Por lo general, el flujo de trabajo implica traer los cambios de las ramas remotas, revisar los commits y por último integrar los cambios.

¿Qué es un pull?

El comando git pull descarga el contenido de un repositorio remoto y de forma inmediata actualiza el repositorio local para que tengan el mismo contenido. Este comando es la combinación de dos comandos: un git fetch seguido de un git merge (o rebase si se indica) para actualizar la rama actual. En una primera instacia, se ejecuta el fetch sobre la rama local donde apunta el HEAD. Una vez que el contenido haya sido descargado, se realiza un merge con la rama actual.

Es el responsable de "sincronizar" el contenido remoto con nuestras ramas locales. git fetch es considerado una opción más "segura" porque solamente descarga el contenido remoto sin modificar el entorno de trabajo actual. Suele suceder que al realizar el merge nuestro repositorio local quede en un estado de conflictos.

Si deseas evitar conflictos, puedes utilizar git pull --rebase para realizar un rebase en lugar de un merge. Esta alternativa es útil para mantener un historial lineal y limpio.

¿Qué es un push?

El comando git push envía los commits, referencias y archivos locales a la rama correspondiente en el repositorio remoto. Este comando es el complemento de git fetch; mientras que el primero descarga contenido remoto, el segundo envía contenido local.
‼️ Por defecto, Git evita evita que sobrescribas cambios en el repositorio remoto (no-fast-forward) para proteger la historia compartida.

ℹ️ Es recomendable antes de realizar un push, ejecutar un git pull para asegurarte de que tu rama local esté actualizada con los últimos cambios remotos.

En ocasiones, tras modificar commits (por ejemplo, usando git commit --amend o rebase interactivo), Git no permitirá hacer push ya que la historia diverge. En ese caso, se puede forzar el push: git push --force.

⚠️ Advertencia: utiliza --force solo si estás seguro de que nadie más ha extraído esos commits, porque podes llegar a sobrescribir cambios en el repositorio remoto.

1. Ejemplo práctico

En muchas situaciones, es posible que deseamos volver a un estado limpio del repositorio remoto. Para ello, podemos restaurar el estado de nuestra rama local con la del origen utilizando git reset origin/master.

ℹ️ Nota: Esto no elimina archivos no rastreados. En esos casos, debemos utilizar git clean -df.

2. Ejemplo práctico

Si estamos trabajando en una rama local y deseamos actualizarla con el último código de origin/master sin cambiar de rama, podemos hacer un git fetch y luego git rebase origin/master.

ℹ️ Nota: Al realizar esta acción, estamos alternado la historia de la rama local. Por lo tanto, no es recomendable hacerlo en ramas compartidas.

3. Ejemplo práctico

En Git, las ramas son ligeras y fáciles de crear, pero a veces es necesario eliminarlas para mantener un historial limpio. Para ello, podemos utilizar el comando git branch -d.

ℹ️ Nota: Si la rama que deseas eliminar tiene cambios sin confirmar, Git no permitirá eliminarla. En ese caso, podes forzar la eliminación con git branch -D.

Playground

Esta es una zona libre para que experimentes sin restricciones.