Existen varias formas posibles de trabajar en equipo con Git, acá vamos a presentar una que es bastante simple pero también muy poderosa, normalmente conocida como GitHub flow o feature branch flow.
Básicamente, se guia por tres principios:
- El código que está en la rama master siempre tiene que funcionar.
- Para comenzar una nueva funcionalidad, corregir un bug o cualquier tarea, se crea una rama nueva partiendo de master. El nombre de esta rama debe ser descriptivo:
busqueda-estudiante-por-legajo
,error-campos-numericos
,refactor-hibernate-stores
. - Concluido el trabajo, se crea un pull request para integrar los cambios a master.
Adicionalmente, podríamos configurar un servidor de integración continua para que despliegue nuestra aplicación bajo ciertas circunstancias. Por ejemplo:
- Cuando haya cambios nuevos en master, publicar la aplicación en el entorno de ensayo (staging).
- Cuando haya un tag nuevo, publicar la aplicación en el entorno de producción.
- Todos los lunes a las 9:00hs, publicar lo que haya en master en el entorno de producción.
Resumen de trabajo
Asumiendo que el backlog ya está completo, estos son los pasos que haría para ponerme a trabajar en una nueva funcionalidad:
- Elijo la user story en la que me voy a poner a trabajar (debería ser la más prioritaria).
- Me asigno la issue para que el resto del equipo sepa que lo voy a hacer yo.
- Muevo la issue a la columna En progreso.
- En mi computadora, creo la rama correspondiente, por ejemplo:
7-momento-de-crisis
o23-mejorar-vista-alumno
. Es buena práctica comenzar el nombre con el número de la issue asociada. - Trabajo. Si en el medio se mergea algún pull request, conviene bajar los cambios de
master
a mi rama. - Cuando terminé, hago un push y un pull request.
- Alguien mira mi trabajo, me pide cambios, los resuelvo y vuelvo a subir (el pull request sigue vivo y los cambios nuevos se reflejan automáticamente).
- Mi trabajo se aprueba y se integra en
master
. - En mi computadora, vuelvo a
master
y me bajo los cambios nuevos, que incluyen lo que hice yo. - Vuelvo al punto 1.
Recursos adicionales
- Cómo configurar la subida por SSH en GitHub: https://help.github.com/articles/generating-a-new-ssh-key-and-adding-it-to-the-ssh-agent/
- Artículo de Martin Fowler sobre integración continua (en inglés): https://www.martinfowler.com/articles/continuousIntegration.html
- Ejemplos de otros flujos de trabajo posibles (en inglés): https://www.atlassian.com/git/tutorials/comparing-workflows
- Tutorial interactivo sobre ramas (branches) en Git: https://learngitbranching.js.org/.