version-control - sobre - mensaje con la palabra compromiso

¿Deben los mensajes de compromiso escribirse en tiempo presente o pasado? (12)

" Fix bug X " tiene 2 caracteres menos que " Fixed bug X ".
Y 3 más cortos que " Corregir error X ".

Desde el punto de vista de escribir-corto-comprometer-mensajes, el presente a veces / generalmente ahorra algunos caracteres?
Lo que realmente 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 -> hecho leer más rápido?

Entonces, ¿qué es lo que piensas 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 justificaciones. Tenga en cuenta que lo estoy planteando desde su perspectiva general, lo que significa que no debe tratar de asociar esto con sus herramientas svn / cvs preferidas o lenguajes de programación, sino más bien considerarlo como algo que debería / puede aplicarse a cualquier herramienta y lenguajes de programación.

Creo que "Fix XXX bug" "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.

Creo que escribir sobre el compromiso actual en tiempo presente es una buena idea, porque lo deja más claro cuando se refiere a confirmaciones previas en tiempo pasado.

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.

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

Soy un desarrollador independiente y utilizo 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 la implementación. Es un flujo de trabajo centrado en el usuario en comparación con el enfoque basado en el tiempo presente, basado en el desarrollador. Puedo ahorrar algo de tiempo de esta manera. Sería extremadamente antinatural dar instrucciones a los usuarios en las notas de la versión. Es mi trabajo corregir errores y agregar funciones. Tengo que ahorrar tiempo, porque soy un indie. No tengo un "escritor de notas de publicación" en mi equipo.

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

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

En cuanto a la intuición, si miro algún registro de cambios, definitivamente entenderé que te refieres al error solucionado 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 auto- forma especifica

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

No creo que realmente importe. El objetivo es:

1) Transmitir qué se está haciendo o qué se está haciendo, por lo que los errores se pueden encontrar más fácilmente, los problemas se pueden revertir más fácilmente y, en general, se puede mantener el proyecto más fácil.

2) Transmitir qué tickets se corrigieron si los hay, para que los auditores (si se usan en su empresa puedan ver qué cambios corresponden a qué boletos).

Por último, si ya se ha solucionado, "Reparar" no tiene sentido, y si aún está trabajando en él, "Solucionado" no es correcto.

Personalmente prefiero el pretérito ("fijo") ya que para cuando cometo el error está solucionado (o no estaría cometiendo).

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

Para otros verbos, escribirlos como un comando parece más natural, y funciona mejor si tienes un objetivo específico por adelantado: literalmente puedes escribir el resumen de compromiso junto con las pruebas iniciales antes de que se realice el trabajo.

No le pongo una gran cantidad de peso, pero para mí este es el camino de menor resistencia mientras se mantiene la constancia.

Prefiero ver los mensajes de compromiso en tiempo presente. De esa forma, el mensaje describe lo que hace el diff (porque puedes sacar ese diff o incluso ese commit completo en una rama diferente). Por lo tanto, el mensaje de compromiso no describe lo que "hizo" ... Describe lo que el compromiso en sí "hace". Por lo tanto, debe estar en tiempo presente.

Imagine que observa una diferencia de forma aislada e intenta decidir si la aplicará. No tiene sentido que tenga un título en tiempo pasado.

Si es un pequeño compromiso, uso presente continuo:

Corrección de error 304

Agregar comentarios

Si es una gran confirmación, hago más de un registro de cambios:

Corrige errores 453, 657 y 324
Agregar sintaxis de expresión
Refactorizado la clase de Operador.

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

"Problema resuelto 3124", o "Soluciona problema 3124" parece correcto porque dice que este código solucionado | soluciona el problema 3124.

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

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 ajusta a todos los casos de uso cuando estoy considerando un parche.

¿Qué vas a hacer aquí?
¿Qué hace este parche?
¿Por qué se creó este parche? (para arreglar el error xxx ...)
Necesito arreglar el error xxx en yyy. ¿Hay algún compromiso en otra rama que ya lo haga?

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