Una rama por ticket: así siempre sabes dónde está el código
Un bug vuelve a aparecer y nadie recuerda en qué rama estaba el arreglo. Un cliente pregunta si su petición ya está en producción y pasas diez minutos buscando en Git. Con unos pocos acuerdos fijos sobre ramas y commits, eso se acaba. Así se configura.
1.Un ticket, una rama
Empieza cada tarea desde un ticket. Si el trabajo es demasiado grande para una rama, el ticket es demasiado grande: divídelo en subtareas, cada una con su propio número. Así una pull request sigue siendo lo bastante pequeña para revisarla bien.
2.El número de ticket en el nombre de la rama
Acordad un formato fijo, como feature/ASUP-12-descripcion-corta o fix/ASUP-14-ideal-callback. El prefijo indica el tipo de trabajo y el número, a qué ticket pertenece. Las herramientas que reconocen el número pueden vincular la rama automáticamente.
3.El número en cada commit
Pon el número de ticket al principio del mensaje de commit: ASUP-12 validar formulario de inicio de sesión. Aunque un commit acabe después en otra rama, verás a qué ticket pertenece. Con los smart commits actualizas el ticket a la vez, por ejemplo con #time 45m o #review.
4.Las pull requests actualizan el ticket
Haz que al abrir una pull request el ticket pase a In Review, y que un merge marque la rama como fusionada. Así el estado del tablero es correcto sin que nadie tenga que acordarse.
5.Compruébalo en la revisión
Incluye en vuestras normas de revisión que el número de ticket esté en la rama y en los commits. Una pull request sin ticket se devuelve. En pocas semanas, todo el mundo lo hace sin pensar.
En resumen
- Un ticket, una rama
- El número de ticket en el nombre de la rama
- El número en cada commit
- Las pull requests actualizan el ticket
- Compruébalo en la revisión