Poruke predavanja važna su sredstva komunikacije između članova tima
U razvoju softvera za tim najvažnija je komunikacija. Poruke predavanja važna su sredstva komunikacije između članova tima: njegove prošlosti i budućnosti.
Kada analiziramo kod ili otklanjamo pogreške, svi imamo pitanja poput:
- Zašto je ovo ako je ovdje?
- Tko je zaboravio ažurirati poslovnicu?
- Kakav je utjecaj imala ova promjena?
- Kako ova promjena uopće može popraviti ili poboljšati kôd?
U tu svrhu git-kriv nam omogućuje da otkrijemo koja je revizija zadnja promijenila datoteku. Ali samo znati da to nije dovoljno dobro. Bilo bi korisno da zapravo pročitate poruku urezivanja da biste razumjeli što se tamo stvarno dogodilo.
Moramo pročitati poruku da bismo iskusili stvarnu vrijednost dobre poruke predavanja i biti motivirani da je napišemo.
Neke najbolje prakse
Dakle, ako je većina vaših Git obveza do sada stvorena s nečim slično, git commit -m "9000 — Bug fixes issue"sljedeći put isprobajte ove smjernice:
-m sg> / --message=gt; flag t To vam daje lošu misaonost odmah nakon što ćete osjetiti da svoju poruku urezivanja morate uklopiti u naredbu terminala, a čini da se urezivanje osjeća više kao jednokratni argument nego kao stranica u povijesti.
Prvi redak uvijek treba imati 50 znakova ili manje, a iza njega treba biti prazan redak.Napišite imperativno vrijeme: "Popravi grešku". [ Dodaj | Popravi | Ukloni | Ažuriranje | Refactor ] Dosljedna formulacija olakšava mentalnu obradu popisa obveza.
Duži opis sa 72 znaka.Često je subjekt sam po sebi dovoljan.Ako nije, dodajte prazan redak (ovo je važno), a zatim jedan ili više odlomaka čvrsto umotanih u 72 znaka.
Ti bi odlomci trebali objasniti:
Zašto je ta promjena potrebna?
Ovaj odgovor objašnjava što mogu očekivati u predavanju, omogućujući im da lakše prepoznaju i ukažu na nepovezane promjene.
Kako rješava problem?
Opišite na visokoj razini što je učinjeno kako bi utjecalo na promjene. Ako je vaša promjena očita, možda ćete moći izostaviti rješavanje ovog pitanja.
Koje nuspojave ima ova promjena?
Ovo je najvažnije pitanje na koje možete odgovoriti, jer može ukazati na probleme kod kojih unosite previše promjena u jednom urezu ili ogranku. Jedna ili dvije metke za povezane promjene mogu biti u redu, ali pet ili šest vjerojatni su pokazatelji obveze koja čini previše stvari.
# 50-character subject line## 72-character wrapped longer description. This should answer:## * Why was this change necessary?# * How does it address the problem?# * Are there any side effects?## Include a link to the ticket, if any.Kako si olakšati život
Mnogo je toga za pamtiti, ali možete postaviti predložak poruke urezivanja pomoću commit.template
Konfigurirajte Git da koristi datoteku predloška (na primjer, .gitmessage), a zatim stvorite datoteku predloška pomoću Vima:
git config --global commit.template ~/.gitmessagevim ~/.gitmessageKada pokrenemo git commitbez -mzastavice poruke, urednik će otvoriti naš korisni predložak spreman za rad:
# [Add/Fix/Remove/Update/Refactor/Document] [summary]# Why is it necessary? (Bug fix, feature, improvements?)-# How does the change address the issue? -# What side effects does this change have?-# Include a link to the ticket, if any.Komentirani redovi nisu uključeni u završnu poruku. Jednostavno ispunite prazne retke tekstom i točkama ispod upita.
Issue lokatori u GitHub i Bitbucket kako prepoznati ključne riječi close, fixi resolvenakon čega slijedi izdavanje ili povlačenje broj zahtjeva.
Mislim da bi Linus bio vrlo sretan da više nikad ne koristimo git commit -m "Fix bug"u javnom spremištu :)
Možete jednostavno pretraživati u git zapisniku broj izdanja, na primjer s git log --grep=JIRA-1234
You can also use plugins like vim-fugitive for vim or git lens for vs code to quickly access to git commit messages.
Closing thoughts
Creating clean Git commits says a lot about you and may be a primary way that people interact with you over projects.
With a little practice, you can make your commit habits an even better reflection of your best work — work that is evidently created with care and pride.
Your future you, and your team, will thank you for your forethought and verbosity when they run git blame to see why that conditional is there.
If you enjoyed this article please clap, recommend and share.