Fluxuri de lucru Git pentru profesioniști: un ghid Git bun

Git vă poate sprijini proiectul nu doar prin controlul versiunilor, ci și prin colaborare și managementul lansărilor. Înțelegerea modului în care modelele de flux de lucru Git pot ajuta sau împiedica un proiect vă va oferi cunoștințele necesare pentru a evalua și adapta eficient procesele Git ale proiectului.

Pe parcursul acestui ghid, voi izola tiparele proceselor de dezvoltare software găsite în fluxurile de lucru comune Git. Cunoașterea acestora vă va ajuta să găsiți o direcție atunci când vă alăturați, creați sau creșteți o echipă de dezvoltare. Avantajele și dezavantajele pentru anumite tipuri de proiecte sau echipe vor fi evidențiate în exemplele de flux de lucru pe care le explorăm, astfel încât să puteți alege ceea ce ar putea funcționa bine pentru scenariul dvs.

Aceasta nu este o introducere în utilizarea Git. Există deja ghiduri și documentație fabuloase pentru asta. Veți beneficia de acest ghid de flux de lucru Git dacă aveți deja experiență în cadrul unei echipe de dezvoltare de aplicații și v-ați confruntat cu probleme de flux de lucru, implozii de integrare sau git-tastrofe - aceste modele pot arunca puțină lumină asupra modului de a evita acele situații în viitor.

Colaborare

În ceea ce privește procesul Git, colaborarea se referă adesea la ramificarea fluxurilor de lucru. Gândirea în avans la modul în care veți împleti arbori de comitere vă va ajuta să minimizați erorile de integrare și să vă susțineți strategia de gestionare a lansărilor.

Filiala Integrare

Utilizați o ramură de integrare cu echipe de dezvoltare software care lucrează pentru implementarea unei colecții de contribuții în producție ca o singură entitate. Acest lucru se opune echipelor care se concentrează pe implementarea individuală a funcțiilor. Adesea, echipele ar putea dori să facă pe ultimul, dar limitările practice impun un proces care le grupează eforturile, iar echipa ajunge să facă primul, așa că asigurați-vă că verificați utilizarea reală a Git pentru a vedea dacă ați beneficia de utilizarea acestui tip de colaborare. model.

Acest model de flux de lucru este un punct de planificare util atunci când riscul integrării mai multor ramuri este suficient de mare pentru a justifica testarea contribuțiilor combinate în ansamblu.

O ramură de integrare constă de obicei dintr-o caracteristică majoră și mai multe contribuții mai mici care trebuie implementate împreună. Puneți o ramură de integrare prin procesul echipei de dezvoltare (întrebări și răspunsuri și testare de acceptare, de exemplu). Împingeți comiterile minore asupra acestuia pentru a-l aduce aproape de gata de producție, apoi utilizați o ramură de mediu sau o ramură de lansare (discută mai jos) pentru a o pregăti pentru implementare.

Fiți conștienți de faptul că contribuțiile la ramura de integrare trebuie să fie îmbinate în următoarea etapă de lansare înainte ca o altă caracteristică majoră să poată fi îmbinată în ramura de integrare - altfel amestecați caracteristici în diferite etape de finalizare. Acest lucru vă va inhiba capacitatea de a elibera ceea ce este gata.

Subiecte Ramuri

Echipele vor dori să folosească ramuri de subiecte dacă este important să-și păstreze arborii de comitere într-o stare care să poată fi citită cu ușurință sau să aibă caracteristicile individuale inversate. Ramurile de subiect înseamnă că commit-urile pot fi suprascrise (folosind o forță) pentru a-și curăța structura și pot fi reduse la o caracteristică commit.

Ramurile de subiect sunt adesea deținute de un contributor individual, dar pot fi, de asemenea, un spațiu desemnat pentru o echipă pentru a dezvolta o funcție. Alți contribuitori știu că acest tip de ramură ar putea avea arborele de comitere rescris în orice moment și nu ar trebui să încerce să-și păstreze ramurile locale sincronizate cu acesta.

Fără a utiliza ramuri de subiecte în fluxul dvs. de lucru Git, sunteți limitat să rămâneți de comite-urile pe care le împingeți către o ramură la distanță. Impingerea forțată a unui nou arbore de comitere către o ramură la distanță ar putea enerva alți contribuitori care se bazează pe integritatea menținută a ramurii cu care se sincronizează.

Sunt șanse să utilizați deja acest model de flux de lucru fără să vă dați seama, dar merită să aveți un set comun de definiții între echipe pentru a consolida practicile din spatele lor. De exemplu, s-ar putea să găsiți convenția de prefixare a numelui ramurilor cu inițialele creatorului ramurilor vă ajută să semnalați care sunt ramurile subiectului. Oricum ar fi, depinde de echipa ta să decidă asupra convențiilor interne.

NU utilizați ramuri de subiect în depozitele publice, provocați o multitudine de conflicte pentru oricine și-a sincronizat ramurile locale cu o ramură de subiect care a avut arborele de comitere rescris.

Furculiţă

Proiectele open source prosperă folosind această caracteristică originată de Github. Furk -ul împuternicește întreținerii depozitului cu un gateway forțat peste împingerea directă către o ramură a depozitului de origine, dar mai important, facilitează colaborarea. Wahoo!

S-ar putea să vă aflați în scenariul în care crearea unui fork al unui depozit privat se potrivește și nevoilor dvs. Setarea depozitului de origine la numai citire pentru contribuatorii depozitului de furcături și rularea cu solicitări de extragere vă oferă aceleași beneficii pe care le experimentează comunitatea open source. Echipele din diferite organizații pot lucra eficient folosind o furcă care poate fi platforma de comunicare și aderarea la politica de proiect.

Modelul de flux de lucru furcă oferă echipelor propriul spațiu pentru a lucra în orice mod cu care sunt obișnuiți, cu un singur punct de integrare între cele două depozite - o cerere de extragere. Comunicarea excesivă este imperativă în descrierea cererii de extragere. Echipele au avut fluxuri de comunicare separate înainte ca o cerere de extragere să fie emisă, iar evidențierea deciziilor care au fost deja luate va accelera procesul de revizuire.

Desigur, un beneficiu al fluxului de lucru cu furcă este că puteți direcționa comentariile către contribuatorii depozitului de origine, pe măsură ce permisiunile sunt în cascadă în jos. Din punctul de vedere al depozitului de origine, aveți controlul pentru a șterge furcăturile atunci când nu mai sunt necesare.

Asigurați-vă că utilizați un instrument care facilitează solicitările de bifurcare și tragere pentru a profita de acest model. Aceste instrumente nu se limitează la Github: alte opțiuni populare sunt Bitbucket și GitlLab. Dar există câteva alte servicii de găzduire a fluxului de lucru Git care vor avea aceste caracteristici (sau similare). Alegeți care serviciu funcționează cel mai bine pentru dvs.

NU utilizați o furcă a unui depozit privat pentru fiecare membru al unei echipe. Numeroasele depozite bifurcate pot face dificilă colaborarea mai multor membri pe aceeași ramură de caracteristici, iar menținerea tuturor acestor depozite sincronizate poate deveni predispusă la erori din cauza numărului mare de părți în mișcare. Proiectele open source au membri ai echipei de bază cu acces push la depozitul de origine, ceea ce reduce această suprasarcină.

Clonează

O strategie comună de externalizare este de a avea „locuri” de contribuție la un proiect care poate fi ocupat de mai mulți dezvoltatori de software. Depinde de compania de outsourcing să își gestioneze resursele pentru a livra orele contractate, problemele cu care se confruntă sunt cum să integreze, să formeze și să mențină un grup de dezvoltatori pentru proiectele fiecărui client.

Folosirea unei clone a depozitului proiectului stabilește un teren izolat de instruire și comunicare pentru echipa externalizată pentru a-și gestiona contribuțiile, a pune în aplicare politicile și a profita de partajarea cunoștințelor - totul sub ochiul atent al echipei de dezvoltare a clientului. Odată ce o contribuție este considerată la standard și pregătită pentru depozitul principal, aceasta poate fi împinsă într-una dintre ramurile de la distanță din depozitele de origine și integrată ca de obicei.

Unele proiecte au așteptări mari de a-și respecta convențiile de codare și standardele de flux de lucru Git definite pentru a contribui la depozitul lor. Poate fi descurajan să lucrezi în acest mediu până când ai învățat frânghiile, așa că lucrează împreună ca o echipă pentru a optimiza timpul ambelor părți.

NU creați o copie găzduită a depozitului clientului fără permisiunea acestuia, ați putea încălca un acord contractual, verificați dinainte că această practică va aduce beneficii proiectului cu clientul.

Managementul lansărilor

Pașii dintre trecerea de la colaborare la lansare vor începe în diferite puncte ale procesului de dezvoltare pentru fiecare echipă. În general, nu ați dori să utilizați mai mult de un model Git de gestionare a lansării. Doriți să aveți cel mai simplu flux de lucru posibil, care să permită echipei dvs. să livreze eficient.

Filiale de Mediu

Procesul dumneavoastră de dezvoltare software poate fi susținut de mai multe medii pentru a ajuta la asigurarea calității înainte de a fi implementat în producție. Ramurile de mediu imită etapele acestui proces: fiecare etapă corespunde unei ramuri, iar contribuțiile curg prin acestea într-o conductă.

Echipele care rulează cu aceste procese au adesea medii de aplicații configurate pentru fiecare etapă din pipeline, de exemplu „QA”, „Staging” și „Production”. În aceste cazuri, infrastructura este pusă în aplicare pentru a sprijini personalul care este responsabil pentru semnarea unei funcții sau a contribuției pentru porțiunea lor din ceea ce înseamnă a fi pregătit pentru producție (de exemplu, testare exploratorie, QA, testare de acceptare), înainte de a o muta pe următoarea persoană. etapă. Acest lucru le oferă propriul loc de implementare, testare și evaluare în funcție de cerințele lor, cu un flux de lucru Git pentru a-și înregistra călătoria prin tunelul de semnare.

A avea o filială pentru fiecare etapă a procesului este OK pentru echipele mici care pot lucra la o eliberare ca unitate. Din păcate, o conductă ca aceasta poate să se blocheze sau să se adună prea ușor și să lase goluri. Acesta cuplează procesul dvs. Git cu infrastructura dvs., ceea ce poate cauza probleme atunci când funcția necesită o accelerare și ambele procese trebuie să se extindă.

NU utilizați acest model fără a lua în considerare mai întâi beneficiile pe termen lung ale altor modele.

Eliberați ramuri

O echipă care împinge o colecție de contribuții în aplicația lor de producție ca unitate în sprinturi succesive poate găsi ramurile de lansare o potrivire favorabilă.

O colecție de comenzi aproape „gata de producție” primesc remedieri de erori minore pe o ramură de lansare. Utilizați o ramură de integrare pentru a combina și a testa caracteristicile înainte de a muta arborele de comitere pe o ramură de lansare. Limitați responsabilitatea unei ramuri de lansare la a fi o verificare finală înainte de implementare în aplicația de producție.

Ramurile de eliberare diferă de ramurile de mediu prin faptul că au o durată de viață scurtă. Ramurile de lansare sunt create numai atunci când este necesar și distruse după ce arborele de comitere a fost implementat în producție.

Încercați să preveniți cuplarea ramurilor de lansare la foaia de parcurs pentru dezvoltarea software-ului. Restricționarea la respectarea unui plan predeterminat întârzie implementarea unei ediții până când toate caracteristicile planificate sunt gata de producție. Nealocarea unui număr de versiune foii de parcurs înainte de a crea o ramură de lansare poate atenua aceste tipuri de întârzieri, permițând ca funcțiile care sunt gata de producție să fie puse într-o ramură de lansare și implementate.

Utilizați o convenție de denumire a numărului de versiune pentru numele ramurilor de lansare pentru a arăta ce versiune a depozitului a fost implementată în producție.

Implementați ramura principală și nu ramura de lansare. Pentru a încuraja efectuarea de remedieri minore asupra ramurilor de lansare înainte de fuzionarea cu ramura principală, utilizați un cârlig Git pe ramura principală pentru a se declanșa după ce s-a întâmplat o îmbinare pentru a implementa automat arborele de comitere actualizat în producție.

Permiterea unei singure ramuri de lansare să existe la un moment dat vă asigură că veți evita costul general de a menține mai multe ramuri de lansare sincronizate între ele.

NU utilizați ramuri de lansare cu mai multe echipe care lucrează în același depozit. Chiar dacă ramurile de lansare sunt de scurtă durată, dacă verificarea finală durează prea mult, atunci oprește cealaltă echipă să elibereze. O echipă care se sprijină pe ramura de lansare a altei echipe este probabil să introducă erori și să provoace întârzieri pentru ambele echipe. Uitați-vă la modelul de lansare marcat cu ora de mai jos, care funcționează mai bine pentru un număr mai mare și grupuri de colaboratori.

Lansări marcate de timp

Aplicațiile cu restricții de infrastructură își programează de obicei implementările în perioadele cu trafic redus. Dacă proiectul dvs. se confruntă cu cozi regulate de funcții gata de implementare, atunci puteți beneficia de utilizarea versiunilor marcate de timp .

O ediție marcată de timp se bazează pe procesul de implementare pentru a adăuga automat o etichetă de marcare temporală la ultima comitere de pe ramura principală care a fost implementată în producție. Ramurile de subiecte sunt folosite pentru a trece o caracteristică prin procesul de dezvoltare înainte de a fi îmbinate în ramura principală pentru a aștepta implementarea.

Eticheta timestamp ar trebui să includă un timestamp real și o etichetă pentru a indica faptul că reprezintă o implementare, de exemplu: deployed-201402121345 .

Includerea metadatelor de implementare, sub forma etichetei timestamp din arborele de comitere al ramurii master, vă va ajuta la depanarea regresiilor lansate în aplicația de producție. Persoana însărcinată cu depistarea cauzei problemei este puțin probabil să știe multe despre fiecare linie care este implementată în aplicația de producție. Rularea unei comenzi git diff pe ultimele două etichete poate oferi rapid o imagine a ce commit-uri au fost implementate ultima dată și cine sunt autorii commit-urilor care ar putea ajuta la rezolvarea problemei.

Ramurile marcate de timp sunt mai mult decât apar la suprafață. Un mecanism simplu pentru înregistrarea unei implementări de caracteristici puse în coadă necesită o cantitate surprinzătoare de proces bun pentru a o conduce. Procesul este unul care se poate scala și funcționează bine și cu o echipă mică de colaboratori.

Pentru ca acest model de flux de lucru Git să fie cu adevărat eficient, este nevoie ca ramura principală să fie întotdeauna implementabilă. Asta ar putea însemna lucruri diferite pentru echipa ta, dar în esență toate commit-urile trebuie să fi trecut prin procesul de dezvoltare a proiectelor tale înainte de a ajunge în ramura principală.

Noile comiteri care ajung pe ramura principală vor avea loc de mai multe ori pe zi. Aceasta este o problemă pentru ramurile de subiecte care au trecut prin procesul de dezvoltare și nu au fost sincronizate cu ramura principală în acest timp. Din păcate, un astfel de scenariu poate introduce regresii în ramura principală atunci când conflictele de îmbinare sunt tratate incorect.

Dacă apar conflicte de îmbinare între o ramură de subiect și ramura principală, atunci riscul introducerii unei noi erori ar trebui discutat cu echipa înainte de a actualiza ramura principală la distanță. Dacă există vreo îndoială că ar putea apărea o regresie, atunci ramura subiectului poate fi repusă prin procesul de asigurare a calității, conflictele de îmbinare rezolvate.

Pentru a reduce erorile de integrare, dezvoltatorii care lucrează la părți conexe ale depozitului pot colabora pentru a stabili momentul cel mai bine să îmbine și să-și sincronizeze ramurile subiectului cu ramura principală. Ramurile de integrare funcționează bine pentru a rezolva conflictele și din ramurile subiectului conexe - acestea ar trebui supuse procesului de testare înainte de a fi îmbinate în coada de pe ramura principală în așteptarea implementării.

Proiectele de dezvoltare software cu mulți colaboratori trebuie să se ocupe de procese de colaborare și de management al lansărilor cu abordări practice și eficiente. Metadatele suplimentare din arborele de comitere pe care le obținem în urma utilizării versiunilor marcate de timp sunt un indicator către previziunea echipelor care se pregătesc să răspundă la problemele de producție.

Versiune Branch

Dacă aveți un depozit pe care nu îl rulați numai în producție, ci și alții îl folosesc pentru propriile aplicații găzduite, atunci folosirea ramurilor de versiuni poate oferi echipei dvs. platforma pentru a sprijini utilizatorii care nu sunt sau nu pot rămâne la vârful dezvoltării aplicației dvs. .

Un depozit care utilizează ramuri de versiune va avea o ramură pentru fiecare versiune minoră a aplicației. Versiunile majore, minore și patch-uri sunt explicate în documentația Semantic Versioning. Ramurile de versiuni urmează de obicei o convenție de denumire pentru a include cuvântul „stabil” și a elimina numărul patch-ului din versiunea aplicației: de exemplu 2-3-stable pentru a face ca scopul și fiabilitatea lor să fie evidente pentru utilizatorii finali.

Etichetele Git pot fi aplicate până la numărul versiunii de corecție a aplicației, dar ramurile versiunii nu sunt atât de granulate. O ramură de versiune va indica întotdeauna cea mai stabilă comitere pentru o versiune minoră acceptată.

Când apar corecțiile de securitate sau nevoia de backport a funcționalității, adunați commit-urile necesare pentru a funcționa pentru versiunile mai vechi de aplicații pe care le suportați și, respectiv, împingeți-le în ramurile versiunii dvs.

NU utilizați ramuri de versiune decât dacă acceptați mai multe versiuni ale depozitului dvs.

rezumat

Când echipa ta își schimbă dimensiunea sau proiectul tău își dezvoltă procesele prin evaluare continuă, nu omite evaluarea și procesul Git. Utilizați tiparele din acest tutorial ca punct de plecare pentru a vă ajuta să vă direcționați pe calea dreptății fluxului de lucru Git.

Modelul din acest ghid vă poate ajuta să vă înarmați cu o anumită previziune în adaptarea sistemului dvs. de control al versiunilor distribuite pentru a funcționa pentru dvs. Dacă doriți să citiți despre fluxurile de lucru Git, asigurați-vă că consultați Gitflow, Github Flow și, cel mai important, uimitoarea documentație git-scm!