¿Debo usar el tiempo pasado o presente en los mensajes de confirmación de git? [cerrado]

Una vez leí que los mensajes de confirmación de git deberían estar en el tiempo presente imperativo, por ejemplo, "Agregar pruebas para x". Siempre me encuentro usando el tiempo pasado, por ejemplo, "Pruebas agregadas para x", lo cual me parece mucho más natural.

Aquí hay una confirmación reciente de John Resig que muestra el mensaje dos en uno:

Ajustar algunos resultados más de jQuery en las pruebas de manipulación. También se arregló el orden de los resultados esperados de la prueba.

¿Importa? ¿Cuál debería usar?

La preferencia por los mensajes de confirmación de estilo imperativo en tiempo presente proviene del propio Git. De Documentation / SubmittingPatches en el repositorio de Git:

Describa sus cambios en el estado de ánimo imperativo, por ejemplo, "make xyzzy do frotz" en lugar de "[Este parche] hace xyzzy do frotz" o "[I] cambiado xyzzy para hacer frotz", como si estuviera dando órdenes a la base de código para cambiar su código comportamiento.

Por lo tanto, verá muchos mensajes de confirmación de Git escritos en ese estilo. Si está trabajando en un equipo o en software de código abierto, es útil que todos se apeguen a ese estilo para mantener la coherencia. Incluso si está trabajando en un proyecto privado, y es el único que verá su historial de git, es útil usar el estado de ánimo imperativo porque establece buenos hábitos que serán apreciados cuando trabaje con otros.

Su proyecto casi siempre debe usar el tiempo pasado . En cualquier caso, el proyecto siempre debe usar el mismo tiempo para lograr consistencia y claridad.

Entiendo algunos de los otros argumentos que argumentan usar el tiempo presente, pero generalmente no se aplican. Los siguientes puntos son argumentos comunes para escribir en tiempo presente y mi respuesta.

• Escribir en tiempo presente le dice a alguien qué hará la aplicación del compromiso , en lugar de lo que hiciste.

Esta es la razón más correcta por la que uno querría usar el tiempo presente, pero solo con el estilo de proyecto correcto. Esta forma de pensar considera todas las confirmaciones como mejoras o características opcionales, y usted es libre de decidir qué confirmaciones mantener y cuáles rechazar en su repositorio particular.

Este argumento funciona si se trata de un proyecto verdaderamente distribuido. Si se trata de un proyecto distribuido, probablemente esté trabajando en un proyecto de código abierto. Y probablemente sea un proyecto muy grande si realmente está distribuido. De hecho, probablemente sea el kernel de Linux o Git. Dado que es probable que Linux haya causado que Git se haya extendido y gane popularidad, es fácil entender por qué las personas considerarían su estilo como la autoridad. Sí, el estilo tiene sentido con esos dos proyectos. O, en general, funciona con proyectos grandes, de código abierto y distribuidos .

Dicho esto, la mayoría de los proyectos en control de fuente no funcionan así. Suele ser incorrecto para la mayoría de los repositorios. Es una forma moderna de pensar sobre los commits: los repositorios Subversion (SVN) y CVS apenas podrían soportar este estilo de registros de repositorios. Por lo general, una rama de integración manejaba el filtrado de registros incorrectos, pero generalmente no se consideraban "opcionales" o "características agradables".

En la mayoría de los escenarios, cuando realiza confirmaciones en un repositorio de origen, está escribiendo una entrada de diario que describe lo que cambió con esta actualización, para facilitar a otros en el futuro comprender por qué se realizó un cambio. Por lo general, no es un cambio opcional: se requiere que otras personas en el proyecto lo fusionen o lo modifiquen. No se escribe una entrada de diario como "Querido diario, hoy me conoce a un niño y le dice hola.", Pero en lugar de escribir "me encontré con un niño y le dije hola a mí."

Finalmente, para tales proyectos no distribuidos, el 99.99% del tiempo que una persona leerá un mensaje de confirmación es para leer el historial: el historial se lee en tiempo pasado. El 0.01% de las veces decidirá si deben aplicar o no este commit o integrarlo en su rama / repositorio.

• Consistencia. Así es en muchos proyectos (incluido el propio git). También las herramientas git que generan confirmaciones (como git merge o git revert) lo hacen.

No, le garantizo que la mayoría de los proyectos que alguna vez iniciaron sesión en un sistema de control de versiones han tenido su historial en tiempo pasado (no tengo referencias, pero probablemente sea correcto, considerando que el argumento del tiempo presente es nuevo desde Git). Los mensajes de "revisión" o mensajes de confirmación en tiempo presente solo comenzaron a tener sentido en proyectos verdaderamente distribuidos; vea el primer punto anterior.

• La gente no solo lee el historial para saber "qué sucedió con esta base de código", sino también para responder preguntas como "qué sucede cuando selecciono este commit" o "qué tipo de cosas nuevas sucederán a mi base de código debido a estos commits Puedo o no fusionarme en el futuro ".

Ver el primer punto. El 99,99% de las veces que una persona leerá un mensaje de confirmación es para leer el historial: el historial se lee en tiempo pasado. El 0.01% de las veces decidirá si deben aplicar o no este commit o integrarlo en su rama / repositorio. 99.99% late 0.01%.

• Por lo general es más corto

Nunca he visto un buen argumento que diga usar tiempo / gramática inapropiados porque es más corto. Probablemente solo guardará 3 caracteres en promedio para un mensaje estándar de 50 caracteres. Dicho esto, el tiempo presente en promedio probablemente será unos pocos caracteres más cortos.

• Puede nombrar confirmaciones más consistentemente con títulos de tickets en su rastreador de problemas / funciones (que no usan el tiempo pasado, aunque a veces el futuro)

Los tickets se escriben como algo que está sucediendo actualmente (por ejemplo, la aplicación muestra un comportamiento incorrecto cuando hago clic en este botón) o como algo que debe hacerse en el futuro (por ejemplo, el texto necesitará una revisión por parte del editor).

Historia (es decir, los mensajes de confirmación) se escribe como algo que se hizo en el pasado (por ejemplo, el problema fue fijado).

Escribí una descripción más completa en 365git .

El uso del tiempo presente imperativo es uno al que lleva un poco acostumbrarse. Cuando comencé a mencionarlo, se encontró con resistencia. Por lo general, en la línea de "El mensaje de confirmación registra lo que he hecho". Pero, Git es un sistema de control de versiones distribuido donde potencialmente hay muchos lugares para obtener cambios. En lugar de escribir mensajes que digan lo que has hecho; considere estos mensajes como las instrucciones de lo que hará la aplicación del commit. En lugar de comprometerse con el título:

Renamed the iVars and removed the common prefix.

Tener uno como este:

Rename the iVars to remove the common prefix

Lo que le dice a alguien qué hará aplicar el commit, en lugar de lo que hiciste. Además, si observa el historial de su repositorio, verá que los mensajes generados por Git también están escritos en este tiempo: "Fusionar" no "Fusionar", "Rebase" no "Rebasar", por lo que escribir en el mismo tiempo mantiene las cosas coherentes. Al principio se siente extraño, pero tiene sentido (testimonios disponibles al momento de la solicitud) y eventualmente se vuelve natural.

Habiendo dicho todo eso, es su código, su repositorio: así que configure sus propias pautas y cúmplalas.

Sin embargo, si decide ir por este camino, entonces git rebase -isería bueno tener en cuenta la opción de cambio de palabra.

Quédate con el imperativo del tiempo presente porque

• es bueno tener un estándar
• coincide con tickets en el rastreador de errores que naturalmente tienen la forma "implementar algo", "arreglar algo" o "probar algo".

¿Para quién estás escribiendo el mensaje? ¿Y ese lector suele leer el mensaje antes o después de la propiedad del compromiso?

Creo que aquí se han dado buenas respuestas desde ambas perspectivas, tal vez no esté a la altura de sugerir que hay una mejor respuesta para cada proyecto. La votación dividida podría sugerir lo mismo.

es decir, para resumir:

• Es el mensaje predominantemente para otras personas, que generalmente se lee en algún momento antes de que hayan asumido el cambio: una propuesta de lo que tomará el cambio en su código existente.

• Es el mensaje predominantemente como un diario / registro para usted (o para su equipo), pero generalmente se lee desde la perspectiva de haber asumido el cambio y buscar para descubrir qué sucedió.

Quizás esto conducirá la motivación para su equipo / proyecto, de cualquier manera.

¿importa? las personas generalmente son lo suficientemente inteligentes como para interpretar los mensajes correctamente, si no lo son, ¡probablemente no debería permitirles acceder a su repositorio de todos modos!

Es tu decision. Simplemente use el mensaje de confirmación como desee. Pero es más fácil si no está cambiando entre tiempos e idiomas.

Y si se desarrolla en un equipo, debe discutirse y establecerse.