8. Mejores Prácticas y Casos Especiales

Para terminar vamos a listar algunos consejos que te vendrán bien en tu día a día con Git.

Commits atómicos y bien documentados

Un commit atómico hace UNA cosa y la hace bien.

❌ Mal commit:

git commit -m "arreglos varios"
# Cambios: corrige bug, añade funcionalidad, actualiza docs, refactoriza código

✅ Buen commit:

git commit -m "fix: corrige error de autenticación en login"
# Solo cambios relacionados con el bug de autenticación

git commit -m "feat: añade botón de exportar a CSV"
# Solo el botón de exportar

git commit -m "docs: actualiza guía de instalación"
# Solo documentación

Escribir buenos mensajes de commit

Por convención, un buen mensaje de commit tiene la siguiente estructura:

tipo(ámbito): descripción corta (50 chars máx)

Cuerpo explicativo más detallado (72 chars por línea).
Explica QUÉ y POR QUÉ, no cómo.

Puede tener múltiples párrafos.

- Viñetas también están bien
- Usa guión o asterisco

Referencias a issues al final.
Fixes #123
See also #456, #789

Por ejemplo:

feat(auth): añade autenticación con OAuth

Implementa autenticación usando OAuth 2.0 para permitir
login con Google y GitHub.

Cambios:

- Añade dependencia passport-oauth2
- Crea middleware de autenticación
- Actualiza rutas de login
- Añade tests de integración

Esta funcionalidad fue solicitada por múltiples usuarios
y mejorará la experiencia de onboarding.

Fixes #234
Related to #189

Según Tim Pope hay 7 reglas para escribir buenos mensajes de commit:

  1. Separa asunto del cuerpo con una línea en blanco
  2. Limita el asunto a 50 caracteres
  3. Capitaliza el asunto
  4. No termines el asunto con punto
  5. Usa modo imperativo en el asunto
  6. Envuelve el cuerpo a 72 caracteres
  7. Usa el cuerpo para explicar qué y por qué, no cómo

No hace falta seguirlas todas al pie de la letra, pero mantenerlas en mente mejorará la calidad de tus commits.

Mantener un historial limpio

git rebase: Reescribe el historial de commits.

# Rebase interactivo de los últimos 3 commits
git rebase -i HEAD~3

Verás algo como:

pick a1b2c3d feat: añade login
pick e4f5g6h fix: corrige typo
pick i7j8k9l refactor: limpia código

# Comandos disponibles:
# p, pick = usar commit
# r, reword = usar commit, pero editar mensaje
# e, edit = usar commit, pero parar para enmendar
# s, squash = usar commit, pero fusionar con el anterior
# f, fixup = como squash, pero descartar mensaje
# d, drop = eliminar commit

Útil para:

  • Combinar commits relacionados
  • Editar mensajes de commit
  • Reordenar commits
  • Eliminar commits innecesarios

NUNCA hagas rebase de commits ya pusheados en main o compartidos con otros.

git stash: Guardar cambios temporalmente

En algunos casos necesitas cambiar de rama, sincronizarla, pero tienes cambios sin commitear. git stash te permite guardar esos cambios temporalmente y recuperarlos después.

# Tienes cambios sin commitear pero necesitas cambiar de rama
git status
# modified: archivo.js

# Guardar cambios temporalmente
git stash

# Ahora puedes cambiar de rama
git switch otra-rama

# Cuando vuelvas
git switch mi-rama
git stash pop  # Recupera y elimina del stash

# Ver stash guardados
git stash list

# Aplicar sin eliminar
git stash apply

# Guardar con mensaje
git stash save "WIP: implementando feature X"

# Limpiar todos los stash
git stash clear

Una alternativa sería crear una rama temporal, commitear ahí, para luego fusionarla o rebasearla más tarde.

git reset: Deshacer cambios

Puedes deshacer cambios en diferentes niveles: deshacer staging, deshacer commits, o deshacer TODO.

# Deshacer staging (mantiene cambios en archivos)
git reset HEAD archivo.js

# Deshacer último commit (mantiene cambios en archivos)
git reset HEAD~1

# Deshacer último commit (mantiene cambios en staging)
git reset --soft HEAD~1

# Deshacer TODO (¡PELIGROSO!)
git reset --hard HEAD~1

Diferencias:

  • --soft: Deshace commit, cambios quedan en staging. Tus archivos quedan listos para commitear de nuevo.
  • --mixed (default): Deshace commit y staging, cambios en working directory. Tus archivos quedan modificados pero no staged.
  • --hard: Deshace TODO, los cambios se pierden. Tus archivos vuelven al estado del commit.

git revert: Deshacer commits de forma segura

Si has subido, o sincronizado, tus cambios con GitHub (o Git Hosting) y necesitas deshacer un commit es posible solucionarlo con git revert. Crea un nuevo commit que "deshace" los cambios del commit anterior. Será visible en el historial y no causará problemas a otros colaboradores.

# Deshacer un commit específico
git revert abc1234

# Deshacer múltiples commits
git revert abc1234..def5678

# Revertir sin crear commit automáticamente. Útil para agrupar varios reverts en uno solo.
git revert -n abc1234

git cherry-pick: Aplicar commits específicos

Sirve para fusionar un commit específico de una rama a otra sin necesidad de hacer un merge completo.

# Aplicar un commit de otra rama
git cherry-pick abc1234

# Aplicar varios commits
git cherry-pick abc1234 def5678

# Aplicar un rango
git cherry-pick abc1234..def5678

El uso más común es para aplicar correcciones de bugs. Hay un commit en la rama develop que arregla un bug crítico y quieres aplicarlo a la rama main sin fusionar todo el desarrollo.

Mantener tu fork actualizado

# Añadir upstream (si no lo has hecho)
git remote add upstream git@github.com:original/repo.git

# Fetch cambios
git fetch upstream

# Actualizar tu main local
git switch main
git merge upstream/main

# Actualizar tu fork en GitHub
git push origin main

# Actualizar una rama de feature
git switch feature/mi-feature
git merge main
# o mejor
git rebase main

This work is under a Attribution-NonCommercial-NoDerivatives 4.0 International license.

Will you buy me a coffee?