Como cualquier cosa en desarrollo, las mejores prácticas son hasta cierto punto controvertidas. Pero desde algun punto debemos partir para adquirir un compromiso que unifique el trabajo de un equipo.
En este caso voy a hablar de los commit y ¿con que frecuencia he de hacerlos?.
Habrá quienes te digan que prefieren que se atómico, es decir, que represente exactamente una unida de trabajo (una tarea, task, una corrección de errores, bug). Si estas alineado con esta forma de trabajar, si te encuentras en medio de un trabajo y te hacen focalizarte en otro punto, no podrás hacer un commit, pero si podrás hacer un stash. Como bien sabes un stash sirve para dejar los ficheros en que estás trabajando archivados para retomarlos posteriormente.
Esto es una forma de trabajo muy lícita, pero yo sostengo otra bien distinta: realiza commit pequeños y a menudo.
Los commit no suponen esfuerzo en Git, con un interactive rebase que te permite hacer un squash de todos los commit juntos. Por tanto, si estás trabajando en una funcionalidad y realizas cuatro commit provisionales antes de finalizar, podrás agruparla en un unico commit. Esto es lo mejor de los dos mundos: asegura tu trabajo temporal, puedes probar y volver para atrás sin ningún miedo, ya que en vez de hacer cuatro commit en el servidor, solo habrá uno.
Esto nos lleva la mantener limpio el historial.
Yo como desarrollador y hablando desde la esperiencia, lo primero que intento es revisar el historial y luego entro en cada una de las que me interesan. Para mí es desesperante no poder hacer esto, más aún cuando varios equipos mezclan la linea temporal con sus commit y resulta imposible desde eliminar la funcionalidad hasta como entenderla.
Me molesta por qué muchas veces no puedes ver una funcionalidad de una sola vez, tienes que ir buscando y buscando, se entremezclan funcionalidades, en fin. Un arduo trabajo máxime cuando en mi vida profesional he llegado a ver más de un més sin hacer un merge con más de 600 commit de una funcionalidad entremezclada entre otras 4. Si estás trabajando con linea de comando y te cuesta, con las PR de Azure DevOps o GitHub o GitLab te puede ayudar mucho o bien usar una herramienta visual, yo uso: GitKraken.
Y como una cosa lleva a la hora, la limpieza esta también en los mensajes de los commit. Son muy importantes para cualquiera. Como siempre digo, para mi, para mis compañeros y para mí yo del futuro.
Por convención, los mensajes han de ser imperativos y deben indicar exactamente que hacen:
- Fix measures //bad
- Fix output measures in helloworld.cs //good
Cuando trabaja con Azure DevOps, puedes ayudarte (ir a los enlaces):
Y como punto final a mí me gusta decirles a las personas que trabajan en mi equipo:
Si no subes tus commit, tus ramas y se quedan en local, es como si no hubieras trabajado
¿Cuántas veces se pierde código por tenerlo en local y no realizar la buena práctica de ir subiendo al repo cada poco tiempo?