¿Por qué se considera una buena práctica describir las confirmaciones de git en time presente?

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 time presente.

¿Porqué es eso? ¿Cuál es el razonamiento detrás de esto?

Git es un VCS distribuido (sistema de control de versiones). Varias personas pueden trabajar en los mismos proyectos. Recibirá cambios de muchas fonts.
En lugar de escribir posts que digan lo que ha hecho un committer. Es mejor considerar estos posts como las instrucciones de lo que se va a hacer después de aplicar la confirmación en el repository.

Entonces escribe un post como este

Corregir error # 1234

En lugar de

Error reparado # 1234

Trate el logging 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.

Es solo una convención (relativamente) común, de modo que los posts 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.