Cuando hacer un commit y como hacerlo

Cuando hacer un commit y como hacerlo

Según mi experiencia en estos años usando control de versiones, y colaborando y siguiendo varios proyectos, he ido modificando mi manera de trabajar, según voy usándolo.

Aclaro que cada cual puede trabajar de la manera que mejor le convenga, pero está claro, que en los proyectos donde trabajan varios usuarios, es necesario al menos establecer unas normas, por el bien común de todos los integrantes y de los futuros que puedan incorporarse.

Así, podemos establecer un sistema de obligado cumplimiento por los miembros del proyecto.

Las reglas básicas del commit

• Una funcionalidad, un commit. Usa ramas locales para ello. Después fusiona con la rama que vas a usar para subir tus cambios al repositorio remoto.

• Evitar a toda costa hacer commits enormes, que corrigen un sinfín de cosas, con o sin relación alguna entre ellos.

¿ Parece una cosa muy fácil ?  No creas. 

El humano está acostumbrado a los malos hábitos, adquiridos con los años de esfuerzo en hacer las cosas diferentes al resto, y cambiar esto, va a costar.

¿ Que aporta esto ?

• Mejora el encontrar posibles errores y su posterior corrección se torna muy simple, sobretodo , a la hora de fusionar por ejemplo la rama hotfix con la rama de producción.

Al tener, en principio, muy pocos cambios, será más sencilla su fusión.

• La historia es mucho más simple , y el seguimiento será mucho más simple, sobretodo , para futura gente que se una al proyecto.

Pero a la hora de hacer el commit , tenemos que documentar que es.

Las reglas básicas del log

• Si se usa un sistema de ticket , hacer referencia en el mensaje. Esto aporta mucho más información, que nos servirá posteriormente a la hora de tratar con la información.

• Podemos usar una plantilla en git a través de los hooks, pero a grandes rasgos podemos simplificarlo cumpliendo este patrón:
  [DESCRIPCION CORTA] Obligatorio.
  [DEJAR ESPACIO EN BLANCO] Opcional.
  [DESCRIPCION LARGA] Opcional.

Es importante en el commit, identificar para un futuro que es lo que se realizado o solucionado.

Recordad, no estamos solos nosotros, por lo tanto, si hacemos un commit de 100 cambios, y cada fichero tiene inserciones, borrados, etc.., solo el programador que subió los cambios va a saber de que va todo esto. 

El resto , si se lo mira, lo tiene fácil, este marrón no me lo voy a comer, porque no tengo NI IDEA de lo que hace.

¿ Alguien aplica otros criterios ?