Guía de Flujo de Trabajo con Git: Ramas, Fusiones y Colaboración en Equipo

Git es la base del flujo de trabajo de todo equipo de software moderno. Sin embargo, muchos desarrolladores solo usan commit, push y pull, dejando de lado las funciones que hacen que el desarrollo colaborativo sea fluido y libre de conflictos. Esta guía cubre las estrategias de ramificación, las prácticas de commits y los comandos cotidianos que utilizan los equipos profesionales.

El modelo mental fundamental

Git es un grafo acíclico dirigido de instantáneas (commits). Cada commit apunta a su(s) padre(s). Las ramas son simplemente punteros con nombre hacia commits — ligeros y fáciles de crear.

main:    A → B → C → D
feature:         C → E → F

Crear una rama no copia archivos — solo crea un nuevo puntero. Por eso crear una rama tarda milisegundos independientemente del tamaño del repositorio.

Estrategias de ramificación

GitHub Flow (simple, entrega continua)

Ideal para equipos que despliegan con frecuencia:

1. main siempre está listo para desplegar
2. Crea una rama de funcionalidad para cada cambio
3. Abre un pull request cuando esté listo para revisión
4. Fusiona a main tras la aprobación
5. Despliega de inmediato

git checkout -b feature/add-user-auth
# ... realiza cambios ...
git push origin feature/add-user-auth
# Abre PR → revisión → fusión → despliegue

Git Flow (lanzamientos estructurados)

Ideal para productos con versiones de lanzamiento (aplicaciones, librerías):

• main — solo código en producción
• develop — rama de integración
• feature/* — nuevas funcionalidades (rama desde develop)
• release/* — preparación de lanzamientos (rama desde develop)
• hotfix/* — correcciones urgentes en producción (rama desde main)

Es más estructurado pero añade sobrecarga. Usa GitHub Flow a menos que tengas una necesidad real de gestión de lanzamientos paralelos.

Desarrollo basado en Trunk

Los desarrolladores hacen commits directamente a main (o ramas de muy corta duración < 1 día). Los feature flags controlan lo que ven los usuarios. Requiere un CI/CD sólido y buena cobertura de tests. Utilizado por Google, Facebook y equipos de alto rendimiento.

Cómo escribir buenos mensajes de commit

El mensaje de commit es una carta para tu yo del futuro (y para tus compañeros). Sigue el formato Conventional Commits:

<tipo>(<ámbito>): <resumen breve>

<cuerpo opcional — qué y por qué, no cómo>

<pie opcional — cambios incompatibles, referencias a issues>

Tipos:

• feat — nueva funcionalidad
• fix — corrección de errores
• docs — solo documentación
• refactor — cambio de código que ni corrige un error ni añade una funcionalidad
• test — añadir o corregir tests
• chore — proceso de construcción, dependencias, herramientas

Ejemplos:

feat(auth): add JWT refresh token rotation

Implements sliding session windows using refresh token rotation.
Previous tokens are invalidated on use to detect theft.

Closes #142

fix(api): return 404 instead of 500 for missing user

The /users/:id endpoint was throwing an unhandled exception when
the user didn't exist. Now returns a proper 404 with error message.

Regla general: Si tu mensaje de commit es fix stuff o WIP, tu equipo te odia. Hazlo descriptivo.

Merge vs. Rebase

Merge

git checkout main
git merge feature/my-feature

Crea un commit de fusión que une dos ramas. Preserva el historial completo — puedes ver exactamente cuándo las ramas divergieron y se fusionaron.

A → B → C → M (commit de fusión)
         ↑   ↑
         E → F (feature)

Usa merge para: integrar ramas de larga duración, preservar el contexto en el historial.

Rebase

git checkout feature/my-feature
git rebase main

Reproduce tus commits sobre la rama destino. Crea un historial lineal — parece como si la funcionalidad hubiera sido construida sobre el último estado de main.

Antes: A → B → C (main)
                ↑
           D → E (feature, basado en B)

Después: A → B → C → D' → E' (feature rebasado sobre C)

Usa rebase para: limpiar commits locales antes de un PR, mantener las ramas de funcionalidad actualizadas.

Regla de oro: Nunca hagas rebase de commits que ya han sido enviados a una rama compartida. El rebase reescribe el historial — rompe las ramas locales de otras personas.

Rebase interactivo: limpiando el historial

Antes de abrir un PR, aplasta y corrige commits desordenados de trabajo en progreso:

git rebase -i HEAD~4   # edita interactivamente los últimos 4 commits

Opciones en el editor interactivo:

• pick — mantener el commit
• squash — fusionar con el commit anterior, combinar mensajes
• fixup — fusionar con el commit anterior, descartar el mensaje
• reword — mantener los cambios, editar el mensaje
• drop — eliminar el commit por completo

Gestión de conflictos

Los conflictos ocurren cuando dos ramas modifican las mismas líneas. Git los marca así:

<<<<<<< HEAD (tu rama)
const timeout = 5000;
=======
const timeout = 3000;
>>>>>>> feature/update-timeouts

Resuélvelos editando el archivo al estado correcto (eliminando los marcadores), y luego:

git add src/config.ts
git merge --continue   # o git rebase --continue

Prevenir es mejor que curar:

• Haz pull desde main con frecuencia para mantener las ramas de corta duración
• Comunícate con tus compañeros cuando trabajes en los mismos archivos
• Mantén los PRs pequeños — los PRs grandes tienen más conflictos y revisiones más difíciles

Comandos esenciales del día a día

# Iniciar una nueva funcionalidad
git checkout -b feature/my-feature

# Agregar cambios específicos al stage (no el archivo completo)
git add -p

# Ver cambios sin stage
git diff

# Ver cambios en stage
git diff --staged

# Modificar el último commit (antes de hacer push)
git commit --amend --no-edit

# Guardar temporalmente trabajo sin commitear
git stash
git stash pop

# Encontrar qué commit introdujo un error (búsqueda binaria)
git bisect start
git bisect bad              # el commit actual es malo
git bisect good v1.2.0      # último commit bueno conocido

# Recuperar una rama eliminada o un commit perdido
git reflog

# Ver un gráfico visual de las ramas
git log --oneline --graph --all

Buenas prácticas para pull requests

Un buen PR:

• Hace una sola cosa — los revisores pueden entender el cambio completo
• Tiene una descripción clara — qué cambió, por qué y cómo probarlo
• Es pequeño — < 400 líneas de diff como objetivo aproximado
• Pasa el CI — nunca pidas revisión con una build rota
• Enlaza al issue — Closes #42 cierra el issue automáticamente al fusionar

Usa nuestro README Generator para generar documentación junto con tus cambios de código.

Lo esencial de .gitignore

Añade siempre esto a .gitignore:

# Variables de entorno
.env
.env.local
.env.*.local

# Dependencias
node_modules/
vendor/

# Salida de compilación
dist/
build/
.next/

# Archivos del sistema operativo
.DS_Store
Thumbs.db

# Archivos del editor
.vscode/settings.json
.idea/
*.swp

Genera un .gitignore específico para tu proyecto en gitignore.io — conoce cientos de lenguajes y herramientas.

El dominio de Git se acumula con el tiempo. Aprende el modelo mental, adopta buenos hábitos de commit, y la colaboración de tu equipo mejorará de forma notable.