- Realizar commits atómicos El enfoque atómico supone lo siguiente.
- Confirmar (commitear) cada modificación o tarea como un cambio separado.
- Confirmar solo cuando se complete un bloque de trabajo.
- Confirmar cada cambio de diseño por separado, con confirmación conjunta para: archivos de diseño, código subyacente y recursos adicionales.
Beneficios del enfoque atómico
- Es fácil de revertir un commit sin afectar a otros cambios.
- Es fácil hacer otros cambios sobre la marcha.
- Hay facilidad de combinación con otras ramas (sin que se produzcan conflictos).
Este enfoque es equivalente al concepto de transacción en bases de datos.
Una recomendación derivada de esto es:
- No hacer commits de trabajos a medias
Por otra parte, también se recomienda realizar commits frecuentemente:
- Un commit temprano ayuda a reducir el riesgo de conflictos entre dos cambios simultáneos.
- Además, tener puntos de control periódicos, significa que puedes comprender cuando algo dejó de funcionar.
Esta recomendación puede parecer que entra en contraposición con lo que he explicado arriba, pero para cumplir ambas recomendaciones, lo que podemos hacer es crear commits localmente “todo el tiempo” y push cuando todo esté funcionando.
-
Probar los cambios antes de hacer commits: Siempre es bueno probar los cambios antes de enviarlos al repositorio local. Las pruebas son esencialmente una capa adicional de seguidad antes de confimar, Permiten identificar errores y fallos más rápido antes de que vayan al servidor de producción.
-
Escribir mensajes de confirmación útiles: Hay dos cualidades importantes de un mensaje de commit: el mensaje de confirmación debe ser sencillo. Y debería ser significativo.
Crear mensajes de confirmación útiles es una de las mejores cosas que se puede hacer. Es bueno para los demás compañeros de trabajo y para nosotros mismos.
- Usar diferentes ramas: Las ramas pueden permitir tener múltiples visiones del código en un solo repositorio. Git simplificó la comparación de código entre dos ramas. También sirven para separar desarrollos largos (de muchos commits) sin que interfieran con la rama principal (feature-branching)
El concepto feature-flagging implica tener banderas (flags) que activan/desactivan funciones (o las activan para unos usuarios sí y para otros no) mientras el código no esté desarrollado completo.
- Usar un flujo de trabajo (workflow) común: Esto supone establecer una serie de reglas para que todos los miembros del equipo apliquen homogéneamente el flujo de cambios.
De esta forma no interferiremos en el trabajo de los demás, mejoraremos nuestro propio trabajo y tendremos un seguro de que si algo falla siempre podremos volver en el tiempo para recuperarlo.