-
La rama de entorno de desarrollo es
master
. Sin embargo, no es un "work in progress". El desarrollo real se realiza en "feature branchs", cuyos cambios se pasan a master una vez finalizada la funcionalidad. -
Para casos en que es necesario un "hotfix", realizar el cambio directamente en la revisiones correspondientes a los entornos
staging
oproduction
(según sea el caso) e incorporar inmediatamente los cambios amaster
. -
Siempre que sea posible, integrar los cambios upstream con
git pull --rebase
para mantener una historia lineal de cambios. -
Nunca realizar
rebase
sobre commits que ya han sido compartidos.
- En inglés.
- Utilizar mensajes descriptivos que expliquen el porqué del cambio. Si es necesario, explicar posibles consecuencias del cambio y el cómo se ha implementado sin ser necesario entrar en detalles.
- Utilizar formato 50/72: 50 caracteres como máximo para la primera línea, una línea en blanco a continuación y 72 caracteres como máximo para las siguientes.
-
Referenciar la issue a la que el commit hace referencia. Por ejemplo:
#122
. -
Aprovechar las funcionalidades de github para cerrar la issue directamente desde el mensaje. Por ejemplo:
Closes #122
Esto se puede automatizar mediante hooks de git, siguiendo cierta convención a la hora de nombrar la feature branch.