Fluxuri de lucru și utilizare Git avansate

Recent, am analizat elementele de bază pentru începerea utilizării Git pentru controlul sursei în proiectele dvs. Deși acesta este un punct de plecare excelent, există o grămadă de alte comenzi și fluxuri de lucru Git care vă vor ajuta să vă înțelegeți folosind Git în munca de codificare zilnică.

Fluxuri de lucru Git

Când am început să folosesc Git, mi-am dat seama că știu cum să-l folosesc corect. Abordarea mea ideală a fost să fac toate modificările într-un singur loc, fără ramuri, apoi să le angajez în depozit și să continui să lucrez.

Deși era mai bine decât să nu folosesc controlul versiunilor, mi-a luat ceva timp să realizez că nu foloseam cea mai mare parte a puterii oferite de Git. Pentru ca Git să funcționeze pentru mine, trebuia să am o strategie de ramificare și de îmbinare a modificărilor mele.

Apoi a apărut git-flow și l-am adoptat ca strategie. Îmi amintesc încă că am simțit că mă uitam în spatele unei perdele unde se aflau uimitorii dezvoltatori. Acum aveam o perspectivă asupra modului în care lucrau și puteam începe să devin unul dintre ei.

Dar git-flow nu se potrivește fiecărui scenariu, așa că, în timp ce îl vom analiza, vom arunca o privire și asupra altor câteva metode de a vă menține organizate proiectele Git, inclusiv modul în care îmi gestionez proiectele ca dezvoltator singur.

git-flow

Privind acum git-flow, recunosc că peisajul software s-a schimbat foarte mult în 10 ani și git-flow poate să nu fie cea mai bună opțiune pentru echipa ta. Când a fost scris git-flow, era rar să implementezi o aplicație de mai multe ori pe zi. În schimb, probabil ați făcut un număr major de versiune și ați lansat la fiecare câteva luni sau săptămâni dacă ați fost într-o echipă deosebit de agilă.

Să aruncăm o privire la ce este git-flow.

Dacă doriți să vedeți explicația completă și profundă cu diagrame și comenzi Git pentru Git Flow, ar trebui să citiți această postare.

În git-flow, două ramuri au o durată de viață infinită. În primul rând, principal, care ar trebui să reflecte codul care este gata să fie implementat în mediul dvs. live/de producție.

În al doilea rând, avem filiala noastră de dezvoltare. Această ramură ar trebui să aibă cele mai recente modificări care sunt gata pentru următoarea ediție a software-ului nostru. Când modificările din dezvoltare sunt gata să fie implementate în aplicația noastră live, le îmbinăm în ramura principală și le etichetăm cu numărul versiunii care corespunde cu numărul versiunii.

În afara celor două ramuri majore, există trei tipuri de ramuri de susținere.

1. Caracteristică

O ramură caracteristică poate fi făcută numai din ramura de dezvoltare. Trebuie fuzionat înapoi în ramura de dezvoltare. Denumirea poate fi orice descriere a caracteristicii la care lucrați.

Când lucrarea este gata pentru următoarea ediție, este fuzionată înapoi în ramura de dezvoltare unde așteaptă timpul de lansare.

2. Eliberare

Ramurile de lansare sunt făcute din ramura de dezvoltare și trebuie să fuzioneze înapoi atât în ​​dezvoltare, cât și în principal. Numiți o ramură de lansare cu convenția release-x. În practică, asta înseamnă de obicei că ai denumi o ramură cu numărul ediției pe care intenționezi să-l folosești astfel: release-2.2

Utilizați o ramură de lansare ca modalitate de a face pregătirea finală pentru a vă lansa software-ul. Aceasta poate include creșterea numărului de versiuni al fișierelor, asigurarea faptului că traducerile sunt finalizate sau verificările finale ale codului.

3. Remediere rapidă

Ramura de remediere rapidă este făcută din ramura principală și este folosită pentru a conține modificările care trebuie rezolvate imediat în aplicația live. Acesta poate fi o eroare care trebuie remediată sau o problemă de securitate care trebuie rezolvată.

Odată ce problema este rezolvată și implementată în filiala principală, veți eticheta codul cu numărul de versiune adecvat.

Cel mai mare motiv pentru care echipele nu folosesc acum git-flow este că modul în care lansăm software-ul sa schimbat. În loc de versiuni mai mari mai rar, puteți lansa o modificare a unei aplicații de câteva ori pe zi. Știu că împing munca pe site-urile clientului meu de multe ori pe săptămână, de îndată ce este gata. Nu facem numere de versiune ale site-ului, ci doar îl îmbunătățim în continuare.

git-flow standard nu este menit să găzduiască acest lucru.

Github Flow

A doua opțiune pe care o folosesc mulți oameni este Github Flow.

Singura regulă mare a Github Flow este că orice cod se află pe ramura principală poate fi implementat în orice moment, deoarece este gata de producție.

Toate ramurile sunt create din ramura principală cu un nume descriptiv pentru orice faci.

După ce aveți modificările pregătite, creați o cerere de extragere.

Solicitările de extragere le spun celorlalți care lucrează la același cod că munca pe care o desfășurați este gata să fie revizuită înainte ca aceste modificări să fie îmbinate în codul principal.

După ce ați trimis o cerere de extragere, echipa cu care lucrați poate examina modificările și poate oferi feedback. Dacă cererea de extragere este considerată gata de îmbinare, atunci aceasta este îmbinată în ramura principală a proiectului dvs.

Un dezavantaj al fluxului Github pentru un singur dezvoltator sau o echipă foarte mică este că administrarea unei cereri de extragere poate crea o suprasolicitare suplimentară în gestionarea proiectului. Acesta este motivul pentru care nu le folosesc în munca mea.

Cum folosesc fluxurile de lucru Git cu proiecte client

În munca mea de client, de obicei sunt singurul care scrie cod zilnic pentru un proiect. Clientul meu poate să actualizeze pluginurile WordPress sau să modifice unele CSS, dar nu fac nicio muncă majoră de codare. Asta înseamnă că, dacă aș merge cu fluxul Github, mi-aș revizui cererile de extragere care creează doar bătăi de cap suplimentare în management. Să ne uităm la sistemul pe care îl folosesc, care seamănă atât cu git-flow cât și cu Github flow.

Am două ramuri principale numite principal și scenă. Sucursala principală urmărește orice cod care rulează în prezent pe site-ul de producție. Ramura de staging urmărește orice este testat pe site-ul de staging pe care îl folosim pentru a testa modificările înainte de a le împinge pe site-ul live.

Fiecare ramură este creată din ramura principală. Noile funcții primesc un nume ca acesta: feature/32-new-feature. În acest context, numărul 32 corespunde numărului de bilet din sistemul nostru de management al proiectelor, iar cuvintele de după acesta sunt o scurtă descriere a ceea ce se lucrează. Remedieri de erori sunt denumite în mod similar, bug/20-bug-name.

Fiecare sucursală creată este fuzionată mai întâi în filiala noastră de staging, iar apoi, odată aprobată de client sau testată de mine, este fuzionată în filiala principală. Acest flux de lucru poate arăta așa.

# îmbinați funcția în ramura de staging

git merge feature/32-new-feature

# implementați și testați caracteristica

git checkout principal

git merge feature/32-new-feature

# implementează funcția pe site-ul live

În proiectele mele, am configurat o implementare continuă, ceea ce înseamnă că de fiecare dată când împing codul în principal, acesta este trimis automat pe site-ul live. Același proces este configurat pentru ramura de staging.

Dacă aș lucra cu o echipă care ar putea să-mi verifice codul într-un flux de lucru cu cerere de extragere, atunci aș folosi acest sistem pentru că funcționează bine într-o echipă. Pentru un dezvoltator care lucrează în mare parte pe cont propriu, este pur și simplu cheltuielile generale de gestionare care vă vor încetini fluxul de lucru.

Comenzi Git avansate pe care le folosesc

Acum că avem o idee despre cum putem folosi Git într-un flux de lucru practic, să aruncăm o privire la comenzile mai avansate care vor fi necesare pentru ca acest lucru să se întâmple. Folosesc fiecare dintre aceste comenzi de cel puțin câteva ori pe săptămână în timp ce lucrez cu codul clientului meu.

Chiar dacă veți folosi o aplicație GUI (am menționat unele bune în ultima mea postare pe Git) este totuși important să înțelegeți ce se întâmplă în fundal. De multe ori a trebuit să lucrez prin terminal pentru a remedia o problemă care a fost creată de o aplicație GUI Git.

Adăugarea modificărilor după linie

Singura comandă care a făcut ca Git să fie folosit prin intermediul terminalului să facă clic pentru mine a fost git add -p. Până am învățat această comandă, am folosit aplicații GUI pentru că aș face modificări în codul meu, dar vreau să despart linii specifice în diferite comite, astfel încât să pot explica de ce am făcut o schimbare. Pentru a face acest lucru, am folosit un GUI pentru a selecta liniile, dar git add -p vă ghidează printr-o interfață interactivă pentru a adăuga modificări în bucăți.

O folosesc de multe ori în fiecare zi.

Urmăriți sucursala Git de la distanță

Dacă eliminați un depozit existent și aveți ramuri precum main și staging pe care trebuie să le urmăriți, dar există deja, trebuie să spuneți versiunilor locale ale ramurilor să urmărească acele versiuni la distanță ale ramurilor.

Există câteva moduri de a face acest lucru.

# Setați în amonte când apăsați la distanță

git push -u origin staging

# Setați în amonte

# presupune că vă aflați în ramura pe care doriți să o urmăriți în prezent cu telecomandă

git branch -u origin/staging

git branch --set-upstream-to=origin/staging

# Dacă nu sunteți în ramura pe care doriți să o urmăriți, astfel încât să specificați ramura la sfârșit

git branch --set-upstream-to=origin/staging staging

Salvați modificările fără a le efectua

Uneori te vei afla în mijlocul unor lucrări care nu sunt încă pregătite pentru a fi angajate, dar trebuie să-i salvezi starea. Acolo este util git stash. Această comandă ascunde modificările pentru dvs. eliminând modificările. Le puteți recupera folosind git stash pop. Mai sunt câteva comenzi pentru ca stash să fie util, dar acestea sunt cele două pe care le folosesc în mod regulat.

Trageți un anumit Git Commit

Uneori trebuie să atragi un anumit angajament în munca ta curentă. Cu un HEAD curat (nu ați făcut încă nicio modificare) puteți efectua un anumit commit cu git cherry-pick . Puteți găsi documentația completă despre git cherry-pick aici.

Pentru fiecare commit, Git construiește o secvență lungă de litere și numere care este numită un obiect Git și denumită în mod obișnuit SHA. Deoarece fiecare commit primește unul, puteți face referire la un commit cu valoarea sa SHA. Citiți mai multe despre obiectele Git.

Aruncați schimbările de care nu aveți nevoie

La un moment dat în orice proiect, vom face modificări și apoi vom realiza că nu funcționează și trebuie pur și simplu să le renunțăm și să o luăm de la capăt. În loc să încercăm să anulăm până când ne întoarcem unde vrem să fim, putem folosi următoarea comandă Git pentru a elimina orice modificări care nu au fost încă urmărite.

git reset --hard

Comanda de mai sus vă va reseta codul înapoi la cea mai recentă comitere din ramura la care lucrați în prezent. De asemenea, am putea folosi un <#commitSHA> cu această comandă pentru a reseta la o anumită comitere dacă dorim să revenim la o stare înainte de ultima comitere. Poate ați folosi acest lucru pentru a reseta la verificarea inițială a sucursalei, deoarece întreaga valoare a lucrării de ramură nu este ceva ce doriți să păstrați, dar ați urmărit deja o parte din muncă.

Pentru a face un pas mai departe, putem arunca orice fișiere sau directoare care nu au fost încă urmărite în git cu comanda git clean.

git clean -fd: steagurile f și d îi spun lui git să arunce fișierele și directoarele care nu sunt urmărite.

Îndepărtați ramurile

În fiecare săptămână sau două mă uit la rezultatele unei comenzi git status și constat că am prea multe ramuri pentru a înțelege în mod rezonabil ce se întâmplă în depozitul meu. Asta înseamnă că pot elimina orice ramuri care corespund biletelor care au fost rezolvate cu următoarele comenzi.

# elimină versiunea locală

git branch -d $branchname

#elimină ramura de pe telecomandă

git push $remotename --delete $branchname

Utilizați Controlul versiunilor

Deși este posibil să nu fii un expert în toate comenzile Git pe care le vei folosi, un lucru important de reținut este că ar trebui să folosești controlul versiunii . Chiar dacă sunteți singura persoană care lucrează la un proiect, utilizarea Git și a unui flux de lucru Git vă va ajuta să vă mențineți proiectele organizate. Nu va trebui să apăsați CTRL + Z până când nu vă resetați munca după ce ați scris cod care nu a funcționat.

Veți putea avea încredere în sistemul dvs. și veți continua să produceți lucrări pentru proiectele dvs.

Încercați găzduirea WordPress complet gestionată

Aveți nevoie de găzduire optimizată pentru WordPress? Consultați astăzi planurile de găzduire WordPress complet gestionate ale Nexcess.