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


531

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?


12
Esta pregunta, por lo tanto, debe cerrarse porque se basa principalmente en la opinión . ¡Solo mira las diferencias de opinión entre imperativo y pasado ! Dicho esto, voto por el tiempo imperativo, porque realmente ayuda a aclarar lo que estás haciendo al reescribir tu historial, elegir cerebros, aplicar parches, etc.




3
@Eonil si está cerrado por tener una opinión basada aquí, también estará cerrado por tener una opinión basada allí.
monstruo de trinquete

Respuestas:


601

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.


90
Creo que esta es una excelente opción. Piense en qué es un commit, en forma de diferencias: un conjunto de instrucciones sobre cómo pasar de un estado anterior a un estado nuevo. Así como el diff dice "agregue esta línea aquí, elimine esta línea aquí", el mensaje de confirmación dice en términos cualitativos "haga este cambio". (Sí, Git hace el commit almacenar simplemente como un árbol con metadatos, sino a un ser humano, la parte importante de una confirmación es la dif.)
Cascabel

124
Puede ver un commit como un conjunto de instrucciones sobre cómo pasar del estado anterior al nuevo estado; pero lo veo más como un punto de control en la evolución del código. Para mí, el mensaje de confirmación es un registro de lo que se ha hecho al código desde la confirmación anterior; y para un registro, el tiempo pasado tiene mucho más sentido. Si realmente cree que el mensaje de confirmación debe ser un conjunto de instrucciones, entonces el tiempo imperativo es el camino a seguir. Realmente no lo pienso de esa manera.
karadoc

10
@oschrenk: Las versiones posteriores del archivo han dado una razón: "Describa sus 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] cambie xyzzy para hacer frotz ', como si estuviera dando órdenes a la base de código para cambiar su comportamiento ".
mipadi

44
El mensaje del informe debe ser imperativo, presente porque con git usted o alguien más puede terminar haciendo rebaseo cherry-pickcomo en este caso, el envío de datos puede ser utilizado fuera de su contexto original. Como resultado, el mensaje de confirmación debe escribirse de manera independiente sin esperar que el lector vea los mensajes de confirmación que lo rodean. Cuando está seleccionando parches de cereza, tiene más sentido aplicar "Reparar algoritmo de ordenación rápida" u "Ordenar: mejorar el rendimiento" en lugar de "Error solucionado # 124" o "Ordenar modificado para mejorar el rendimiento".
Mikko Rantalainen

55
La forma en que pienso sobre esto es que el mensaje debería decirme qué cambiará si elijo aplicar este compromiso a mi sucursal. No lo considero como un registro, sino como estados a los que puedo moverme y necesito saber qué sucederá cuando elija un estado en particular.
steinybot

357

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).


79
Hoy escuché por primera vez acerca de la supuesta preferencia por los compromisos de estilo imperativo. Para mí, sonaba tan antinatural y extraño que decidí buscar algunas opiniones más. Me complace ver que no soy el único que piensa que el tiempo pasado es más natural para enviar mensajes. :)
karadoc

57
los mensajes de confirmación de fusión y rebase generados automáticamente de git son imprescindibles y en presente ("Combinar", no "Combinar"; "Rebase", no "Rebased"), por lo que es posible que desee hacer coincidir esto en sus propios mensajes de confirmación para mantener la coherencia.
mjs

13
Parece que la diferencia es entre un enfoque en el cambio al software - "Se corrigió X haciendo Y" - o el repositorio - "Hacer Y para arreglar X". +1 para un buen argumento, pero creo que el repositorio generalmente debería centrarse en sí mismo en lugar del software resultante.
l0b0

28
La cuestión es que el uso del tiempo presente imperativo funciona para grandes proyectos (por ejemplo, Linux), por lo que obviamente se escala. Además, requiere un esfuerzo prácticamente nulo utilizando el tiempo pasado. Como resultado, no veo ninguna razón (aparte de "las personas mayores se usan para escribir mensajes de compromiso en tiempo pasado") para usar cualquier otra cosa que no sea el tiempo presente imperativo. Si puede aprender el conjunto de comandos git, puede aprender a escribir en imperativo, tiempo presente.
Mikko Rantalainen

35
Imperativo no es "nuevo desde git". ChangeLog existió mucho antes de git, y el uso de imperativo siempre ha sido el estilo recomendado en el Proyecto GNU. gnu.org/prep/standards/html_node/Style-of-Change-Logs.html
adl

81

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.


77
Bueno, has mezclado dos pautas diferentes: el proyecto de código abierto de Git y el uso regular de Git. El enlace proporcionado no menciona el tiempo en absoluto . El documento oficial de Git solo menciona el límite de 50 caracteres. Git es un VCS distribuido donde hay muchos lugares para obtener cambios ... considere estos mensajes como las instrucciones de lo que hará la aplicación del commit. Esto solo se aplica a algunos proyectos que en realidad son proyectos distribuidos. El 99.999% de las confirmaciones de Git nunca se aplicarán manualmente de esta manera. En la mayoría de los proyectos, el historial es un registro de cambios, que debería estar en tiempo pasado.
Matt Quigley

44
"y debería omitir la parada completa"
takeshin

30

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".

16

¿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.


10

¿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!


27
Para algunas personas , cosas así importan bastante.
Wesley Murch

2
@mog el enlace no hace ninguna declaración sobre el presente y el pasado.
ceving

2
Si el proyecto se escala a lo grande, las personas que realizan la revisión del código y la búsqueda de errores verán tantas confirmaciones que necesitan toda la ayuda que usted y yo podamos brindar. No tiene sentido ahorrar un par de segundos ahora para causar un gran dolor de cabeza en el futuro por no escribir un mensaje de confirmación adecuado.
Mikko Rantalainen

No estoy diciendo que no escribas un buen mensaje de confirmación. Estoy diciendo que no importa si usas tiempo pasado o presente.
Michael Baldry

1
¿Cómo podría saber que la persona que no puede interpretar su mensaje de confirmación es causa de que esa persona no es lo suficientemente capaz o que usted no es capaz de escribir un buen mensaje de confirmación?
Haris

7

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.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.