¿Por qué debería usar un editor para los mensajes de confirmación de Git?

Question

Tengo la sensación de que casi todo el mundo usa un editor (Vim, Notepad ++, etc.) para los mensajes de confirmación de Git. ¿Por qué?

Me parece que escribir -m y un par de citas es fácil y proporciona una manera fácil de rehacer una confirmación (presionando la flecha hacia arriba). Supongo que es más fácil hacer mensajes de compromiso de varias líneas en un editor, pero me cuesta convencer a mis compañeros de trabajo para que escriban cualquier mensaje!

Answer 1

Usted mencionó que lo más importante - la longitud. Los mensajes de confirmación deben ser esencialmente siempre ser multilíneas. Las únicas excepciones son compromisos triviales (por ejemplo, "número de versión tropezada a X.X.X") o se fusiona sin conflictos (aunque incluso entonces, agregar un shortlog no es una mala idea). El compromiso promedio, en la medida en que tal cosa existe, probablemente debería tener una o dos oraciones más allá del sujeto; algunos incluso podrían tener párrafos. Solo mira el log of git.git; es más que garantizado que es un buen ejemplo del estilo y duración de los mensajes de confirmación.

Me doy cuenta de que puede ser difícil convencer a otros para que escriban buenos mensajes de confirmación, pero eso no significa que no pueda hacerlo, y probablemente le resultará más fácil usar un editor para escribirlos.

(I tienen exactamente la misma experiencia en mi lugar de trabajo. Mis compañeros de trabajo son los ingenieros de primera, segunda, programadores y usuarios de control de versiones ... tercera sería generoso. Pero al menos puede hacer su derecha trabajo!)

Answer 2

En un editor puede escribir mensajes más largos, qué formato, como justificar a 80 columnas, etc Tal vez usted tiene una plantilla para los mensajes de confirmación que copiar y pegar. Puede hacer estas cosas en los editores de texto.

Answer 3

empecé a aprender vim configurándola como mi editor por defecto para Mercurial; me obligó a conocer al menos los comandos básicos si quería hacer algo. Ahora uso vim todo el tiempo.

Answer 4

Algunas personas tienen convenciones, such as the following:

cortas (50 caracteres o menos) resumen de los cambios

más detallada texto explicativo, si necesario. Envuélvalo a unos 72 caracteres o menos. En algunos contextos, la primera línea se trata como el objeto de un correo electrónico y el resto de el texto como el cuerpo. La línea en blanco separar el resumen del cuerpo es crítico (a menos que se omite por completo el cuerpo ); herramientas como rebase pueden confundir a si ejecuta los dos juntos.

Escriba su mensaje de compromiso en el presente: "Corregir error" y no "Error reparado". Esta convención coincide se comprometen con los mensajes generados por comandos como git merge y git de revertir.

Otros párrafos vienen después de líneas en blanco .

- Las viñetas están bien, también

- Normalmente, un guión o un asterisco se utiliza para la bala, precedido por un único espacio
, con líneas en blanco en entre, pero convenciones varían aquí

- Utilice una sangría de suspensión

Buena suerte haciendo eso sin usar un editor.

Answer 5

Un mensaje de confirmación de git adecuado debería ser casi siempre de varias líneas. De the official git-commit discussion,

Aunque no se requiere, que es una buena idea para comenzar el mensaje de confirmación con un única corta (menos de 50 caracteres) línea que resume el cambio, seguido por una línea en blanco y luego una más descripción completa. Las herramientas que activan correos electrónicos, por ejemplo, usan la primera línea del Asunto: línea y el resto de la confirmación en el cuerpo .

Si usted está teniendo dificultades para conseguir cualquier mensajes de confirmación, (hable con su administrador de sistemas y/o) asegurarse de que al menos uno de la variable de entorno GIT_EDITOR, la variable de configuración core.editor, el entorno visual variable, o la variable de entorno EDITOR se establece en algo útil.

Una opción sería crear su propio "editor", que solicita una descripción corta (< 50 caracteres), y luego un número mínimo de caracteres u oraciones. Esto podría no ser bien recibido, pero eso dependería de su posición y la cultura de su entorno de trabajo.