Cando un desenvolvedor vai atrás no tempo para buscar algo que traballou hai seis meses, moitas veces non entende por que fixo ese compromiso particular, e a única razón para iso é porque non seguiu a forma correcta de escribir a mensaxe de compromiso. Hai estándares de mensaxes de compromiso que desenvolven práctica en todo o mundo, e é bo seguir estándares populares para que cando volva despois dunha boa cantidade de tempo ou alguén olle para as súas mensaxes de compromiso, non parecerían cringe! A técnica máis eficaz para informar a outros desenvolvedores do contexto dun cambio é cunha mensaxe de compromiso de Git ben escrita. A técnica máis eficaz para informar a outros desenvolvedores do contexto dun cambio é cunha mensaxe de compromiso de Git ben escrita. Os equipos deben primeiro decidir sobre unha convención de mensaxes de compromiso que especifique o historial de control de versión do produto que están construíndo. Unha boa mensaxe de comisión de Git debe ter un estilo, contido e metadatos axeitados. Un coñecido compromiso de Git segue esta convención: <type>(<scope>): <message> Pode ser unha das seguintes: <type> Feat para unha nova característica. refactor para refactorizar o código de produción, por exemplo, renomeando unha función. Docs para cambios na documentación. Corrixir un bug para o usuario. perf para melloras de rendemento. Modificacións de formato, falta de semicolóns, etc. Proba para engadir probas faltantes, refactoring probas. construír para actualizar a configuración de construción, as ferramentas de desenvolvemento ou outros cambios irrelevantes para o usuario. Tamén pode engadir o seu tipo personalizado, dependendo dos estándares que siga o seu equipo. Os estándares anteriores son seguidos polo equipo de ESLint. Pode comprobar as súas mensaxes de compromiso . aquí O alcance é opcional, e a parte da mensaxe debe incluír unha declaración de liña única, non máis de 72 caracteres, para resumir o que o compromiso é para. Moitos desenvolvedores tamén usan a mensaxe como a liña de tema e engaden un corpo tamén; que é basicamente a descrición do compromiso, pero unha mensaxe de compromiso dunha liña é preferible sempre que poida entender o contexto (compromiso o que é e por que é). Tamén podes usar ferramentas como ou Estandariza as túas mensaxes. Glitter comisario Non só iso, tamén pode preguntar se hai unha ferramenta que comprobe a súa mensaxe de compromiso e aparece un erro se non segue as directrices. axuda ao seu equipo a adherirse a unha convención de compromiso. Compoñente Lint Moitas veces, os expertos da industria usan o seu billete JIRA ou Click Up como a mensaxe de compromiso para que todo poida ser ligado ou rastrexado en calquera momento, e a base de código permanece mantida para futuros desenvolvedores. Algúns equipos tamén queren engadir emojis ás súas mensaxes de compromiso. Teño curado unha lista de emojis e os seus respectivos significados. . aquí Ao final, o importante é que a súa mensaxe de compromiso sexa significativa e non confunda aos seus compañeiros de desenvolvemento ou futuros desenvolvedores sobre o que é un cambio en particular. Se desexa saber máis sobre os compromisos convencionais, os compromisos semánticos ou as prácticas que segue a industria, aquí están algúns recursos para vostede: Comités convencionais Compromisos semánticos Como escribir unha mensaxe de compromiso por CBeams
