Lucru în echipă fără confuzie: înțelegerea strategiilor de ramificare în Git

Introducere

Git a devenit standardul industrial de facto pentru sistemele de control al versiunilor în dezvoltarea de software. Mai întâi ar trebui să citiți articolul meu despre ce este Git și cum să începeți. Ai citit-o? Excelent, hai să mergem! Vă place sau nu, acest instrument creat de Linus Tovalds nu se va retrage. Deci, este logic să vorbim despre modul în care echipele distribuite lucrează cu Git și ce strategie de ramificare ar trebui să aleagă pentru aceasta. Aceasta nu este o întrebare lipsită de importanță. Atunci când se formează o nouă echipă de dezvoltare care nu a mai lucrat împreună anterior, strategia de ramificare este adesea unul dintre primele lucruri pe care trebuie să le decideți. Și unii oameni vor face spumă la gură pentru a demonstra că o strategie este mai bună decât alta. Așadar, vreau să vă transmit câteva informații generale despre ei.

Sunt necesare strategii de ramificare?

Ele chiar sunt necesare. Foarte necesar. Pentru că dacă echipa nu este de acord cu ceva, atunci fiecare membru al echipei va face ce vrea:

• lucrând în orice ramură
• contopirea în alte ramuri arbitrare
• stergerea unor ramuri
• creând altele noi
• și astfel fiecare membru al echipei va acționa într-un flux negestionat.

De aceea avem trei strategii de luat în considerare mai jos. Să mergem!

GitHub Flow

Această strategie de ramificare, destul de ciudat, este preferată pe GitHub :) Vine cu un set de reguli :

1. Codul din ramura principală nu trebuie spart. Ar trebui să fie gata să fie implementat în orice moment. Adică nu trebuie să puneți acolo cod care vă va împiedica să construiți proiectul și să îl implementați pe server.
2. Când intenționați să lucrați la o nouă funcționalitate, trebuie să creați o nouă ramură de caracteristică bazată pe ramura principală și să îi dați un nume semnificativ. Commiteți codul local și împingeți regulat modificările în aceeași ramură din depozitul de la distanță.
3. Deschideți o cerere de extragere (puteți citi despre cererile de extragere aici ) atunci când credeți că lucrarea este gata și poate fi îmbinată în ramura principală (sau dacă nu sunteți sigur, dar doriți să obțineți feedback cu privire la munca efectuată).
4. După ce noua caracteristică din cererea de extragere este aprobată, aceasta poate fi îmbinată în ramura principală.
5. Când modificările sunt îmbinate în ramura principală, acestea ar trebui să fie implementate imediat pe server.

Potrivit GitHub Flow, înainte de a începe să lucrați la ceva nou, fie că este vorba despre o remediere sau o caracteristică nouă, trebuie să creați o nouă ramură bazată pe master și să îi dați un nume adecvat. În continuare, începe munca la implementare. Ar trebui să trimiteți în mod constant comite-uri către serverul de la distanță cu același nume. Când ajungeți la concluzia că totul este gata, trebuie să creați o cerere de extragere către ramura principală. Apoi, cel puțin una, sau mai bine, două persoane ar trebui să se uite la acest cod înainte de a face clic pe „Aprobare”. De obicei, liderul echipei proiectului și oa doua persoană ar trebui să arunce o privire. Apoi puteți finaliza cererea de extragere. GitHub Flow este, de asemenea, cunoscut pentru conducerea livrării continue (CD) în proiecte. Acest lucru se datorează faptului că atunci când modificările intră în ramura principală, acestea ar trebui să fie implementate imediat pe server.

GitFlow

Strategia anterioară (GitHub Flow) nu este foarte complicată la bază. Există două tipuri de ramuri: ramuri principale și ramuri caracteristice. Dar GitFlow este mai serios. Cel puțin, imaginea de mai sus ar trebui să clarifice acest lucru :) Deci, cum funcționează această strategie? În general, GitFlow constă din două ramuri persistente și mai multe tipuri de ramuri temporare. În contextul GitHub Flow, ramura principală este persistentă, iar celelalte sunt temporare. Ramuri persistente

• maestru: Nimeni nu ar trebui să atingă sau să împingă nimic în această ramură. În această strategie, master reprezintă cea mai recentă versiune stabilă, care este utilizată în producție (adică pe un server real)
• dezvoltare: ramura de dezvoltare. Ar putea fi instabil.

Dezvoltarea are loc folosind trei ramuri temporare auxiliare :

1. Ramuri caracteristice — pentru dezvoltarea de noi funcționalități.
2. Ramuri de lansare — pentru pregătirea pentru lansarea unei noi versiuni a proiectului.
3. Ramuri de remediere rapidă — pentru remedierea rapidă a unei erori găsite de utilizatori reali pe un server real.

Ramuri caracteristice

Ramurile de caracteristici sunt create de dezvoltatori pentru noi funcționalități. Ele ar trebui să fie întotdeauna create pe baza ramurului de dezvoltare. După finalizarea lucrărilor la noua funcționalitate, trebuie să creați o cerere de extragere către ramura de dezvoltare. În mod clar, echipele mari pot avea mai multe ramuri caracteristice simultan. Aruncă o altă privire la imaginea de la începutul descrierii strategiei GitFlow.

Eliberați ramuri

Când setul necesar de funcții noi este gata în ramura de dezvoltare, vă puteți pregăti pentru lansarea unei noi versiuni a produsului. O ramură de lansare, care este creată pe baza ramurului de dezvoltare, ne va ajuta în acest sens. Când lucrați cu ramura de lansare, trebuie să găsiți și să remediați toate erorile. Orice modificări noi care sunt necesare pentru a stabiliza ramura de lansare trebuie, de asemenea, fuzionate înapoi în ramura de dezvoltare. Acest lucru se face pentru a stabiliza și ramura de dezvoltare. Când testerii spun că ramura este suficient de stabilă pentru o nouă ediție, aceasta este îmbinată în ramura principală. Mai târziu, o etichetă, căreia i se atribuie un număr de versiune, este creată pentru acest commit. Pentru a vedea un exemplu, priviți imaginea de la începutul strategiei. Acolo vei vedea Tag 1.0— aceasta este doar o etichetă care indică versiunea 1.0 a proiectului. Și, în sfârșit, avem ramura de remediere rapidă.

Ramuri de remediere rapidă

Ramurile de remediere rapidă sunt, de asemenea, menite să lanseze o nouă versiune pentru ramura principală. Singura diferență este că acele lansări nu sunt planificate. Există situații în care erorile intră în versiunea lansată și sunt descoperite în mediul de producție. Luați iOS: de îndată ce o nouă versiune este lansată, primiți imediat o grămadă de actualizări cu remedieri pentru erori care au fost găsite după lansare. În consecință, trebuie să remediam rapid o eroare și să lansăm o nouă versiune. În imaginea noastră, aceasta corespunde versiunii 1.0.1. Ideea este că lucrul la noile funcționalități nu trebuie să se oprească atunci când este necesar să se remedieze un bug pe un server real (sau așa cum spunem, „în prod” sau „în producție”). Ramura de remediere rapidă ar trebui creată din ramura principală, deoarece reprezintă ceea ce rulează în prezent în producție. De îndată ce remedierea erorilor este gata, este îmbinat în master și este creată o nouă etichetă. La fel ca pregătirea unei ramuri de lansare, o ramură de remediere rapidă ar trebui, de asemenea, să-și îmbine remedierea în ramura de dezvoltare.

Flux de lucru de bifurcare

În fluxul de lucru de bifurcare, dezvoltarea implică două depozite:

1. Depozitul original, în care vor fi îmbinate toate modificările.
2. Un depozit de furcuri. Aceasta este o copie a depozitului original, deținută de un alt dezvoltator care dorește să facă modificări la original.

Sună puțin ciudat până acum, nu? Oricine a întâlnit deja dezvoltarea open-source este deja familiarizat cu această abordare. Această strategie oferă următorul avantaj: dezvoltarea poate avea loc într-un depozit fork fără acordarea de permisiuni pentru dezvoltarea comună în ramura originală. Desigur, proprietarul depozitului original are dreptul de a respinge modificările propuse. Sau să le accepte și să le îmbine. Acest lucru este convenabil atât pentru proprietarul depozitului original, cât și pentru dezvoltatorul care dorește să ajute la crearea produsului. De exemplu, puteți sugera modificări ale nucleului Linux . Dacă Linus decide că au sens, modificările vor fi adăugate (!!!).

Un exemplu de flux de lucru de bifurcare

Fluxul de lucru de bifurcare este aplicat pe GitHub atunci când există o bibliotecă pe care doriți să o utilizați. Are o eroare care te împiedică să-l folosești pe deplin. Să presupunem că te scufunzi suficient de adânc în problemă și știi soluția. Folosind fluxul de lucru forking, puteți remedia problema fără drepturi de a lucra în depozitul original al bibliotecii. Pentru a începe, trebuie să selectați un depozit, de exemplu, Spring Framework . Găsiți și faceți clic pe butonul „Fork” din colțul din dreapta sus: va dura ceva timp. Apoi, o copie a depozitului original va apărea în contul dvs. personal, ceea ce va indica faptul că este un furk:Acum puteți lucra cu acest depozit ca de obicei, adăugând modificări la ramura principală, iar când totul este gata, puteți crea o cerere de extragere în depozitul original. Pentru a face acest lucru, faceți clic pe butonul New pull request :

Ce strategie să alegi

Git este un instrument flexibil și puternic care vă permite să lucrați folosind o mare varietate de procese și strategii. Dar cu cât ai mai multe opțiuni, cu atât este mai dificil să te decizi ce strategie să alegi. Este clar că nu există un singur răspuns pentru toată lumea. Totul depinde de situație. Acestea fiind spuse, există mai multe îndrumări care vă pot ajuta în acest sens:

1. Cel mai bine este să alegeți mai întâi cea mai simplă strategie. Treceți la strategii mai complexe numai atunci când este necesar.
2. Luați în considerare strategii care au cât mai puține tipuri de ramuri pentru dezvoltatori.
3. Privește avantajele și dezavantajele diferitelor strategii, apoi alege-o pe cea de care ai nevoie pentru proiectul tău.

Atât am vrut să spun despre strategiile de ramificare în Git. Vă mulțumesc pentru atenție :) Urmărește-mă pe GitHub , unde îmi postez adesea creațiile care implică diferite tehnologii și instrumente pe care le folosesc în munca mea.