GIT Guía Completa en Español – Comandos Avanzados de GIT

git rebase – Reorganizar commits

El comando git rebase es una herramienta poderosa pero potencialmente compleja que te permite modificar el historial de commits de una rama. En esencia, te permite “reubicar” una serie de commits de una rama sobre otra, creando un historial lineal y limpio.

¿Qué hace git rebase?

1. Identifica los commits a reubicar: Toma los commits de tu rama actual que no están presentes en la rama destino.
2. Aplica los commits en la rama destino: Aplica esos commits uno por uno sobre la punta de la rama destino, como si los hubieras hecho directamente en esa rama.
3. Crea nuevos commits: En lugar de modificar los commits originales, git rebase crea nuevos commits con los mismos cambios pero con nuevos identificadores (SHA-1).
4. Actualiza la rama actual: Mueve el puntero de tu rama actual para que apunte a la nueva serie de commits reubicados.

¿Cuándo usar git rebase?

• Limpiar el historial: Para reorganizar los commits de una rama, eliminar commits innecesarios o combinar varios commits en uno solo, creando un historial más lineal y fácil de entender.
• Integrar cambios de otra rama: En lugar de usar git merge, puedes usar git rebase para aplicar los cambios de otra rama sobre la tuya, evitando la creación de un commit de merge y manteniendo un historial lineal.
• Colaboración: Antes de hacer un git push a una rama compartida, puedes usar git rebase para reorganizar tus commits y facilitar la revisión de código y la integración de cambios.

Cómo usar git rebase:

1. Cambiar a la rama que quieres reubicar: Utiliza git checkout <nombre-rama> para moverte a la rama cuyos commits quieres reubicar.
2. Ejecutar el rebase: Escribe git rebase <nombre-rama-destino> y presiona Enter. Reemplaza <nombre-rama-destino> con el nombre de la rama sobre la cual quieres reubicar tus commits.

Ejemplo:

Consideraciones:

• Reescribe el historial: git rebase modifica el historial de commits, lo que puede causar problemas si otros desarrolladores ya están trabajando con los commits originales. Úsalo con precaución en ramas compartidas.
• Conflictos: Si hay conflictos entre tus commits y los de la rama destino, GIT detendrá el rebase y te pedirá que los resuelvas manualmente.
• Alternativa a git merge: git rebase puede ser una alternativa a git merge para integrar cambios, pero tiene implicaciones diferentes en el historial de commits. Elige la opción adecuada según tus necesidades y el flujo de trabajo de tu equipo.

git reset – Deshacer cambios

El comando git reset es una herramienta versátil pero potencialmente peligrosa que te permite deshacer cambios en tu repositorio. Puede mover el puntero HEAD, modificar el Staging Area e incluso revertir cambios en tu Working Tree. Es importante comprender sus diferentes modos de operación y usarlo con precaución, especialmente en ramas compartidas.

¿Qué hace git reset?

• Mueve HEAD: Cambia el puntero HEAD a un commit específico, modificando efectivamente la rama actual.
• Modifica el Staging Area: Puede eliminar archivos del Staging Area o incluso descartar cambios en el Working Tree, dependiendo del modo de operación utilizado.

Modos de Operación:

• --soft: Mueve HEAD al commit especificado, pero mantiene los cambios en el Staging Area y el Working Tree. Es útil para combinar varios commits en uno solo o modificar el mensaje de un commit reciente.
• --mixed (por defecto): Mueve HEAD al commit especificado, descarta los cambios del Staging Area y mantiene los cambios en el Working Tree. Es útil para deshacer git add o preparar un commit diferente.
• --hard: Mueve HEAD al commit especificado, descarta los cambios del Staging Area y sobrescribe los cambios en el Working Tree. Es útil para descartar todos los cambios no guardados y volver a un estado anterior del proyecto, pero ten cuidado, ya que los cambios en el Working Tree se perderán permanentemente.

¿Cuándo usar git reset?

• Deshacer commits: Para eliminar commits recientes de tu rama local (antes de hacer git push).
• Deshacer git add: Para quitar archivos del Staging Area sin perder los cambios en el Working Tree.
• Limpiar el Working Tree: Para descartar todos los cambios no guardados y volver a un estado anterior del proyecto (usa --hard con precaución).

Cómo usar git reset:

1. Identifica el commit al que quieres volver: Utiliza git log para encontrar el identificador del commit deseado.
2. Ejecuta el comando:
   • git reset --soft <identificador-commit>: Para deshacer commits manteniendo los cambios en el Staging Area y el Working Tree.
   • git reset <identificador-commit> o git reset --mixed <identificador-commit>: Para deshacer commits y git add, manteniendo los cambios en el Working Tree.
   • git reset --hard <identificador-commit>: Para descartar todos los cambios y volver al estado del commit especificado (¡cuidado, perderás cambios no guardados!).

Ejemplos:

Precauciones:

• Ramas compartidas: Evita usar git reset --hard en ramas compartidas, ya que puedes sobrescribir el trabajo de otros desarrolladores.
• Pérdida de datos: git reset --hard puede causar pérdida permanente de datos si no tienes cuidado. Asegúrate de entender lo que estás haciendo antes de usarlo.
• Alternativas más seguras: En muchos casos, es preferible usar git revert para deshacer commits de forma segura, ya que crea nuevos commits que revierten los cambios en lugar de modificar el historial existente.

git stash – Guardar cambios temporalmente

El comando git stash es como un cajón mágico donde puedes guardar temporalmente tus cambios sin necesidad de hacer un commit. Es útil cuando estás trabajando en algo y necesitas cambiar de rama o hacer un pull, pero no quieres perder los cambios que aún no están listos para ser incluidos en un commit.

¿Qué hace git stash?

• Guarda los cambios que tienes en tu Working Tree y en el Staging Area en un área de almacenamiento temporal llamada “stash”.
• Limpia tu Working Tree y el Staging Area, dejándolos como estaban en el último commit.
• Te permite cambiar de rama, hacer un pull o realizar otras operaciones sin preocuparte por tus cambios no guardados.
• Puedes recuperar tus cambios más tarde cuando estés listo para continuar trabajando en ellos.

¿Cuándo usar git stash?

• Cambio de contexto: Cuando necesitas cambiar de rama rápidamente pero tienes cambios no guardados que no quieres incluir en un commit todavía.
• Pull sin conflictos: Cuando quieres hacer un git pull pero tienes cambios locales que podrían generar conflictos. Puedes usar git stash, hacer el pull y luego recuperar tus cambios con git stash pop.
• Guardar trabajo en progreso: Cuando quieres guardar temporalmente una idea o un experimento que aún no está listo para ser committeado.

Cómo usar git stash:

• git stash: Guarda todos los cambios del Working Tree y del Staging Area en un nuevo stash.
• git stash list: Lista todos los stashes que has creado.
• git stash pop: Aplica el último stash creado y lo elimina de la lista de stashes.
• git stash apply: Aplica el último stash creado sin eliminarlo de la lista de stashes.
• git stash drop: Elimina el último stash creado.

Ejemplos:

Consideraciones:

• Stashes múltiples: Puedes crear varios stashes y gestionarlos con los comandos git stash list, git stash apply <número-stash> y git stash drop <número-stash>.
• Conflictos: Si al aplicar un stash surgen conflictos con los cambios actuales en tu Working Tree, GIT te pedirá que los resuelvas manualmente.
• Cambios en el Staging Area: git stash guarda tanto los cambios del Working Tree como los del Staging Area. Si solo quieres guardar los cambios del Working Tree, puedes usar git stash --keep-index o git stash -u.

git tag – Etiquetar commits

El comando git tag te permite crear etiquetas (tags) en puntos específicos del historial de tu repositorio, marcando commits importantes como versiones de lanzamiento, hitos del proyecto u otros eventos significativos. Las etiquetas actúan como referencias permanentes y amigables para esos commits, facilitando su identificación y acceso posterior.

¿Qué hace git tag?

• Crea una etiqueta (tag) que apunta a un commit específico.
• Las etiquetas pueden ser ligeras (lightweight) o anotadas (annotated).
  • Etiquetas ligeras: Son simplemente punteros a commits, sin información adicional.
  • Etiquetas anotadas: Contienen metadatos adicionales, como el nombre del etiquetador, la fecha, un mensaje y una firma GPG (opcional). Se consideran más completas y seguras.

¿Cuándo usar git tag?

• Versiones de lanzamiento: Para marcar commits que representan versiones estables de tu software, facilitando su identificación y descarga posterior.
• Hitos del proyecto: Para marcar puntos importantes en el desarrollo del proyecto, como la finalización de una funcionalidad clave o la corrección de un error crítico.
• Referencias permanentes: Para crear referencias amigables a commits específicos, en lugar de tener que recordar sus identificadores SHA-1 largos y complejos.

Cómo usar git tag:

1. Listar etiquetas:
   • git tag: Lista todas las etiquetas existentes en tu repositorio.
   • git tag -l "<patrón>": Lista las etiquetas que coinciden con un patrón de búsqueda específico.
2. Crear una etiqueta ligera:
   • git tag <nombre-etiqueta>: Crea una etiqueta ligera en el commit actual.
   • git tag <nombre-etiqueta> <identificador-commit>: Crea una etiqueta ligera en el commit especificado.
3. Crear una etiqueta anotada:
   • git tag -a <nombre-etiqueta> -m "Mensaje descriptivo": Crea una etiqueta anotada en el commit actual con el mensaje especificado.
   • git tag -a <nombre-etiqueta> <identificador-commit> -m "Mensaje descriptivo": Crea una etiqueta anotada en el commit especificado con el mensaje especificado.
4. Eliminar una etiqueta:
   • git tag -d <nombre-etiqueta>
5. Enviar etiquetas a un repositorio remoto:
   • git push origin <nombre-etiqueta>: Envía una etiqueta específica al repositorio remoto.
   • git push origin --tags: Envía todas las etiquetas al repositorio remoto.

Ejemplos:

git cherry-pick – Aplicar commits específicos de una rama a otra

El comando git cherry-pick te permite seleccionar uno o varios commits específicos de una rama y aplicarlos a otra rama. Es como tomar cerezas de un árbol y colocarlas en otro, permitiéndote incorporar cambios puntuales sin necesidad de fusionar ramas completas.

¿Qué hace git cherry-pick?

• Toma el commit especificado de una rama y crea un nuevo commit en la rama actual con los mismos cambios.
• El nuevo commit tendrá un identificador (SHA-1) diferente al commit original, pero contendrá los mismos cambios en los archivos.
• Preserva el autor y la fecha del commit original, pero registra la fecha actual como la fecha de aplicación del cherry-pick.

¿Cuándo usar git cherry-pick?

• Corrección de errores: Si has corregido un error en una rama de desarrollo y quieres aplicar esa corrección a la rama principal sin fusionar toda la rama de desarrollo.
• Funcionalidades específicas: Si quieres incorporar una funcionalidad específica de una rama a otra sin incluir todos los demás cambios de esa rama.
• Revertir cambios: Si accidentalmente hiciste un commit en la rama equivocada, puedes usar git cherry-pick para aplicar ese commit en la rama correcta y luego revertirlo en la rama original.

Cómo usar git cherry-pick:

• Identifica el commit que quieres aplicar: Utiliza git log para encontrar el identificador (SHA-1) del commit deseado.
• Cambia a la rama destino: Utiliza git checkout <nombre-rama-destino> para moverte a la rama donde quieres aplicar el commit.
• Ejecuta el cherry-pick: Escribe git cherry-pick <identificador-commit> y presiona Enter.

Ejemplo:

Consideraciones:

• Conflictos: Si el commit que estás aplicando entra en conflicto con los cambios existentes en la rama destino, GIT detendrá el cherry-pick y te pedirá que resuelvas los conflictos manualmente.
• Historial no lineal: El uso excesivo de git cherry-pick puede crear un historial de commits no lineal y difícil de seguir. Úsalo con moderación y considera otras opciones como git merge o git rebase cuando sea apropiado.
• Múltiples commits: Puedes aplicar varios commits a la vez usando sus identificadores separados por espacios: git cherry-pick <commit1> <commit2> <commit3>.

Lee el primer capítulo de esta guía aquí o lee la guía completa aquí.