Wanneer een ontwikkelaar terugkeert in de tijd om te zoeken naar iets waar hij zes maanden geleden aan heeft gewerkt, begrijpt hij vaak niet waarom hij die specifieke opdracht heeft gemaakt, en de enige reden hiervoor is omdat hij de juiste manier niet heeft gevolgd om de opdrachtbericht te schrijven. Er zijn commit-berichtenstandaarden die ontwikkelaars over de hele wereld beoefenen, en het is goed om populaire normen te volgen, zodat wanneer je na een goede tijd terugkomt of iemand anders naar je commit-berichten kijkt, ze er niet uitzien als cringe! De meest effectieve techniek om andere ontwikkelaars te informeren over de context van een verandering is met een goed geschreven Git-commit-bericht. De meest effectieve techniek om andere ontwikkelaars te informeren over de context van een verandering is met een goed geschreven Git-commit-bericht. Teams moeten eerst beslissen over een commissie-berichtconventie die de versiecontrole-geschiedenis van het product dat ze bouwen, specificeert. Een geweldig Git-commit-bericht moet een juiste stijl, inhoud en metagegevens hebben. Een bekende Git commit volgt deze conventie: <type>(<scope>): <message> Het kan een van de volgende zijn: <type> Feat voor een nieuwe functie. een refactor voor het refactoren van de productiecode, bijvoorbeeld om een functie te hernoemen. Docs voor wijzigingen in de documentatie. Een bug fix voor de gebruiker. perf voor prestatieverbeteringen. stijl voor het formatteren van wijzigingen, ontbrekende halve kolommen, enzovoort Test voor het toevoegen van ontbrekende tests, refactoring tests. build voor het bijwerken van build-configuratie, ontwikkelhulpmiddelen of andere wijzigingen die irrelevant zijn voor de gebruiker. U kunt ook uw aangepaste type toevoegen, afhankelijk van de normen die uw team volgt. De bovenstaande normen worden gevolgd door het ESLint-team. . hier De reikwijdte is optioneel en het deel van het bericht moet een enkele regelverklaring bevatten, niet meer dan 72 tekens, om samen te vatten waar de opdracht voor is. Veel ontwikkelaars gebruiken ook het bericht als de onderwerplijn en voegen ook een lichaam toe; dat is in principe de beschrijving van de commit, maar een one-lineer commit-bericht is de voorkeur zolang je de context kunt begrijpen (commit wat is en waarom is). Je kunt ook tools gebruiken zoals of om uw commits te standaardiseren. Glitter commissaris Niet alleen dit, u kunt zich ook afvragen of er een hulpmiddel is dat uw commit-bericht controleert en een fout popt als het de richtlijnen niet volgt. Het helpt je team om zich te houden aan een commit convention. Verantwoord Lint Vaak gebruiken experts in de industrie hun JIRA- of Click Up-ticket als de opdrachtbericht, zodat alles op elk gewenst moment kan worden gekoppeld of teruggetrokken en de codebase onderhoudbaar blijft voor toekomstige ontwikkelaars. Sommige teams willen ook emojis toevoegen aan hun commitberichten. ik heb een lijst met emojis en hun respectieve betekenissen gecurateerd. . hier Uiteindelijk is het belangrijk dat uw commit-bericht zinvol moet zijn en uw mede-ontwikkelaars of toekomstige ontwikkelaars niet verwarrt over wat een bepaalde verandering is. Als u meer wilt weten over conventionele commits, semantische commits of de praktijken die de industrie volgt, zijn hier enkele bronnen voor u: Conventionele commissie Semantische verplichtingen Hoe een Commit-bericht te schrijven door CBeams
