Sådan skriver du gode forpligtelsesmeddelelser: En praktisk guide til git

For at oprette en nyttig revisionshistorik skal holdene først blive enige om en konvention om meddelelseskommission, der skal bruges. Dette gælder også for personlige projekter.

For nylig på Hashnode spurgte jeg: "Hvilken begivenhedsmeddelelseskonvention bruger du på arbejde?" og jeg fik nogle fantastiske svar med brugere, der forklarede de konventioner, de bruger på arbejdspladsen og til deres personlige projekter.

Hvilken konvention besked konvention bruger du på arbejde?

fra @hashnode //t.co/HewCBxRCbr

- BOLAJI ✨ (@iambolajiayo) 25. november 2019

I denne artikel vil jeg gå over, hvordan man skriver gode forpligtelsesmeddelelser, og hvorfor du skal.

PS: Denne artikel blev først offentliggjort på min blog her.

Introduktion til versionskontrol med Git

Versionskontrolsoftware er en vigtig del af nutidens softwareudviklerpraksis.

Langt er Git det mest anvendte versionskontrolsystem i verden. Det er et distribueret og aktivt vedligeholdt open source-projekt, der oprindeligt blev udviklet i 2005 af Linus Torvalds, den berømte skaber af Linux-operativsystemets kerne.

Ny hos Git? Tjek den officielle startvejledning eller dette dias fra en tidligere tale, jeg holdt.

Hvad er en meddelelse?

Den begå kommando bruges til at gemme ændringer i en lokal arkiv efter mellemstationer i Git. Inden du dog kan gemme ændringer i Git, skal du fortælle Git, hvilke ændringer du vil gemme, da du muligvis har foretaget masser af redigeringer. En god måde at gøre det på er ved at tilføje en forpligtelsesbesked for at identificere dine ændringer.

Forpligtelsesmuligheder

  • -m

Denne indstilling indstiller meddelelsens meddelelse.

git add static/admin/config.yml git commit -m "Setup multiple roles for netlify-cms git gateway" 
  • -a eller - alt

Denne mulighed forpligter automatisk alle (inklusive nye) sporede, ændrede eller slettede filer.

git commit -a -m "Add a new role for netlify-cms git gateway" 
  • --ændre

Denne indstilling omskriver den sidste forpligtelse med eventuelle aktuelt iscenesatte ændringer eller en ny forpligtelsesmeddelelse og bør kun udføres på forpligtelser, der endnu ikke er skubbet til et eksternt lager.

git add . git commit --amend -m "Update roles for netlify-cms git gateway" 

Hvorfor skal du skrive gode kommitterede meddelelser?

Du kan måske sige, "Det er bare et personligt projekt." Ja, du arbejder alene nu, men hvad sker der, når du arbejder med et team eller bidrager til open source?

En veludformet Git-forpligtelsesbesked er den bedste måde at kommunikere sammenhæng om en ændring til andre udviklere, der arbejder på dette projekt, og faktisk til dit fremtidige selv.

Har du nogensinde prøvet at køre git logpå et af dine gamle projekter for at se de "underlige" meddelelser, du har brugt siden starten? Det kan være svært at forstå, hvorfor du har foretaget nogle ændringer tidligere, og du vil ønske, at du læste denne artikel tidligere :).

Commit-meddelelser kan kommunikere tilstrækkeligt, hvorfor en ændring blev foretaget, og forståelse, der gør udvikling og samarbejde mere effektiv.

Sådan skriver du meddelelser med Git

Før nu brugte jeg kun git commit -m "Fix X to allow Y to use Z"mine personlige projekter med kun et emne og ingen ekstra beskrivelse. Dette er fantastisk til små og klare rettelser som git commit -m "Fix typo in README.md, men i tilfælde af mere omfattende ændringer skal du tilføje nogle ekstra detaljer.

Editor-metode

Kør git commituden en besked eller mulighed, og det åbner din standardteksteditor til at skrive en meddelelsesmeddelelse.

Sådan konfigureres din "standard" -editor:

git config --global core.editor nano 

Dette ville konfigurere Git til at bruge nano som din standard editor. Udskift "nano" med "emacs", "vim" eller hvad du foretrækker.

I den åbnede editor er den første linje emnet (kort beskrivelse), efterlad en tom linje efter den, og alt andet er den udvidede beskrivelse (body).

Kommandolinjemetode

git commit -m "Subject" -m "Description..." 

Den første -mmulighed er emnet (kort beskrivelse), og den næste er den udvidede beskrivelse (brødtekst).

Sådan skriver du gode forpligtelsesbeskeder

Der er flere konventioner, der bruges af forskellige teams og udviklere til at skrive gode meddelelser. Jeg vil kun skitsere nogle generelle regler og tip til at skrive kommitterede meddelelser - du skal beslutte, hvilken konvention du vil følge. Og hvis du arbejder for en virksomhed eller bidrager til open source, skal du tilpasse deres konvention :).

For konsistens kan du bruge en konvention til arbejde og en anden til personlige projekter, da du måske skifter job en gang, og konventionen kan også ændre sig.

Sørg for at tjekke denne tråd for nogle fantastiske budskabskonventioner eller tilføj din for at hjælpe nogen med at træffe en beslutning.

Her er en god skabelon til en god meddelelse, der oprindeligt blev skrevet af Tim pope

Capitalized, short (50 chars or less) summary More detailed explanatory text, if necessary. Wrap it to about 72 characters or so. In some contexts, the first line is treated as the subject of an email and the rest of the text as the body. The blank line separating the summary from the body is critical (unless you omit the body entirely); tools like rebase can get confused if you run the two together. Write your commit message in the imperative: "Fix bug" and not "Fixed bug" or "Fixes bug." This convention matches up with commit messages generated by commands like git merge and git revert. Further paragraphs come after blank lines. - Bullet points are okay, too - Typically a hyphen or asterisk is used for the bullet, followed by a single space, with blank lines in between, but conventions vary here - Use a hanging indent If you use an issue tracker, add a reference(s) to them at the bottom, like so: Resolves: #123 

Ser godt ud, ikke? Sådan kan du også gøre din god:

  1. Angiv typen af ​​forpligtelse:
  • feat: Den nye funktion, du tilføjer til en bestemt applikation
  • fix: A bug fix
  • style: Feature and updates related to styling
  • refactor: Refactoring a specific section of the codebase
  • test: Everything related to testing
  • docs: Everything related to documentation
  • chore: Regular code maintenance.[ You can also use emojis to represent commit types]
  1. Separate the subject from the body with a blank line
  2. Your commit message should not contain any whitespace errors
  3. Remove unnecessary punctuation marks
  4. Do not end the subject line with a period
  5. Capitalize the subject line and each paragraph
  6. Use the imperative mood in the subject line
  7. Use the body to explain what changes you have made and why you made them.
  8. Do not assume the reviewer understands what the original problem was, ensure you add it.
  9. Do not think your code is self-explanatory
  10. Follow the commit convention defined by your team

Conclusion

Den vigtigste del af en forpligtende besked er, at den skal være klar og meningsfuld. I det lange løb viser skrivning af gode meddelelser, hvor meget du er samarbejdspartner. Fordelene ved at skrive gode forpligtelsesbeskeder er ikke kun begrænset til dit team, men udvides faktisk til dig selv og fremtidige bidragydere.

Vil du lære mere om Git og blive en professionel "version controller"? Tjek disse fremragende ressourcer:

  • //try.github.io/
  • //git-scm.com/book/da/v2
  • //www.git-tower.com/learn/
  • //learngitbranching.js.org/
  • //github.com/commitizen/cz-cli