¿Deben escribirse los mensajes de confirmación en tiempo presente o pasado? [cerrado]

102

Entonces, ¿cuál crees que es mejor y más intuitivo?

Fixed the XXX bug in YYY
Fix the XXX bug in YYY
Fixes the XXX bug in YYY
Fixing the XXX bug in YYY

Por favor proporcione sus fundamentos. Tenga en cuenta que lo estoy preguntando desde su perspectiva general, lo que significa que no debe intentar asociar esto con sus herramientas svn / cvs o lenguajes de programación preferidos, sino más bien pensar en ello como algo que debería / puede aplicarse a cualquier herramienta y lenguaje de programación.

version-control coding-style Ella
fuente
Alguien en tu trabajo es demasiado pedante, espero que no seas tú. Quienquiera que sea, debe considerar el presente perfecto frente al presente imperfecto, y el enigma filosófico de si el comentario de confirmación se lee como si fuera desde el momento en que era tipo, o desde el momento en que se persistió en el repositorio. Si es lo último, use el presente perfecto para una acción completa. Si es el primero, use imperfecto para una actividad presente incompleta.
Heath Hunnicutt
1
No es un engaño de esa pregunta. Se trata de preguntar sobre un aspecto pequeño, no sobre pautas generales.
3
Afortunadamente no lo es. Estaba preguntando, tratando de averiguarlo, me gustaría saber cuál es la práctica general por ahí. Si tengo que decirte la verdad, esta es en realidad la pregunta más insignificante que he hecho en SO, pero bueno, sigue siendo una pregunta, ¿no? La pregunta en sí ha ganado tres votos, lo que (si no es obvio para usted) indica que no soy el único que piensa que esta pregunta es válida en sí misma. Estoy tras respuestas constructivas y no me estás ayudando en absoluto.
Su
1
Si pensaba que la gente no debería preocuparse demasiado por los tiempos verbales en los mensajes de confirmación, dígalo, exponga sus razones y sus preferencias. Mucho más útil y útil que tu comentario sarcástico anterior.
Su
10
Me tomo esta pregunta muy en serio. Es una gran pregunta. Ser coherente es muy importante a la hora de desarrollar software, y serlo debe ser de interés para todos los visitantes interesados ​​en el tema de este sitio web. Esa es mi opinión.
Niklas Berglund

Respuestas:

39

Pienso en estos mensajes tal como les aparecen a otros desarrolladores. Todavía no se han aplicado los cambios, y existe la pregunta implícita, "¿qué hará la aplicación de este conjunto de cambios / parche?" ¡"Arreglará el error XXX en YYY"!

Para otros verbos, escribirlos como un comando parece más natural y funciona mejor si tiene un objetivo específico desde el principio; literalmente, puede escribir el resumen de confirmación junto con las pruebas iniciales antes de terminar el trabajo.

No le pongo una gran cantidad de peso, pero para mí este es el camino de menor resistencia manteniendo la consistencia.

Roger Pate
fuente
8
Recuerdo haber encontrado algo en la documentación de git que recomendaba encarecidamente este tiempo, pero todavía me resulta incómodo.
keithjgrant
1
Esta es la pieza de la documentación de Git de donde proviene.
sschuberth
31

Personalmente voy con el tiempo pasado ("arreglado") ya que para cuando llego a cometer el error ya está arreglado (o no lo estaría cometiendo).

cletus
fuente
¿Puede dar un ejemplo de esto?
bzlm
15
un ejemplo de esto.
Reverendo Gonzo
Se llama 'Confirmar historial'. La historia siempre se escribe en tiempo pasado. Así que el tiempo pasado tiene más sentido. Cuando también está revisando el historial de confirmación de algunos repositorios, está viendo lo que se le hizo ... ¡en el pasado!
Shiva
13

Prefiero ver los mensajes de confirmación en tiempo presente. De esa manera, el mensaje describe lo que hace el diff (porque puede tirar ese diff o incluso toda esa confirmación en una rama diferente). Por lo tanto, el mensaje de confirmación no describe lo que "hizo" ... Describe lo que "hace" la propia confirmación. Entonces debería estar en tiempo presente.

Imagínese mirando una diferencia de forma aislada y tratando de decidir si la aplicará. No tiene sentido que tenga un título en tiempo pasado.

TedPavlic
fuente
1
"lo que hace el diff", pero se crea el diff por un commit que fue comprometida , es en la historia de Git ya, por lo que ya era "aplicar".
Iulian Onofrei
9

En mi humilde opinión, si quieres que sea descriptivo sin necesidad de considerar el contexto, entonces "Fixed" es definitivamente la única variante correcta.

Con respecto a la intuición, si miro algún registro de cambios, definitivamente entenderé que te refieres al error corregido ya que conozco el contexto en el que se usa la palabra, pero mi cerebro lo captará mucho más rápido si la palabra está escrita en este yo. forma específica.

"Arreglar" es la peor opción en mi humilde opinión, ya que se puede interpretar no solo como una descripción de lo que hace el parche (para), sino también como un estado de error, lo que significaría que se está trabajando y aún no se ha resuelto.

Iván
fuente
7 
Fix the XXX bug in YYY
Teach the XXX to be more ZZZ
Correct typos in javadoc

En general: {verbo imperativo} el {objeto afectado} {calificadores opcionales}

La forma imperativa se adapta a todos los casos de uso cuando estoy considerando un conjunto de parches.

  • Que vas a hacer aqui
  • ¿Qué hace este conjunto de parches?
  • ¿Por qué se creó este conjunto de parches? (para arreglar el error xxx ...)
  • Necesito arreglar el error xxx en yyy. ¿Hay una confirmación en otra rama que ya haga esto?

Independientemente de su elección, creo que la coherencia ayuda enormemente a la legibilidad. Elige uno y quédate con él.

phord
fuente
4
Muy buenas razones. Siempre lo considero como si el mensaje dijera "Soy un parche y yo [mensaje]". De esa forma siempre comienzas con un verbo imperativo.
florisla
5

Creo que escribir sobre la confirmación actual en tiempo presente es una buena idea, porque lo deja más claro cuando se hace referencia a confirmaciones anteriores en tiempo pasado.

Ken Bloom
fuente
1
Estoy de acuerdo. Si la confirmación se refiere a sí misma, también es cierta, como en "Esta confirmación corrige el error F00F".
bzlm
4

No creo que realmente importe. El propósito es:

1) Transmita lo que se está haciendo o se estaba haciendo, de modo que los errores se puedan encontrar más fácilmente, los problemas se puedan revertir más fácilmente y, en general, se pueda mantener el proyecto más fácilmente.

2) Transmita qué tickets se arreglaron, si los hubo, para que los auditores (si se utilizan en su empresa pueden ver qué cambios corresponden a qué tickets).

Por último, si ya se ha solucionado, "Fixing" no tiene sentido y, si todavía está trabajando en ello, "Fixed" no es correcto.

Reverendo Gonzo
fuente
1
Claro, estrictamente hablando, es cierto que realmente no importa. Pero si tiene que elegir uno, cuando ha corregido un error en su árbol local y desea confirmar los cambios realizados, ¿dice "Corregido XXX" o "Corregido XXX" o "Corregido XXX"?
Su
1
Creo que importa si el texto es demasiado breve. A veces veo mensajes de confirmación que me hacen preguntarme si 1. se encontró un error o realmente se corrigió, o 2. si se concibió o se aplicó una solución, o 3. si el comportamiento erróneo complejo se corrigió total o parcialmente. Y a veces varias confirmaciones se relacionan con el mismo error. En "Esta confirmación corrige el problema de rebote en DrawBall () y cierra el ticket 666" el tiempo no importa, porque el texto es detallado. Pero para "DrawBall () rebota mal", ¿qué hizo la confirmación?
bzlm
2

" Corregir error X " es 2 caracteres más corto que " Corregido error X ".
Y 3 más cortos que " Corregir error X ".

Desde el punto de vista de la escritura de mensajes cortos de confirmación, ¿el tiempo presente a veces / generalmente guarda algunos caracteres?
Lo que en realidad creo que importa un poco, por ejemplo, con la recomendación de Git de menos de 50 caracteres en la primera línea de mensaje de confirmación.
Además, menos texto -> ¿ha terminado de leer más rápido?

KajMagnus
fuente
1

Un mensaje de confirmación describe por qué escribió el código que se está confirmando.

"Solucionado el problema 3124" o "Soluciona el problema 3124" parece correcto porque dice que este código solucionó | corrige el problema 3124.

Sin embargo, la gramática también puede depender de por qué marca el error como corregido. Si puede marcar el error como corregido después de confirmarlo, entonces "Arreglado" está bien, pero si el error va a ser marcado como corregido por otra persona después de verificar su código, entonces "Correcciones" puede ser más apropiado.

Parag
fuente
0

Creo que la respuesta más importante a esta pregunta es: Todos deberían usar lo que funciona para un proyecto específico y mantenerlo al menos un poco consistente.

Si bien veo las ventajas de usar el tiempo presente (y de hecho me topé con esta publicación porque he visto algunos mensajes de tiempo presente en proyectos de código abierto), probablemente nunca dejaré de usar el tiempo presente para mis proyectos. Es la forma recomendada para Linux y Git, y probablemente otros proyectos de código abierto más grandes, pero honestamente no me importa siempre que no forme parte de estos proyectos.

Soy un desarrollador independiente y uso la primera línea de un mensaje de confirmación para las notas de la versión, mientras que la descripción en las siguientes líneas me da una idea sobre los detalles de implementación. Es un flujo de trabajo centrado en el usuario en comparación con el enfoque basado en el desarrollador en tiempo presente. Puedo ahorrar algo de tiempo de esta manera. Sería extremadamente antinatural dar instrucciones a mis usuarios en las notas de la versión. Mi trabajo es corregir errores y agregar funciones. Tengo que ahorrar tiempo, porque soy indie. No tengo un "redactor de notas de la versión" en mi equipo.

Use las reglas de un proyecto si ya están establecidas, pero sea pragmático y haga lo que sea que facilite o acelere su trabajo.

Rafael Bugajewski
fuente
-1

Creo que "Fixes XXX bug"tiene más sentido que "Fix XXX bug"si la razón para usar el tiempo presente es "hacerlo más descriptivo de lo que hace el compromiso" en lugar de lo que hizo el autor.

tecnofilo
fuente
-4

Si es una pequeña confirmación, uso el presente continuo:

Corrección de error 304

o

Agregar comentarios

Si es un gran compromiso, hago más de un registro de cambios:

  • Corrige errores 453, 657 y 324
  • Adición de sintaxis de expresiones
  • Refactorizó la clase Operador.
tster
fuente
9
en otras palabras, los mezcla todos a voluntad B-)
Brian Postow
Bastante. Porque al final, los mensajes de confirmación no necesitan ser los ingleses de la reina.
tster
2
De todos modos, no deberías estar haciendo muchas cosas diferentes en un compromiso.
florisla