Git Commit; Unos hacks eficaces

#Git

Git commit es una de las características más subestimadas de Git. Haste una pausa por un momento y piensa con esas pocas neuronas que tienes;

1. ¿Cuándo fue la última vez que tuviste que revertir tu código a un punto anterior en el tiempo?
2. ¿Tuviste dificultades para encontrar ese commit que arruinó tu código?
3. ¿Fue por falta de claridad, mezclando los mensajes del commit?
4. Cuando encontraste ese commit, ¿también te diste cuenta de que incluyó varios cambios de archivos en ese commit en particular, lo que resultó en un dolor de cabeza al intentar volver a ingresar a ese commit?
   

Felicidades, acabamos de hacer la mayor aberración del mundo, incapacitados la mayor y milagrosa función de git ... Spoilers....

git-reset - Restablece la CABEZA actual al estado especificado

https://git-scm.com/docs/git-reset

La importancia de tener los commits limpios y ordenados.

Como desarrollador; hacker, estudiante o la wea fome que te quieras poner, una de las cosas más difíciles del mundo, jamás imposibles es la comunicación. Comunicarse con otro hermano tuyo de tu misma raza, cliente, gerente, jefe o un capa 8, o contigo mismo en un futuro no muy cercano.

Tener un historial de mensajes de git commit limpio significa que en cualquier momento en el futuro podrás revisar lo que se cambió en el código, qué partes de la funcionalidad se eliminaron y qué errores se corrigieron.

Al ejecutar git log, podrás ver un flujo lógico de mensajes que solo explican el historial de código completo de la aplicación. También puede ejecutar git log --pretty=oneline para ver una versión más densa de git log.

¿Cómo organizar un mensaje de commit?

Si utilizas una herramienta de gestión de proyectos como Jira , Asana , Trello u otra, y sigues un flujo de gestión de proyectos de desglose de tareas como Scrum o Kanban , tendrá todas sus tareas en un solo lugar, ordenadas y organizadas.
El objetivo debe ser que cada commit caracterice una subtarea correspondiente. No más git commit -m "Agregue código", git commit -m "Agregue CSS"o git commit -m "bugfix". Estos commit son imposibles de rastrear y nunca podrás usarlos en el futuro.

Entonces, ¿por qué tenerlos en primer lugar?

Cuando haya cambiado un montón de clases y estés listo para cometer el código, tómate un momento y piensa;

1. ¿Qué cambiaste en cada archivo? 
2. ¿Qué clases son relevantes para la funcionalidad de subtarea en la que trabajaste?
3. ¿Cómo se ve afectada la aplicación?
4. ¿Qué cambios de última hora introduje en el código?

Siguiendo un estilo de mensaje limpio 

Al elegir un estilo y seguirlo, llevas tu código a otro nivel.

Otros desarrolladores podrán leer tu historial de mensajes como una novela y nunca tendrán que mirar el código real (lo que ahorrará mucho tiempo).

También te obligarás a comprometer lo que importa, no lo que sea conveniente en el momento actual.

Finalmente, la guía de estilo.

Estructura del mensaje

Un mensaje de confirmación limpio debe constar de tres partes distintas separadas por una línea en blanco: el título (que describe el tipo de cambio de código) y un cuerpo descriptivo con mensajes opcionales sobre la tarea siguiente o la identificación del rastreador de problemas (pie de página).

El diseño debería verse así:

type:

body: (cambios, enlaces, atributos, etc.)

ID de rastreador de problemas (para referencia)

El type

Puede ser una abreviatura de lo que realmente es el commit. Por ejemplo (tomado de la guía de estilo de commit de Udacity ):

1. feat: Una nueva característica.
2. fix: corregir un error.
3. docs: cambios de la documentación.
4. style: estilo, formato, falta de punto y coma, etc; sin cambio de código.
5. refactor: refactorización del código de producción. 
6. test: agregamos tests, refactorizar test; no hay cambios de código de producción
7. chore: actualización de tareas de compilación, configuraciones de gestor de paquetes, etc; no hay cambio de código de producción.

El body

Cualquier cosa que el commit haya cambiado en el código. Puede ser una descripción de la funcionalidad agregada, una descripción de la tarea completada o los pasos de una solución y reproducción de errores.

Al componer el body, trata de ser lo más detallado posible. Piensa que hay una alta probabilidad de que estés leyendo este mensaje de confirmación dentro de dos años. ¿Qué te gustaría comunicar a tu futuro yo? Puedes agregar viñetas, listas, enlaces a las respuestas de Stackoverflow y enlaces a tu rastreador de problemas.

Ejemplo

type: resume los cambios en alrededor de 50 caracteres o menos


body: Texto explicativo más detallado, si es necesario. Envuélvalo a unos 72 caracteres más o menos. En algunos contextos, la primera línea se trata como el sujeto de la confirmación y el resto del texto como el cuerpo. La línea en blanco que separa el resumen del cuerpo es crítica (a menos que omita el cuerpo por completo); varias herramientas como `log`,` shortlog` y `rebase` pueden confundirse si ejecutas los dos juntos.

Explica el problema que este compromiso está resolviendo. Concéntrese en por qué está haciendo este cambio en lugar de cómo (el código lo explica). ¿Existen efectos secundarios u otras consecuencias no intuitivas de este cambio?
Aquí está el lugar para explicarlos.

Otros párrafos vienen después de líneas en blanco.

- Los puntos de bala también están bien.

- Normalmente, se utiliza un guión o un asterisco para la viñeta, precedido por un solo espacio, con líneas en blanco entre ellas, pero las convenciones varían aquí

Si utiliza un rastreador de problemas, ponga referencias a ellos en la parte inferior, como esto:

ID de rastreador de problemas:
Resuelve: # 123
Vea también: # 456, # 789

Conclusión

Ser capaz de componer significativas "git commit" no sólo le hará simpático a otros desarrolladores que van a leer sus confirmaciones. También te hará un mejor escritor, así como más analítico y limpio orientado al código.

FIN :)