remove - git tag best practices
¿Por qué se considera una buena práctica describir las confirmaciones de git en tiempo presente? (2)
Git es un VCS distribuido (sistema de control de versiones). Varias personas pueden trabajar en los mismos proyectos. Recibirá cambios de muchas fuentes.
En lugar de escribir mensajes que digan lo que ha hecho un committer. Es mejor considerar estos mensajes como las instrucciones de lo que se va a hacer después de aplicar la confirmación en el repositorio.
Entonces escribe un mensaje como este
Corregir error # 1234
En lugar de
Error reparado # 1234
Trate el registro de git no un historial de sus acciones, sino una secuencia de descripciones de lo que hacen todas las confirmaciones.
Hay un gran hilo en las noticias de los piratas informáticos al respecto. Allí obtendrá muchas más razones detrás de esta convención.
He leído todo tipo de tutoriales de Git, incluido el oficial, y todos parecen decirme que es una buena convención y práctica escribir notas de compromiso de Git en tiempo presente.
¿Porqué es eso? ¿Cuál es el razonamiento detrás de esto?
Es solo una convención (relativamente) común, de modo que los mensajes de confirmación en un proyecto se leen constantemente. El consejo para enviar parches a Git (por ejemplo) proviene de Documentation/SubmittingPatches .
- describir cambios en el estado de ánimo imperativo, por ejemplo, "hacer xyzzy do frotz" en lugar de "[este parche] hace xyzzy do frotz" o "[I] cambié xyzzy para hacer frotz", como si estuviera dando órdenes al código para cambiar su comportamiento .
Como se puede ver en el tema entre corchetes, esta convención elimina la necesidad de sujetos repetidos -o alternativamente implicados- para el verbo de compromiso que no brinden ningún beneficio útil.