De acuerdo, entonces ha terminado su trabajo y, naturalmente, está ansioso por impulsarlo y comenzar a trabajar en algo más, nuevo y emocionante. Conozco el sentimiento, todos hemos estado allí.
Bueno, tengo noticias para ti: el desarrollador realmente excelente aprieta los dientes y hace un esfuerzo adicional, dedicando tiempo a escribir un buen mensaje de compromiso para que lo vea toda la posteridad.
Al igual que un árbol es más difícil de implementar que una lista, pero proporciona órdenes de magnitud mejores rendimiento en tiempo de ejecución, escribir buenos mensajes de confirmación le toma más tiempo a usted, pero le ahorra tiempo a **todos los demás ** leer su código en el futuro (incluido su yo futuro).
Aquí hay una ganancia neta para todos. Solo considere lo que sucede cuando usted necesita revisar el código de otra persona y se ha etiquetado con los mensajes de git adecuados. Genial, ¿no? ¿Un cambio de juego incluso?
Nos esforzamos por ser desarrolladores verdaderamente excelentes aquí, así que aprieta los dientes y dedica tiempo a escribir un buen mensaje de compromiso después de cada trabajo completado. Esta guía te explica cómo hacerlo.
Esta es la parte más importante de este documento:
Un buen mensaje de confirmación explica el motivo del cambio, es decir, el por qué de la confirmación.
Lo que hace la confirmación y cómo lo hace, ya se muestra en la confirmación real. El buen mensaje de confirmación incluye la información que falta, como:
La razón detrás del cambio: ¿Por qué era necesario?
La necesidad del cambio: ¿Cómo funcionaban las cosas antes, qué estaba mal con eso y cómo funcionarán las cosas después de esta confirmación?
El resumen del cambio, cuando es demasiado largo para que se entienda fácilmente al leer el código. Siéntase libre de agregar listas de viñetas o diagramas cuando sea necesario para comprender una gran caída de código.
Puntos a información adicional: No se debe omitir ningún detalle. Incluya enlaces a toda la información que lo ayudó a producir este compromiso, para que otros desarrolladores puedan volver sobre sus pasos si es necesario. Esto significa enlaces a problemas de Jira o GitHub, artículos de Wikipedia o discusiones de Stack Overflow.
Además, si el mensaje de confirmación se adhiere a un formato estricto, puede habilitar una automatización interesante.
Hemos decidido seguir la especificación Conventional Commits:
La especificación de confirmaciones convencionales es una convención ligera sobre los mensajes de confirmación. Proporciona un conjunto sencillo de reglas para crear un historial de confirmaciones explícito; lo que facilita la escritura de herramientas automatizadas encima. Esta convención encaja con SemVer, al describir las funciones, las correcciones y los cambios importantes realizados en los mensajes de confirmación.
Los beneficios son:
Comunicación más fácil, ya que la naturaleza de los cambios es clara.
Los CHANGELOG se generan automáticamente.
Las versiones se empalman automáticamente en función de los tipos de confirmaciones obtenidas.
En resumen, todas las confirmaciones deben tener este formato:
Los tipos válidos (basados en la convención angular) son:
El tipo puede ir seguido de un signo de exclamación ! que indica que se trata de un CAMBIO IMPORTANTE DE LA API (consulte la sección de pie de página a continuación).
Se puede proporcionar un alcance después del tipo de confirmación, para proporcionar información contextual adicional y está contenido entre paréntesis, por ejemplo, feat(parser): agregar capacidad para analizar matrices.
Se puede proporcionar uno o más pies de página con una línea en blanco después del cuerpo. Cada pie de página debe constar de un token de palabra, seguido de un separador :<espacio> o <espacio># , seguido de un valor de cadena (esto está inspirado en la convención de tráiler de git <https: //git-scm.com/docs/git-interpret-trailers>`__).
BREAKING CHANGE es un token especial que cambiará la MAJOR versión. Esto también se puede indicar con un ! después del tipo o ámbito.
Ejemplos:
Revisado por: John Doe <john.doe@bitxor.software>
Coautor: John Doe <john.doe@bitxor.software>
Arreglos #1024
CAMBIO IMPORTANTE: las variables de entorno ahora tienen prioridad sobre los archivos de configuración
Sigue a los dos puntos y al espacio después del prefijo de tipo/alcance. La descripción es un resumen de una sola línea de los cambios en el código, por ejemplo, corrección: problema de análisis de matriz cuando había varios espacios en la cadena.
Esto va en el <cuerpo> del mensaje de confirmación y debe tratar de abordar todos los puntos en la sección anterior Contenido del mensaje de confirmación.
El cuerpo se puede omitir solo cuando la confirmación es breve, su descripción es autoexplicativa y los enlaces a más información (como números de problemas, si los hay) ya se proporcionan en ** pie de página**.
Omitir el cuerpo debería ser un caso raro. Un ejemplo claro podría ser corrección: errores ortográficos, pero los errores tipográficos definitivamente deben tener un cuerpo: aunque la corrección sea simple, el mensaje de confirmación debe explicar al menos cuáles fueron los efectos nocivos.
Mensaje de confirmación con descripción y pie de página de cambios importantes:
hazaña: permitir que el objeto de configuración proporcionado amplíe otras configuraciones CAMBIO IMPORTANTE: la tecla `extiende` en el archivo de configuración ahora se usa para extender otros archivos de configuración.
Mensaje de confirmación con ! para llamar la atención sobre cambios importantes:
refactorizar!: Eliminación del soporte para el Nodo 6
Confirmar mensaje con ! y pie de página BREAKING CHANGE:
refactorizar!: Eliminación del soporte para el Nodo 6 CAMBIO IMPORTANTE: Refactorización para usar funciones de JavaScript no disponible en el Nodo 6.
Confirmar mensaje sin cuerpo:
docs: ortografía correcta de CHANGELOG
Confirmar mensaje con alcance:
feat(lang): Agregar idioma polaco
Confirmar mensaje con cuerpo de varios párrafos y varios pies de página:
corrección: corregir errores tipográficos menores en el código Consulte el problema para obtener detalles sobre los errores tipográficos corregidos. Algunos de ellos se filtraron en la interfaz de usuario, por lo que esto es importante. Revisado por: Z Referencias #133
Last updated by John Doe
on 2023‑06‑19.
