Dezvoltare bazată pe trunchi vs. Git Flow

Pentru a dezvolta software de calitate, trebuie să fim capabili să urmărim toate modificările și să le inversăm dacă este necesar. Sistemele de control al versiunilor ocupă acest rol urmărind istoricul proiectului și ajutând la îmbinarea modificărilor făcute de mai multe persoane. Ele accelerează foarte mult munca și ne oferă posibilitatea de a găsi bug-uri mai ușor.

Mai mult, lucrul în echipe distribuite este posibil în principal datorită acestor instrumente. Acestea permit mai multor persoane să lucreze la diferite părți ale unui proiect în același timp și ulterior să își unească rezultatele într-un singur produs. Să aruncăm o privire mai atentă asupra sistemelor de control al versiunilor și să explicăm cum a apărut dezvoltarea bazată pe trunk și fluxul Git.

Cum sistemele de control al versiunilor au schimbat lumea

Înainte ca sistemele de control al versiunilor să fie create, oamenii se bazau pe salvarea manuală a versiunilor anterioare ale proiectelor. Copiau manual fișierele modificate pentru a încorpora munca mai multor dezvoltatori în același proiect.

A costat mult timp, spațiu pe hard disk și bani.

Când ne uităm la istorie, putem distinge în linii mari trei generații de software de control al versiunilor.

Să aruncăm o privire la ele:

Observăm că, pe măsură ce sistemele de control al versiunilor se maturizează, există tendința de a crește capacitatea de a lucra la proiecte în paralel.

Una dintre cele mai inovatoare modificări a fost trecerea de la blocarea fișierelor la îmbinarea modificărilor. Le-a permis programatorilor să lucreze mai eficient.

O altă îmbunătățire considerabilă a fost introducerea sistemelor distribuite. Git a fost unul dintre primele instrumente care a încorporat această filozofie. Literal, a permis lumii open-source să înflorească. Git permite dezvoltatorilor să copieze întregul depozit, într-o operațiune numită forking, și să introducă modificările dorite fără a fi nevoie să-și facă griji cu privire la conflictele de îmbinare.

Mai târziu, ei pot începe o cerere de extragere pentru a-și îmbina modificările în proiectul original. Dacă dezvoltatorul inițial nu este interesat să încorporeze acele modificări din alte depozite, atunci le pot transforma în proiecte separate pe cont propriu. Totul este posibil datorită faptului că nu există conceptul de stocare centrală.

Stiluri de dezvoltare

În zilele noastre, cel mai popular sistem de control al versiunilor este cu siguranță Git, cu o cotă de piață de aproximativ 70 la sută în 2016.

Git a fost popularizat odată cu ascensiunea Linux și a scenei open-source în general. GitHub, în ​​prezent cel mai popular stocare online pentru proiecte publice, a contribuit, de asemenea, în mod considerabil la prevalența sa. Îi datorăm introducerea cererilor pull ușor de gestionat către Git.

Mai simplu spus, cererile pull sunt cereri create de un dezvoltator de software pentru a combina modificările pe care le-au creat cu proiectul principal. Include un proces de revizuire a acestor modificări. Recenziatorii pot introduce comentarii pentru fiecare parte pe care cred că ar putea fi îmbunătățită sau pe care o consideră inutilă.

După ce a primit feedback, creatorul poate răspunde la acesta, creând o discuție sau pur și simplu îl poate urmări și își poate schimba codul în consecință.

Git este doar un instrument. Îl poți folosi în multe moduri diferite. În prezent, două stiluri de dezvoltare cele mai populare pe care le puteți întâlni sunt fluxul Git și dezvoltarea bazată pe trunk. Destul de des, oamenii sunt familiarizați cu unul dintre aceste stiluri și s-ar putea să îl neglijeze pe celălalt.

Să le aruncăm o privire mai atentă la ambele și să aflăm cum și când ar trebui să le folosim.

Git Flow

În modelul de dezvoltare a fluxului Git, aveți o ramură principală de dezvoltare cu acces strict la aceasta. Este adesea numită ramura de develop .

Dezvoltatorii creează ramuri de caracteristici din această ramură principală și lucrează la ele. Odată ce au terminat, ei creează solicitări de extragere. În cererile de extragere, alți dezvoltatori comentează modificările și pot avea discuții, adesea destul de lungi.

Este nevoie de ceva timp pentru a conveni asupra unei versiuni finale a modificărilor. Odată ce sa convenit, cererea de extragere este acceptată și fuzionată cu ramura principală. Odată ce s-a decis că ramura principală a atins suficientă maturitate pentru a fi eliberată, se creează o ramură separată pentru a pregăti versiunea finală. Aplicația din această ramură este testată și se aplică remedieri de erori până în momentul în care este gata să fie publicată pentru utilizatorii finali. Odată ce s-a terminat, îmbinăm produsul final cu ramura master și îl etichetăm cu versiunea de lansare. Între timp, pot fi dezvoltate noi caracteristici pe ramura de develop .

Mai jos, puteți vedea diagrama de flux Git, ilustrând un flux de lucru general:

Unul dintre avantajele fluxului Git este controlul strict. Doar dezvoltatorii autorizați pot aproba modificările după ce le examinează îndeaproape. Acesta asigură calitatea codului și ajută la eliminarea erorilor din timp.

Cu toate acestea, trebuie să rețineți că poate fi și un dezavantaj imens. Creează o pâlnie care încetinește dezvoltarea software-ului. Dacă viteza este preocuparea ta principală, atunci ar putea fi o problemă serioasă. Caracteristicile dezvoltate separat pot crea ramuri de lungă durată care ar putea fi greu de combinat cu proiectul principal.

În plus, solicitările de tragere se concentrează asupra revizuirii codului numai pe codul nou. În loc să privească codul ca întreg și să lucreze pentru a-l îmbunătăți ca atare, ei verifică doar modificările nou introduse. În unele cazuri, acestea pot duce la o optimizare prematură, deoarece este întotdeauna posibil să implementați ceva pentru a funcționa mai rapid.

În plus, solicitările de extragere pot duce la un micromanagement extins, în care dezvoltatorul principal gestionează literalmente fiecare linie de cod. Dacă aveți dezvoltatori cu experiență în care puteți avea încredere, ei se pot descurca, dar este posibil să le pierdeți timpul și abilitățile. De asemenea, poate demotiva sever dezvoltatorii.

În organizațiile mai mari, politica de birou în timpul solicitărilor de retragere este o altă preocupare. Este posibil ca persoanele care aprobă solicitările de extragere să-și folosească poziția pentru a bloca în mod intenționat anumiți dezvoltatori să facă modificări la baza de cod. Ei ar putea face acest lucru din cauza lipsei de încredere, în timp ce unii ar putea abuza de poziția lor pentru a-și regla scorurile personale.

Avantaje și dezavantaje Git Flow

După cum puteți vedea, efectuarea solicitărilor de extragere ar putea să nu fie întotdeauna cea mai bună alegere. Acestea trebuie folosite numai acolo unde este cazul.

Când funcționează cel mai bine Git Flow?

• Când rulați un proiect open-source.
  Acest stil provine din lumea open-source și funcționează cel mai bine acolo. Deoarece toată lumea poate contribui, doriți să aveți acces foarte strict la toate modificările. Vrei să poți verifica fiecare linie de cod, pentru că, sincer, nu poți avea încredere în oamenii care contribuie. De obicei, acestea nu sunt proiecte comerciale, așa că viteza de dezvoltare nu este o problemă.

• Când ai o mulțime de dezvoltatori juniori.
  Dacă lucrați mai ales cu dezvoltatori juniori, atunci doriți să aveți o modalitate de a verifica munca lor îndeaproape. Le puteți oferi mai multe sfaturi despre cum să facă lucrurile mai eficient și să-i ajutați să-și îmbunătățească abilitățile mai rapid. Persoanele care acceptă solicitări de extragere au un control strict asupra modificărilor recurente, astfel încât să poată preveni deteriorarea calității codului.

  

• Când ai un produs stabilit.
  Acest stil pare să joace bine și atunci când ai deja un produs de succes. În astfel de cazuri, accentul se pune de obicei pe performanța aplicației și pe capacitățile de încărcare. Acest tip de optimizare necesită schimbări foarte precise. De obicei, timpul nu este o constrângere, așa că acest stil funcționează bine aici. În plus, întreprinderile mari sunt potrivite pentru acest stil. Ei trebuie să controleze îndeaproape fiecare schimbare, deoarece nu vor să-și rupă investiția de mai multe milioane de dolari.

Când Git Flow poate cauza probleme?

• Când tocmai începi.
  Dacă tocmai porniți, atunci Git flow nu este pentru dvs. Sunt șanse să doriți să creați rapid un produs minim viabil. Efectuarea solicitărilor de tragere creează un blocaj uriaș care încetinește dramatic întreaga echipă. Pur și simplu nu îți poți permite. Problema cu fluxul Git este faptul că solicitările pull pot dura mult timp. Pur și simplu nu este posibil să oferim o dezvoltare rapidă în acest fel.

• Când trebuie să repetați rapid.
  Odată ce ajungeți la prima versiune a produsului dvs., cel mai probabil va trebui să o pivotați de câteva ori pentru a satisface nevoile clienților dvs. Din nou, mai multe ramuri și cererile de extragere reduc dramatic viteza de dezvoltare și nu sunt recomandate în astfel de cazuri.

• Când lucrezi mai ales cu dezvoltatori seniori.
  Dacă echipa dvs. este formată în principal din dezvoltatori seniori care au lucrat unul cu altul pentru o perioadă mai lungă de timp, atunci nu aveți nevoie cu adevărat de micromanagementul cererii de pull menționat mai sus. Ai încredere în dezvoltatorii tăi și știi că sunt profesioniști. Lasă-i să-și facă treaba și nu-i încetinește cu toată birocrația fluxului Git.

Flux de lucru de dezvoltare bazat pe trunchi

În modelul de dezvoltare bazat pe trunchi, toți dezvoltatorii lucrează pe o singură ramură cu acces deschis la aceasta. Adesea este pur și simplu ramura master . Îi comit cod și îl rulează. Este super simplu.

În unele cazuri, ele creează ramuri caracteristice de scurtă durată. Odată ce codul de pe ramura lor este compilat și a trecut toate testele, îl îmbină direct în master . Se asigură că dezvoltarea este cu adevărat continuă și îi împiedică pe dezvoltatori să creeze conflicte de îmbinare greu de rezolvat.

Să aruncăm o privire asupra fluxului de lucru de dezvoltare bazat pe trunchi.

Singura modalitate de a revizui codul într-o astfel de abordare este să faceți o revizuire completă a codului sursă. De obicei, discuțiile lungi sunt limitate. Nimeni nu are control strict asupra a ceea ce este modificat în baza codului sursă - de aceea este important să existe un stil de cod aplicabil. Dezvoltatorii care lucrează în acest stil ar trebui să aibă experiență, astfel încât să știți că nu vor scădea calitatea codului sursă.

Acest stil de lucru poate fi grozav atunci când lucrați cu o echipă de dezvoltatori de software experimentați. Le permite să introducă noi îmbunătățiri rapid și fără birocrație inutilă. De asemenea, le arată că aveți încredere în ei, deoarece pot introduce cod direct în ramura master . Dezvoltatorii din acest flux de lucru sunt foarte autonomi – ei livrează direct și sunt verificați cu privire la rezultatele finale în produsul de lucru. Există cu siguranță mult mai puțin micromanagement și posibilități pentru politica de birou în această metodă.

Dacă, pe de altă parte, nu ai o echipă experimentată sau nu ai încredere în ea dintr-un motiv oarecare, nu ar trebui să mergi cu această metodă – ar trebui să alegi Git flow. Vă va scuti de griji inutile.

Avantaje și dezavantaje ale dezvoltării bazate pe trunchi

Să aruncăm o privire mai atentă la ambele părți ale costului - cele mai bune și foarte proaste scenarii.

Când funcționează cel mai bine dezvoltarea bazată pe trunchi?

• Când tocmai începi.
  Dacă lucrezi la produsul tău minim viabil, atunci acest stil este perfect pentru tine. Oferă viteză maximă de dezvoltare cu formalitate minimă. Deoarece nu există solicitări de extragere, dezvoltatorii pot oferi noi funcționalități la viteza luminii. Asigurați-vă că angajați programatori experimentați.

• Când trebuie să repetați rapid.
  Odată ce ai ajuns la prima versiune a produsului și ai observat că clienții tăi vor ceva diferit, atunci nu te mai gândi de două ori și folosește acest stil pentru a pivota într-o nouă direcție. Sunteți încă în faza de explorare și trebuie să vă puteți schimba produsul cât mai repede posibil.

• Când lucrezi mai ales cu dezvoltatori seniori.
  Dacă echipa ta este formată în principal din dezvoltatori seniori, atunci ar trebui să ai încredere în ei și să-i lași să-și facă treaba. Acest flux de lucru le oferă autonomia de care au nevoie și le permite să-și exercite stăpânirea profesiei. Doar oferiți-le un scop (sarcini de îndeplinit) și urmăriți cum crește produsul dvs.

Când dezvoltarea bazată pe trunchi poate cauza probleme?

• Când rulați un proiect open-source.
  Dacă rulați un proiect open-source, atunci Git flow este opțiunea mai bună. Ai nevoie de un control foarte strict asupra modificărilor și nu poți avea încredere în contribuitori. La urma urmei, oricine poate contribui. Inclusiv trolii online.

• Când ai o mulțime de dezvoltatori juniori.
  Dacă angajați în mare parte dezvoltatori juniori, atunci este o idee mai bună să controlați strict ceea ce fac aceștia. Solicitările stricte de tragere îi vor ajuta să-și îmbunătățească abilitățile și vor găsi mai rapid erori potențiale.

• Când ai stabilit un produs sau ai gestionat echipe mari.
  Dacă aveți deja un produs prosper sau gestionați echipe mari la o întreprindere uriașă, atunci fluxul Git ar putea fi o idee mai bună. Vrei să ai un control strict asupra a ceea ce se întâmplă cu un produs bine stabilit care valorează milioane de dolari. Probabil, performanța aplicației și capacitățile de încărcare sunt cele mai importante lucruri. Acest tip de optimizare necesită schimbări foarte precise.

Utilizați instrumentul potrivit pentru locul de muncă potrivit

După cum am spus mai devreme, Git este doar un instrument. Ca orice alt instrument, acesta trebuie utilizat în mod corespunzător.

Fluxul Git gestionează toate modificările prin solicitări de extragere. Oferă un control strict al accesului la toate modificările. Este excelent pentru proiecte open-source, întreprinderi mari, companii cu produse consacrate sau o echipă de dezvoltatori juniori fără experiență. Puteți verifica în siguranță ceea ce este introdus în codul sursă. Pe de altă parte, ar putea duce la un micromanagement extins, dispute care implică politici de birou și o dezvoltare semnificativ mai lentă.

Dezvoltarea bazată pe trunchi oferă programatorilor autonomie deplină și exprimă mai multă încredere în ei și în judecata lor. Accesul la codul sursă este gratuit, așa că trebuie să ai încredere în echipa ta. Oferă o viteză excelentă de dezvoltare a software-ului și reduce procesele. Acești factori îl fac perfect atunci când creați produse noi sau pivotați o aplicație existentă într-o direcție cu totul nouă. Face minuni dacă lucrați mai ales cu dezvoltatori experimentați.

Totuși, dacă lucrați cu programatori juniori sau oameni în care nu aveți deplină încredere, Git flow este o alternativă mult mai bună.

Dotat cu aceste cunoștințe, sper că vei putea alege fluxul de lucru care se potrivește perfect cu proiectul tău.