Lecții în Git: merge/rebase

Sistemul de control al versiunilor distribuit numit Git a schimbat modul în care dezvoltatorii gândesc despre fuziunea și ramificarea codului, în comparație cu sistemele anterioare de control al versiunilor precum CVS și SVN.

Cu Git, aceste operațiuni au devenit relativ ușor și rapid de făcut. Acest sistem permite dezvoltatorilor să creeze noi caracteristici izolate de ramura principală și să le integreze la un moment ulterior, când caracteristica este gata pentru integrare.

Dacă sunteți nou în Git, următoarele link-uri ar trebui să vă ajute să începeți rapid:

Git – Ghidul simplu
Bazele Git
Noțiuni de bază despre ramificarea Git
Un model de succes Git Branching

În Git, există două moduri principale de a integra modificările de la o ramură în alta:

combina
rebaza

Ne vom uita la îmbinarea cu opțiunea -ff și cu opțiunea –no-ff . Notă: nu există nicio comandă git –no-ff rebase .

O configurare rapidă demo

Înainte de a ne uita la cele două moduri de îmbinare Git, să setăm mai întâi un depozit Git funcțional cu următoarele comenzi:

mkdir mycode echo „foo bar baz” > mycode/foo.txt git init mycode cd mycode git add foo.txt git commit -m „Commit mesaj”

Acum să creăm o nouă ramură numită „funcția mea” și să trecem la ea:

git checkout -b caracteristica mea

Acum putem face o modificare la fișierul „foo.txt” din ramura „myfeature” a depozitului nostru local:

echo -e „foo bar baznquux” > foo.txt git commit -a -m „a adăugat funcția mea”

Să presupunem că schimbarea noastră „funcția mea” este completă și acum am dori să integrăm această caracteristică în ramura noastră „master”.

Graficul nostru git ar arăta astfel:

B myfeature / A master

După cum sa spus mai sus despre Git, avem două moduri de a face acest lucru: fie să facem o îmbinare, fie o rebazare.

Cum se utilizează: git merge

Comanda git merge unește două sau mai multe ramuri împreună.

Mai întâi, să revenim la „master”, astfel încât să putem aplica îmbinarea pe ramura noastră principală.

git checkout master

Acum putem face îmbinarea, dar să discutăm mai întâi cele două moduri diferite de a crea o îmbinare.

Adesea, actualul cap de ramură este un strămoș al commit-ului numit (“myfeature”). Acesta este cel mai frecvent caz. În acest scenariu, nu este necesar un nou commit pentru a stoca istoricul combinat. În schimb, git HEAD (împreună cu indexul) este actualizat pentru a indica comiterea numită fără a crea un comit de îmbinare suplimentar.

Comportamentul implicit al git merge este de a face o îmbinare rapid-forward atunci când este posibil. Acest comportament implicit poate fi explicit cu opțiunea -ff sau acest comportament poate fi suprimat cu opțiunea de îmbinare fără rapid înainte ( –no-ff ). La îmbinarea unei etichete adnotate, Git creează întotdeauna un commit de îmbinare, chiar dacă este posibilă o îmbinare rapidă.

Când utilizați –no-ff, cineva care examinează istoricul git poate vedea clar ramura la care ați verificat pentru a lucra. De asemenea, rețineți că îmbinarea –no-ff are o comitere suplimentară de îmbinare la sfârșit.

Mai jos este o imagine care arată diferența dintre o îmbinare –no-ff și -ff .

Deci acum aveți opțiunea de a utiliza fie:

git merge myfeature

După această comandă, graficul nostru git ar arăta astfel:

A – B maestru

Sau am putea păstra istoricul filialei făcând:

git merge –no-ff myfeature

În acest ultim caz, graficul nostru git ar arăta acum astfel:

B myfeature / A – C master

Și dacă executăm următoarea comandă git log :

git log –graph –full-istory –all –pretty=format:„%h%x09%d%x20%s”

Aceasta va afișa un grafic git similar:

*5368727 (HEAD, master) Îmbinați ramura „funcția mea” | | * 6267227 (funcția mea) a adăugat caracteristica mea | / *ac54e38 Mesaj de confirmare

Tipul de îmbinare pe care îl preferați depinde de cât de mult din informațiile despre ramură doriți să stocați atunci când faceți o îmbinare.

Cum se utilizează: git rebase

Al doilea mod de integrare a modificărilor de la o ramură în alta este să faci o rebase git .

Când îmbinarea aduce două ramuri împreună, păstrând în același timp graficul fiecărui istoric de comitere, rebazarea unifică ramurile prin rescrierea modificărilor din ramura sursă, astfel încât acestea să apară ca copii ale ramurilor de destinație.

git rebase forward-ports local se commite la capul upstream actualizat. Rebazarea este procesul de mutare a unei ramuri la un nou commit de bază.

Așa arată într-un grafic git. Să presupunem că există următorul istoric și ramura curentă este „funcția mea”:

A — B — C caracteristica mea / D — E — F — G master

Și dacă facem acum:

git rebase master

Rezultatul ar fi:

A’–B’–C’ caracteristica mea / D—E—F—G master

Ramura „master” conține acum modificările ramurii „myfeature” la commit „G” fără a crea o comitere de îmbinare. Deci, în loc să se alăture ramurilor cu un comit de îmbinare, rebazarea integrează ramura „myfeature” prin construirea peste master. Rezultatul este o istorie liniară care poate fi mai ușor de înțeles pentru dezvoltatori. Jurnalul git ar arăta acum istoricul liniar al „D—E—F—G master”.

În caz de conflict, git rebase se va opri la prima comitere problematică și va lăsa marcatori de conflict în arbore.

Îmbinați sau rebazați?

Ambele metode de integrare a codului ar trebui folosite atunci când sunt cele mai potrivite. Există opinii diferite cu privire la momentul în care ar trebui utilizată o anumită metodă.

Iată câteva link-uri care descriu situații în care o metodă ar putea fi preferată celeilalte:

fuziona sau rebaza ?
Când să fuzionați vs. Când să rebazați
Fluxuri de lucru ale echipei Git: îmbinare sau rebazare ?

Dezvăluirea agentului de publicitate

Gazduirweb este o resursă online gratuită care oferă utilizatorilor conținut valoros și servicii de comparare. Pentru a menține această resursă 100% gratuită, primim compensații de la multe dintre ofertele afișate pe site. Alături de factorii cheie de revizuire, această compensație poate afecta modul în care și locul în care apar produsele pe site (inclusiv, de exemplu, ordinea în care apar). Gazduirweb nu include întregul univers al ofertelor disponibile. Opiniile editoriale exprimate pe site sunt strict ale noastre și nu sunt furnizate, susținute sau aprobate de agenții de publicitate.

Politica noastră de revizuire editorială

Site-ul nostru se angajează să publice conținut independent, precis, ghidat de reguli editoriale stricte. Înainte ca articolele și recenziile să fie publicate pe site-ul nostru, acestea sunt supuse unui proces amănunțit de revizuire efectuat de o echipă de editori independenți și experți în materie pentru a asigura acuratețea, actualitatea și imparțialitatea conținutului. Echipa noastră editorială este separată și independentă de agenții de publicitate ai site-ului nostru, iar opiniile pe care le exprimă pe site-ul nostru sunt proprii. Pentru a citi mai multe despre membrii echipei noastre și despre mediul lor editorial, vă rugăm să vizitați pagina Despre a site-ului nostru.