Pe scurt: Cea mai bună practică este ramificată, îmbină-te des și păstrează-te mereu sincronizată .

Există convenții destul de clare despre păstrarea codului dvs. într-o ramură separată de ramura principală:

1. Sunteți pe cale să efectuați o implementare a unei schimbări majore sau perturbatoare
2. pentru a face unele modificări care s-ar putea să nu fie utilizate
3. Doriți să experimentați ceva care nu sunteți sigur că va funcționa
4. Când vi se spune să vă ramificați, alții ar putea avea ceva de făcut în master

Regula generală este după ramificare, ar trebui să vă țineți sincronizat cu masterul ramură. Pentru că, în cele din urmă, trebuie să-l îmbini înapoi la master. Pentru a evita o imensă mizerie complicată de conflicte atunci când fuzionați înapoi, ar trebui să comiteți adesea, să fuzionați des.

Bune practici de urmat

Un model de ramificare Git de succes de Vincent Driessen are sugestii bune. Dacă acest model de ramificare vă interesează, luați în considerare extensia de flux la git . Alții au comentat despre flux .

Practicile de etichetare

După cum știți deja, Git vă oferă identificatori de validare precum 1.0 -2-g1ab3183, dar acestea nu sunt etichete! Etichetarea se face cu eticheta git, iar etichetele care sunt create folosind eticheta git reprezintă baza pentru identificatorii de validare pe care git describe îi creează. Cu alte cuvinte, în Git nu etichetați ramuri. Etichetați comitetele. Este corect să spuneți că eticheta este doar un indicator adnotat la o comitere.

Să vedem exemplul practic care a demonstrat-o,

 /-- [v1.0] v ---.---.---.---S---.---A <-- master \ \-.---B <-- test 

Permiteți „s commit” S „commit validat de eticheta” v1.0 „. Această comitere este atât pe „master” de ramură, cât și pe „test” de ramură. Dacă rulați " git descrieți " deasupra commit-ului ” Un „(partea de sus a ramurii” master „) veți obține ceva de genul v1.0-2-g9c116e9. Dacă rulați " git describe " pe partea de sus a commit „B” (cunoscută și ca ramura „test”), veți obține ceva de genul v1.0-2-g3f55e41, acesta este cazul cu configurația implicită git-describe. Rețineți că acest rezultat este ușor diferit. v1.0-2-g9c116e9 înseamnă că suntem la commit cu ID SHA-1 sortat din 9c116e9, 2 comits după eticheta v1.0. Nu există nici o etichetă v1.0-2!

Dacă doriți ca eticheta dvs. să apară numai în ramura „master”, puteți crea un nou commit (de exemplu, actualizați doar default / fallback) informații despre versiune în GIT-VERSION-FILE) după punctul de ramificare al ramurii „test”. Dacă etichetați comite pe ramura „test” cu de ex. „v1.0.3` ar fi vizibil numai din„ test ”.

Referințe

Am găsit multe, multe bloguri și postări utile de la care să învăț. Cu toate acestea, cele care sunt ilustrate profesional sunt rare. Astfel, aș dori să recomand o postare – Un model de succursare Git de succes de @nvie. I-am împrumutat ilustrarea:)

Comentarii

• 1.0-2-g1ab3183 este un identificator construit de git describe din informațiile disponibile din git, dar numirea acestuia ca identificator git este puțin prea mult. Git se identifică prin hash SHA; etichetele și ramurile sunt construcții umane pe care git le urmărește cu ușurință. Ca atare, creați o etichetă când credeți că un om va dori într-o bună zi să găsească un semn de carte convenabil pentru un commit.
• o ilustrare minunată a multidimensionalității în universul git. frumos. mulțumesc
• Merită observând că multe proiecte nu au nevoie de unele a benzilor prezentate în această diagramă. Unele proiecte au nevoie doar de ceea ce ' se numește dezvoltat și caracteristic aici. Acest lucru este adesea adevărat pentru aplicațiile web care pot fi implementate după bunul plac.
• Chiar și autorul git flow nu îl mai recomandă pentru multe tipuri de proiecte, cum ar fi dezvoltarea web. Mulți oameni cred că este mult mai complex decât necesită marea majoritate a proiectelor, ceea ce face dificil de executat și ușor de greșit.La celălalt capăt al spectrului, unii practicanți avansați susțin echipe care utilizează ' dezvoltare bazată pe trunchi ', care aproape niciodată nu folosește ramuri, și să livreze astfel de proiecte de succes. Pentru ceva intermediar, luați în considerare " anti-gitflow '

O ramură este utilizată dacă aveți 2 versiuni diferite de depozit în același timp. O etichetă este o modalitate de a marca un moment în depozitul dvs.

Ar trebui să adăugați o etichetă pentru a marca o versiune lansată. Dacă atunci trebuie să remediați erorile la această versiune, veți crea o ramură la etichetă.

Vrei doar să ștergi ramurile care au fost îmbinate înapoi în HEAD [sau în altă ramură].

Comentarii

• oh … și presupun că vrei să spui că ramura este fuzionată într-o altă ramură, cum ar fi master. HEAD se mută de fiecare dată când fac o verificare, nu?
• HEAD indică de obicei spre o ramură (cu excepția cazului în care ' sunteți în modul HEAD detașat), deci HEAD se deplasează cu ramura pe care o indică