tipos - ¿Debo usar el tiempo pasado o presente en los mensajes de git commit?

git ver archivos modificados (7)

¿Para quién estás escribiendo el mensaje? ¿Y ese lector que normalmente lee el mensaje anterior o posterior a la propiedad es el compromiso?

Creo que aquí se han dado buenas respuestas desde ambas perspectivas, tal vez no llegue a sugerir que hay una mejor respuesta para cada proyecto. El voto dividido podría sugerir tanto.

es decir, para resumir:

Es el mensaje predominantemente para otras personas, que normalmente se leen en algún momento antes de que asuman el cambio: una propuesta de lo que el cambio hará a 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 se busca para descubrir qué sucedió.

Quizás esto lleve a la motivación para tu equipo / proyecto, de cualquier manera.

Leí una vez que los mensajes de git commit deberían estar en 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 un mensaje reciente de John Resig que muestra los dos mensajes en uno:

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

¿Importa? ¿Qué debo usar?

¿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. Solo usa el mensaje de confirmación como desees. Pero es más fácil si no está cambiando entre tiempos e idiomas.

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

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

El uso del imperativo, el tiempo presente es uno que requiere un poco de tiempo para acostumbrarse. Cuando empecé a mencionarlo, se encontró con resistencia. Por lo general, a lo largo de las líneas 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 para lo que hará la aplicación de la confirmación. En lugar de tener un commit 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 lo que hará la aplicación del compromiso, en lugar de lo que hiciste. Además, si observa el historial del repositorio, verá que los mensajes generados por Git también se escriben en este tiempo: "Fusionar" no "Fusionado", "Rebase" no "Restablecer", por lo que escribir en el mismo tiempo mantiene la coherencia. Al principio se siente extraño, pero tiene sentido (los testimonios están disponibles al momento de la aplicación) y eventualmente se vuelven naturales.
Habiendo dicho todo eso, es tu código, tu repositorio: así que configura tus propias pautas y apégate a ellas.
Sin embargo, si decides ir por este camino, sería bueno git rebase -i con la opción de git rebase -i .

La preferencia por los mensajes de compromiso en tiempo presente y estilo imperativo proviene del propio Git. Desde Documentation/SubmittingPatches en el repositorio de Git:

Describe tus cambios en el estado de ánimo imperativo, por ejemplo, "make xyzzy do frotz" en lugar de "[Este parche] hace que xyzzy do frotz" o "[I] cambié xyzzy para hacer frotz", como si estuvieras dando órdenes al código base para cambiar su comportamiento.

Así que verás muchos mensajes de Git commit escritos en ese estilo. Si está trabajando en un equipo o en un software de código abierto, es útil si todos se adhieren a ese estilo para mantener la coherencia. Incluso si estás trabajando en un proyecto privado y eres el único que verá tu historial de git, es útil usar el estado de ánimo imperativo porque establece buenos hábitos que serán apreciados cuando trabajes con otros.

Quédate con el presente imperativo tenso porque

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

Tu proyecto casi siempre debe usar el tiempo pasado . En cualquier caso, el proyecto siempre debe usar el mismo tiempo para la coherencia y la 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 lo que hará la aplicación del compromiso , en lugar de lo que hiciste.

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

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

Dicho esto, la mayoría de los proyectos en control de código fuente no funcionan así. Normalmente es incorrecto para la mayoría de los repositorios. Es una forma moderna de pensar acerca de los compromisos: Subversion (SVN) y los repositorios CVS apenas pueden soportar este estilo de registros en el repositorio. Por lo general, una rama de integración manejaba el filtrado de registros incorrectos, pero en general no se consideraban "opcionales" o "agradables para tener características".

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 que sea más fácil para otros en el futuro entender por qué se realizó un cambio. Por lo general, no es un cambio opcional; se requiere que otras personas en el proyecto se fusionen o vuelvan a generar. No escribes una entrada en el diario como "Querido diario, hoy me encontré con un chico y él me saludó", pero en cambio escribiste "Me encontré con un chico y él me saludó".

Finalmente, para dichos 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% del tiempo decidirá si deben aplicar este compromiso o integrarlo en su sucursal / 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 han iniciado sesión en un sistema de control de versiones han tenido su historial en tiempo pasado (no tengo referencias, pero es probable que sea así, considerando que el argumento del tiempo presente es nuevo desde Git). Los mensajes de "revisión" o los mensajes de confirmación en tiempo presente solo comenzaron a tener sentido en proyectos verdaderamente distribuidos; consulte el primer punto anterior.

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

Ver el primer punto. 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% del tiempo decidirá si deben aplicar este compromiso o integrarlo en su sucursal / repositorio. 99.99% supera el 0.01%.

Suele ser mas corto

Nunca he visto un buen argumento que diga usar tiempo / gramática inadecuados porque es más corto. Es probable que solo ahorre 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 corto.

Puede asignar un nombre a los compromisos de forma más consistente con los títulos de tickets en su problema / rastreador de características (que no usa el tiempo pasado, aunque a veces es futuro)

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

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