Flujos de trabajo de Git

Qué es un flujo de trabajo de Git

Un flujo de trabajo de Git es un conjunto acordado de convenciones sobre cómo un equipo usa ramas, commits y fusiones para colaborar sin interferir entre sí. Git en sí no impone ninguna opinión — ofrece las herramientas pero no dicta cómo usarlas. Un flujo de trabajo llena ese vacío respondiendo preguntas prácticas: dónde vive el trabajo nuevo, cómo se revisa y cómo llega a producción.

Por qué es importante

Sin un flujo de trabajo compartido, un equipo cae rápidamente en el caos: trabajo a medias en la rama principal, conflictos de fusión inesperados y versiones difíciles de reproducir. Un buen flujo de trabajo mantiene la rama principal lista para publicar, convierte la revisión en un paso natural y da a todos el mismo modelo mental de dónde se encuentra el código en su camino.

El flujo de trabajo centralizado

El modelo más simple, y una buena base para entender el resto, es el flujo de trabajo centralizado: todos hacen commits directamente en una sola rama compartida (normalmente main). No hay ramas de funcionalidad — git pull y git push mantienen a cada desarrollador sincronizado con el repositorio central.

# Get the latest shared history before you start
git pull origin main

# ...make and commit your changes...
git add .
git commit -m "Add user profile page"

# Share your work; rebase on top of any new commits first
git pull --rebase origin main
git push origin main

Esto es fácil de entender, pero escala mal: cada commit aterriza en la única rama de la que dependen los compañeros de equipo, por lo que un cambio inacabado puede romper el trabajo de todos. Los flujos de trabajo que se describen a continuación resuelven esto aislando el trabajo en ramas primero.

Los flujos de trabajo más comunes

Estos cuatro enfoques se basan en la idea centralizada pero añaden aislamiento. Cada uno tiene diferentes compromisos entre simplicidad y estructura:

Una rama de funcionalidad en acción

En la práctica, la mayoría de los equipos comienzan con ramas de funcionalidad porque los comandos son familiares y el aislamiento es inmediato. El patrón es siempre el mismo: crear una rama desde main, hacer el trabajo y luego fusionarla de vuelta.

# Create and switch to an isolated branch
git switch -c feature/login

# ...edit files, then stage and commit...
git add .
git commit -m "Add login form"

# Bring the finished work back into main
git switch main
git pull origin main          # make sure main is current
git merge feature/login       # integrate the feature
git push origin main

La rama mantiene main lista para publicar mientras la funcionalidad está a medias, y ofrece a los revisores un conjunto de commits autocontenido para leer.

Pull requests sobre cualquier flujo de trabajo

En plataformas alojadas como GitHub, GitLab o Bitbucket, normalmente no se fusiona en local. En cambio, se sube la rama y se abre un pull request (o "merge request" en GitLab): un lugar para revisar el diff, ejecutar CI y discutir antes de que el código llegue a main.

git switch -c feature/login
# ...commit work...
git push -u origin feature/login   # push branch, set upstream
# then open a pull request in the web UI

Los pull requests no son un flujo de trabajo separado — son una puerta de revisión que se puede añadir encima del modelo de rama de funcionalidad, Gitflow, trunk-based o forking por igual.

Cómo elegir

Comienza con el flujo de trabajo más simple que se adapte a tu situación y añade estructura solo cuando sientas la necesidad de tenerla.

• Un equipo pequeño que despliega una aplicación web de forma continua se beneficia bien del enfoque de rama de funcionalidad o trunk-based.
• Un producto con versiones programadas se beneficia de las ramas explícitas de publicación y hotfix de Gitflow.
• Un proyecto de código abierto que recibe contribuciones de desconocidos necesita el modelo forking, porque los colaboradores no tienen acceso de escritura al repositorio principal.

Estos flujos de trabajo no son mutuamente excluyentes. Muchos equipos combinan ideas — por ejemplo, usando ramas de funcionalidad de corta duración con una mentalidad trunk-based, o pull requests encima de cualquiera de ellos.

El hilo conductor

Todos los flujos de trabajo aquí descritos se basan en los mismos elementos que ya has aprendido: git branch, git switch, git merge, git rebase y git push. El flujo de trabajo es simplemente una convención aplicada encima de esos comandos. Domina los comandos, acuerda las convenciones y la colaboración se vuelve significativamente más fluida.

Práctica