git-style-guide.md

Guía de estilos para commits en git

¿Cuándo hacer commits?

Decidir cúando se debe hacer commits es un skill que se aprende con la experiencia.

Un commit debe tener sentido por si mismo, no debe presentar fallos de pruebas al compilar y debe aportar algún valor a la base de código.

Un commit debe recoger cambios que tengan relación. Por ejemplo, corregir dos bugs diferentes se debe reflejar en dos commits diferentes.

Crear Commits grandes o excesivamente pequeños dificultad que otros desarrolladores comprendan los cambios y los reviertan.

¿Con qué frecuencia hacer commits?

Hay que encontrar un enquilibrio también en la frecuencia:

Desventajas poca frecuencia

• Más dificiles de revisar porque todos los cambios se agrupan
• Ensucia el historial de código fuente
• Retrasa que otros compañeros vean tu trabajo y se beneficien de él

Ejemplo poca frecuencia

Único commit:

1. Refactoring, reformatting and add navbar

Desventajas mucha frecuencia

• Crea una historia confusa con commits con poco sentido.
• Problemas al revertir cambios o encontrar el commit exacto donde empieza un cambio.

#### Ejemplo mucha frecuencia

1. refactor: component app
2. refactor: component header
3. style: formatting components
4. style: more formatting components
5. feat: import navbar from bootstrap
6. feat: add navbar
7. feat: setting navbar

Ventajas de un buen equilibrio

• Deja un historial limpio
• Los commits son fáciles de revisar
• Otros desarrolladores pueden beneficiarse. Por ejemplo de la refactorización que hayas hecho antes de añadir la feature.
• Es facil revertir a un cambio que pueda necesitar. Por ejemplo al punto donde un código se refactorizó y se formateó, antes de empezar a agregar el navbar.
• Los tres commits no deberían romper pruebas de código existentes

Ejemplo buen equilibrio

1. refactor: current header
2. style formatting header
3. feat: add navbar to header

## No crear commits con cambios incompletos

Crear commits solo cuando se complete un componente lógico.

Dividir la implementación de bloques funcionales en partes lógicas permite que se puedan completar y grabar sus commits con frecuencia.

Si tienes necesidad de crear un commit solo para guardar una copia de los cambios usa la función stash de git.

Probar el código antes de hacer commits

Pruébelo a fondo para asegurarse de que realmente esté completo y no tenga efectos secundarios para los que se actualicen los cambios.

Escribir buenos mensajes de commits

Formato

{type}: {subject}

Reglas

Asunto {subject}

• No más de 60 caracteres
• Describir de forma breve, precisa y concisa el cambio añadido. Evitar palabras de relleno.
• Expresado en imperativo
  • fix: bug on navbar (good)
  • fixed bug on navbar (bad)
• Primera letra en minúscula
• No finalizar en punto '.' ni usar otros signos de puntuación

Tipos {type}

• feat -> nuevas features
• fix -> corregir errores
• docs -> documentación
• style -> actualizar o limpiar estilo del código
• refactor -> Restructurar código sin cambiar su comportamiento
• test -> Añadir tests
• chore -> Tareas de mantenimiento
• init -> initial commit
• rearrange -> Reorganizar, mover, eliminar archivos, etc.
• update -> Actualizar código, versiones y librerias compatibles.