Cómo usar .gitignore: una guía paso a paso

En el sistema de control de versiones Git, existen dos formas de combinar una rama con otra, representadas por diferentes comandos: git merge. Los commits de una rama se transfieren a otra creando un commit de fusión (merge commit). git rebase. Los commits de una rama se transfieren a otra mientras se conserva el orden original de los cambios. En pocas palabras: con git merge, los commits de una rama se “comprimen” en uno solo, mientras que con git rebase permanecen intactos, pero las ramas se combinan igualmente. El comando git rebase permite, por tanto, combinar los commits de ambas ramas formando un historial compartido de cambios. Esta guía aborda el comando git rebase, que se encarga de reasignar (rebasar) los commits (cambios) de una rama a otra. Todos los ejemplos mostrados usan Git versión 2.34.1, ejecutándose en un servidor de Hostman con el sistema operativo Ubuntu 22.04. Puedes usar estas guías para instalar Git en tu equipo: Installing Git on Ubuntu Installing Git on Windows Qué es Git Rebase Git Rebase es un comando potente que se usa principalmente para integrar cambios de una rama sobre otra reescribiendo el historial de commits. A diferencia de git merge, que crea un nuevo commit de fusión y preserva el historial de ambas ramas, git rebase mueve o “reproduce” una serie de commits de una rama sobre otra. Este proceso genera un historial lineal, que parece como si la rama de funciones se hubiera desarrollado directamente desde el último commit de la rama principal (por ejemplo, main o master). Así, se limpia el historial y se eliminan commits de fusión innecesarios, resultando en una estructura de proyecto más clara y organizada. Cómo funciona Git Rebase La mejor manera de entender cómo funciona rebase en Git es observar un repositorio abstracto compuesto por varias ramas. El proceso debe analizarse paso a paso. Creación de ramas Supongamos que creamos un repositorio con una sola rama, master, que contiene un único commit. La rama master se ve así: master   commit_1 Luego, a partir de master, creamos una nueva rama llamada hypothesis, donde decidimos probar algunas funciones. En esta nueva rama realizamos varios commits mejorando el código. La rama ahora se ve así: hypothesis   commit_4   commit_3   commit_2   commit_1 Más tarde, añadimos otro commit a la rama master para corregir urgentemente una vulnerabilidad. La rama master ahora se ve así: master   commit_5   commit_1 Ahora nuestro repositorio tiene dos ramas: master   commit_5   commit_1 hypothesis   commit_4   commit_3   commit_2   commit_1 La rama master es la principal, mientras que hypothesis es secundaria (derivada). Los commits más recientes se muestran encima de los anteriores, como en la salida del comando git log. Fusión de ramas Supongamos que queremos seguir trabajando en la función que habíamos movido a la rama hypothesis. Sin embargo, esta rama no contiene la corrección crítica que hicimos en master. Por lo tanto, queremos “sincronizar” el estado de hypothesis con master para que el commit de corrección también aparezca en la rama de funciones. En otras palabras, queremos que la estructura del repositorio se vea así: master   commit_5   commit_1 hypothesis   commit_4   commit_3   commit_2   commit_5   commit_1 Como puedes ver, ahora hypothesis repite exactamente el historial de master, aunque originalmente se creó antes de commit_5. Es decir, hypothesis ahora contiene el historial de ambas ramas: la suya y la de master. Para lograrlo, debemos usar git rebase. Después, los cambios hechos en hypothesis pueden fusionarse en master usando el comando clásico git merge, que crea un commit de fusión. La estructura del repositorio se verá así: master   commit_merge   commit_5   commit_1 hypothesis   commit_4   commit_3   commit_2   commit_5   commit_1 Además, ejecutar git merge después de git rebase puede reducir la probabilidad de conflictos. Práctica: git rebase Una vez cubierto el aspecto teórico del comando git rebase, podemos probarlo en un repositorio real de un proyecto de ejemplo. La estructura del repositorio será la misma que en el ejemplo teórico anterior. Creación de un repositorio Primero, crea un directorio separado para el repositorio: mkdir rebase Luego entra en él: cd rebase Ahora podemos inicializar el repositorio: git init En la consola aparecerá un mensaje informativo estándar: hint: Using 'master' as the name for the initial branch. This default branch name hint: is subject to change. To configure the initial branch name to use in all hint: of your new repositories, which will suppress this warning, call: ... Y en el directorio actual aparecerá una carpeta oculta .git, que puedes ver con: ls -a El parámetro -a significa all y permite ver el sistema de archivos en modo extendido. Su contenido será: .  ..  .git Antes de crear commits, debemos configurar algunos datos básicos del usuario. Primero, el nombre: git config --global user.name "NAME" Luego el correo electrónico: git config --global user.email "NAME@HOST.COM" Llenar la rama master Usando archivos de texto simples, simularemos la adición de diferentes funciones al proyecto. Cada nueva función se representará como un commit separado. Crea un archivo para la primera función: nano function_1 Rellénalo con el siguiente contenido: Function 1 Ahora indexa los cambios: git add . Verifica el estado de indexación: git status En la consola debería aparecer un mensaje indicando los cambios indexados: On branch master No commits yet Changes to be committed: (use "git rm --cached <file>..." to unstage) new file: function_1 Ahora podemos hacer commit: git commit -m "commit_1" La consola mostrará un mensaje confirmando el commit exitoso en master: [master (root-commit) 4eb7cc3] commit_1  1 file changed, 1 insertion(+)  create mode 100644 function_1 Llenar la rama hypothesis Ahora crea una nueva rama llamada hypothesis: git checkout -b hypothesis El parámetro -b sirve para cambiar inmediatamente a la nueva rama. La consola mostrará un mensaje de confirmación: Switched to a new branch 'hypothesis' A continuación, debemos realizar tres commits consecutivos con tres archivos, igual que en master: commit_2 con el archivo function_2 y contenido: Function 2 commit_3 con el archivo function_3 y contenido: Function 3 commit_4 con el archivo function_4 y contenido: Function 4 Si luego comprobamos la lista de commits: git log --oneline La consola mostrará la siguiente secuencia: d3efb82 (HEAD -> hypothesis) commit_4 c9f57b7 commit_3 c977f16 commit_2 4eb7cc3 (master) commit_1 Aquí, la opción --oneline se usa para mostrar la información de los commits en formato resumido. Añadir un commit a la rama master El último paso es añadir otro commit a la rama principal master. Cambia a ella: git checkout master La consola confirmará el cambio: Switched to branch 'master' Crea otro archivo de función: nano function_5 Con el siguiente contenido: Function 5 Indexa los cambios: git add . Y haz el nuevo commit: git commit -m "commit_5" Si comprobamos la lista de commits: git log --oneline La rama master ahora tendrá dos commits: 3df7a00 (HEAD -> master) commit_5 4eb7cc3 commit_1 Combinar ramas con git rebase Para realizar el rebase, primero hay que cambiar a la rama hypothesis: git checkout hypothesis Y ejecutar el rebase: git rebase master Después, la consola mostrará un mensaje confirmando un rebase exitoso: Successfully rebased and updated refs/heads/hypothesis. Ahora puedes comprobar la lista de commits: git log --oneline La consola mostrará una lista con los commits de ambas ramas en el orden original: 8ecfd58 (HEAD -> hypothesis) commit_4 f715aba commit_3 ee47470 commit_2 3df7a00 (master) commit_5 4eb7cc3 commit_1 Ahora la rama hypothesis contiene el historial completo del repositorio. Resolución de conflictos Al igual que con git merge, al usar el comando git rebase pueden ocurrir conflictos que requieren resolución manual. Crea otro archivo en la rama hypothesis: nano conflict Y escribe el siguiente texto: There must be a conflict here! Indexa los cambios: git add . Haz un commit: git commit -m "conflict_1" Ahora cambia a la rama master: git checkout master Crea un archivo similar: nano conflict Y agrega el siguiente contenido: There must NOT be a conflict here! Indexa los cambios: git add . Haz un commit: git commit -m "conflict_2" Modifica nuevamente el archivo: nano conflict Cámbialo por: There definitely must NOT be a conflict here! Indexa y haz otro commit: git add . git commit -m "conflict_3" Cambia de nuevo a hypothesis y ejecuta: git checkout hypothesis git rebase master La consola mostrará un mensaje de conflicto: Auto-merging conflict CONFLICT (add/add): Merge conflict in conflict error: could not apply 6003ed7... conflict_1 hint: Resolve all conflicts manually, mark them as resolved with hint: "git add/rm <conflicted_files>", then run "git rebase --continue". hint: You can instead skip this commit: run "git rebase --skip". hint: To abort and get back to the state before "git rebase", run "git rebase --abort". Could not apply 6003ed7... conflict_1 Git sugiere editar el archivo de conflicto, indexar los cambios con git add y luego continuar con --continue. nano conflict El archivo contendrá dos versiones en conflicto dentro de marcadores especiales: <<<<<<< HEAD There definitely must NOT be a conflict here! ======= There must be a conflict here! >>>>>>> 6003ed7 (conflict_1) Nuestro trabajo es eliminar las partes innecesarias y dejar una versión final: There must absolutely definitely unanimously NOT be any conflict here! Indexa los cambios y continúa: git add . git rebase --continue Después de esto, la consola abrirá un editor de texto que te sugerirá modificar el mensaje de confirmación original de la confirmación donde ocurrió el conflicto: conflict_1 # Please enter the commit message for your changes. Lines starting # with '#' will be ignored, and an empty message aborts the commit. # # interactive rebase in progress; onto bd7aefc # Last commands done (4 commands done): # pick 8ecfd58 commit_4 # pick 6003ed7 conflict_1 # No commands remaining. # You are currently rebasing branch 'hypothesis' on 'bd7aefc'. # # Changes to be committed: # modified: conflict # La consola mostrará un mensaje indicando que el proceso de rebase se ha completado correctamente: [detached HEAD 482db49] conflict_1  1 file changed, 1 insertion(+), 1 deletion(-) Successfully rebased and updated refs/heads/hypothesis. Ahora, si revisas la lista de confirmaciones en la rama de hipótesis: git log --oneline Verás la secuencia original de todos los cambios realizados: 482db49 (HEAD -> hypothesis) conflict_1 bd5d036 commit_4 407e245 commit_3 948b41c commit_2 bd7aefc (master) conflict_3 d98648d conflict_2 3df7a00 commit_5 4eb7cc3 commit_1 Observa que las confirmaciones conflict_2 y conflict_3, realizadas en la rama master, aparecen en el historial antes que la confirmación conflict_1. Sin embargo, esto aplica a todas las confirmaciones realizadas en la rama master. Rebase de un repositorio remoto Además de trabajar con ramas locales, también es posible hacer rebase al extraer cambios de un repositorio remoto. Para ello, se añade la opción --rebase al comando pull: git pull --rebase remote branch Donde: remote es el repositorio remoto branch es la rama remota Básicamente, esta configuración de pull es equivalente a git rebase, salvo que los commits aplicados en la rama actual provienen del repositorio remoto. Principales ventajas de Git Rebase Historial lineal El comando git rebase permite crear un historial lineal en la rama de destino, compuesto por commits secuenciales. Esta secuencia sin ramificaciones hace que el historial sea más fácil de leer y entender. Menos conflictos  Ejecutar git rebase antes puede reducir significativamente la probabilidad de conflictos al fusionar ramas con git merge. Los conflictos son más fáciles de resolver en commits secuenciales que en uno solo de fusión. Esto es especialmente útil al enviar ramas a repositorios remotos. Desventajas de Git Rebase Modificación del historial A diferencia de merge, rebase reescribe parcialmente el historial de la rama de destino, eliminando elementos innecesarios. Riesgo de errores  La capacidad de reestructurar significativamente el historial puede causar errores irreversibles en el repositorio, lo que podría provocar la pérdida permanente de datos. Cuándo usar Git Rebase Git rebase es especialmente útil al trabajar en ramas pequeñas o de características individuales que finalmente se fusionarán en la rama principal. También es ideal para mantener un historial limpio y lineal, lo que resulta beneficioso en proyectos de código abierto o cuando es necesario un historial claro para depuración y comprensión. Sin embargo, en entornos colaborativos con varios desarrolladores, se debe usar con precaución para evitar problemas por reescritura de historial público. Es importante comunicar al equipo cuándo es apropiado rebasar. En muchos casos, git merge puede ser más seguro y simple. Consideraciones importantes Reescritura del historial Uno de los aspectos críticos de git rebase es que reescribe el historial de commits, lo que cambia los identificadores SHA-1. Esto puede generar problemas en entornos colaborativos, especialmente si se rebasea una rama que ya fue enviada a un remoto. Esto puede provocar conflictos al intentar hacer push. Evita rebasear ramas públicas Como práctica recomendada, evita hacer rebase a ramas públicas que ya han sido compartidas, ya que esto puede crear historiales divergentes y conflictos difíciles de resolver. Git rebase es más adecuado para ramas locales o para preparar una rama de funciones antes de fusionarla con la principal. Posibles conflictos Durante un rebase, si existen cambios conflictivos entre ramas, Git se detendrá y pedirá resolverlos manualmente. Aunque la resolución es similar a la de merge, puede requerir más trabajo, especialmente en ramas largas. Después de resolver los conflictos, puedes continuar con: git rebase --continue Conclusión Combinar dos ramas usando rebase, mediante el comando git rebase, es fundamentalmente diferente del merge clásico con git merge. git merge combina los commits de una rama en un solo commit dentro de otra. git rebase mueve los commits de una rama al final de otra, manteniendo el orden original. Un efecto similar se puede lograr usando git pull con la opción --rebase. Por un lado, git rebase permite mantener un historial más limpio y comprensible en la rama principal, mejorando la mantenibilidad del repositorio. Por otro lado, git rebase simplifica la historia eliminando algunos detalles, lo que puede reducir la trazabilidad de los cambios. Por esta razón, rebase es una herramienta pensada para usuarios experimentados que entienden cómo funciona Git. A menudo, git rebase se usa junto con git merge para lograr una estructura óptima del repositorio y las ramas.