Flujos de trabajo de Git

Cómo organizan los equipos ramas, revisiones y versiones. Cada flujo de trabajo viene con sus reglas tal como las formula su fuente original, cuándo encaja y un recorrido animado, ejecutado por el simulador de Git y verificado con el Git real.

Flujo de trabajoRamas de larga duraciónCómo se publicaIdeal para
mainDesplegar main tras cada pull request fusionadaAplicaciones con despliegue continuo
main, developRamas de release, etiquetadas en mainSoftware con versiones, varias versiones mantenidas
main (the trunk)Desde el tronco o una rama de release de corta duraciónEquipos de CI/CD que integran a diario
upstream’s mainLos mantenedores fusionan pull requests desde forksCódigo abierto, colaboradores sin permiso de escritura

GitHub flow

Una rama main + ramas de corta duración + pull requests

Un flujo ligero basado en ramas. Todo lo que está en main se puede desplegar; cada cambio se hace en su propia rama con un nombre descriptivo, se fusiona en main mediante una pull request revisada y se despliega.

Las reglas

  1. Todo lo que está en la rama main se puede desplegar.
  2. Crea una rama con un nombre descriptivo a partir de main para cada cambio.
  3. Haz commit en local y sube con frecuencia a la rama del mismo nombre.
  4. Abre una pull request para pedir opiniones o cuando la rama esté lista para fusionarse.
  5. Fusiona en main tras la revisión y luego borra la rama.
  6. Despliega en cuanto se fusione (en el artículo original: «puedes y debes desplegar de inmediato»).

✓ Úsalo cuando

Aplicaciones web y servicios que se despliegan de forma continua a partir de una sola versión.

✗ Evítalo cuando

Tienes que mantener varias versiones publicadas en paralelo.

Fuentes

Abrir y fusionar la pull request ocurre en GitHub; el recorrido muestra las operaciones de Git equivalentes (el botón de merge por defecto de GitHub crea un commit de merge).

Pon en marcha el flujo de trabajo y recórrelo una vez.

TUS ARCHIVOS: UN ARCHIVO, TRES LUGARESDirectoriotu discoPreparaciónpróximo commitHEADúltimo commitadd ›commit ›GITUALIZE☁ ORIGIN: github.com/acme/shop (otro repositorio)TU REPOSITORIO: .git en tu portátil2e039acAdd homepage2e039ac897849007af489a58ee9eec107a21974e Add homepageb272b3aSet up projectb272b3abaca08f2f1c56c0562679f66a61035535 Set up project129c2dbInitial commit129c2db06bfe68f8469dc82e6e05d1c03d1f768c Initial commit2e039acAdd homepage2e039ac897849007af489a58ee9eec107a21974e Add homepageb272b3aSet up projectb272b3abaca08f2f1c56c0562679f66a61035535 Set up project129c2dbInitial commit129c2db06bfe68f8469dc82e6e05d1c03d1f768c Initial commitmainmain: una etiqueta móvil sobre un commitorigin/mainorigin/main: tu marcador LOCAL de dónde estaba la rama de origin en tu último fetch/pushHEADHEAD → la rama en la que estásmainmain: tal como existe EN originREADME.mdsin cambiosapp.jssin cambiosindex.htmlsin cambiosv1v1v1v1v1v1v2v2v2HEAD → main → 2e039ac “Add homepage”
0.0s / 142s
commitanillo = el commit donde está HEADinalcanzable (aún existe)rama = etiqueta que se mueveorigin/* = tu marcador del remotoHEAD = dónde estás

  1. 1 Crear una rama

  2. 2 Hacer cambios

  3. 3 Crear un pull request

  4. 4 Atender los comentarios de revisión

  5. 5 Integrar tu pull request

  6. 6 Borrar tu rama