Cuando un desarrollador regresa en el tiempo para buscar algo en el que ha trabajado hace seis meses, muchas veces no entiende por qué hizo ese compromiso en particular, y la única razón para eso es porque no siguió la forma correcta de escribir el mensaje de compromiso. Hay estándares de mensajes de compromiso que los desarrolladores practican en todo el mundo, y es bueno seguir estándares populares para que cuando vuelvas después de una buena cantidad de tiempo o alguien se vea a tus mensajes de compromiso, no se verían como cringe! La técnica más efectiva para informar a otros desarrolladores del contexto de un cambio es con un mensaje de compromiso Git bien escrito. La técnica más efectiva para informar a otros desarrolladores del contexto de un cambio es con un mensaje de compromiso Git bien escrito. Los equipos deben primero decidir sobre una convención de mensajes de compromiso que especifique el historial de control de versiones del producto que están construyendo. Un gran mensaje de comisión de Git debe tener un estilo, contenido y metadatos adecuados. Un conocido compromiso de Git sigue esta convención: <type>(<scope>): <message> Puede ser uno de los siguientes: <type> Feat para una nueva característica. refactor para refactorizar el código de producción, por ejemplo, renombrar una función. Docs para cambios en la documentación. Corregir un bug para el usuario. perf para mejorar el rendimiento. Modificación del formato, falta de semicoloncas, etc. Test para la adición de pruebas faltantes, refactoring de pruebas. para actualizar la configuración de la instalación, las herramientas de desarrollo u otros cambios irrelevantes para el usuario. También puede agregar su tipo personalizado, dependiendo de los estándares que su equipo siga. Los estándares anteriores son seguidos por el equipo ESLint. Puede comprobar sus mensajes de compromiso . Aquí El alcance es opcional, y la parte del mensaje debe incluir una declaración de línea única, no más de 72 caracteres, para resumir lo que el compromiso es para. Muchos desarrolladores también usan el mensaje como la línea de tema y añaden un cuerpo también; eso es básicamente la descripción del comité, pero un mensaje de comité de una línea es preferible siempre que pueda comprender el contexto (comprender qué es y por qué es). También puede utilizar herramientas como o Estandariza tus mensajes. Glitter Comisionado No solo esto, también puede preguntarse si hay una herramienta que comprueba su mensaje de compromiso y aparece un error si no sigue las pautas. es uno de ellos. Ayuda a su equipo a adherirse a una convención de compromiso. Compañía Lint Muchas veces, los expertos de la industria utilizan su ticket JIRA o Click Up como el mensaje de compromiso para que todo se pueda vincular o rastrear en cualquier momento, y la base de código permanece mantenible para futuros desarrolladores. Algunos equipos también les gusta añadir emojis a sus mensajes de compromiso. He curado una lista de emojis y sus respectivos significados. . Aquí Al final, lo importante es que su mensaje de compromiso sea significativo y no confunda a sus compañeros de desarrollo o futuros desarrolladores sobre qué es un cambio en particular. Si desea aprender más sobre los compromisos convencionales, los compromisos semánticos o las prácticas que sigue la industria, aquí hay algunos recursos para usted: Comisiones convencionales Compromisos semánticos Cómo escribir un mensaje de compromiso de CBeams
