Cele mai bune practici Git – Cum să profitați la maximum de (g)it

Pull, Fetch, Commit, Push, Merge, Rebase – au reușit acești termeni să-și facă încă loc în viața de zi cu zi? Când Linus Torvalds și-a creat prima versiune de Git, el a descris-o drept „prostia de urmărire a conținutului”. Înainte rapid până astăzi, acest software gratuit open-source este acum cel mai popular sistem de control al versiunilor.

Ce este Git?

Nu ți-ai dori să poți da timpul înapoi uneori, ca să fi putut lua o decizie mai bună sau să faci lucrurile altfel? Ei bine, în lumea tehnologiei și a codificării, poți. Git este un sistem de control al versiunilor distribuit cu sursă deschisă, care salvează versiuni ale codului tău prețios de fiecare dată când faci orice modificări/adăugări la acesta. Deci, ori de câte ori trebuie să faceți rollback, alegeți doar versiunea de lucru și voila! Git permite, de asemenea, lucrul fără întreruperi în cadrul echipelor, deoarece dezvoltatorii lucrează simultan la copiile locale individuale. Fiecare schimbare a fiecărui membru al echipei este urmărită, menținând astfel transparența într-un flux organizat. Deci, ce este GitHub atunci? GitHub este un serviciu de găzduire a depozitelor pentru Git care are, de asemenea, o mulțime de funcții pentru a vă optimiza sistemul de control al versiunilor.
Flux de lucru Git

Fiecare organizație are un flux de lucru Git diferit. Cel mai de succes flux de lucru Git este cel care oferă echipei dvs. suficient spațiu pentru productivitate, maximizând în același timp eficiența rezultatelor lor. Ar trebui să fie scalabil cu dimensiunea echipei tale și ar trebui să minimizeze numărul de conflicte care pot apărea. Fluxul de lucru centralizat Git este baza pe care sunt construite alte fluxuri de lucru Git, cum ar fi fluxul de lucru de ramificare a caracteristicilor, fluxul de lucru de bifurcare, fluxul de lucru Gitflow etc. Ar trebui planificat un flux de lucru pentru a îmbunătăți și completa cultura organizației dvs. Pentru fiecare echipă, propriul flux de lucru Git.

De ce să folosiți Git?

1. Arhitectura distribuită

Spre deosebire de sistemele centralizate de control al versiunilor care obligă dezvoltatorii să acceseze un singur depozit central pentru a putea „checkout” și efectua modificări la fișierele individuale, Git urmează o abordare distribuită. În arhitectura distribuită, fiecare dezvoltator are propriile copii locale ale întregului depozit central, permițându-le să lucreze offline, să acceseze istoricul complet al reviziilor și să ramifice și să comaseze ușor.

2. Performanță puternică

Ramificarea, fuzionarea, comiterea etc. sunt cu adevărat ușoare și rapide cu fluxul de lucru Git datorită algoritmilor săi inteligenți de cunoaștere profundă care înțeleg tiparele de acces la T.

3. Este Securizat

Git stochează tot conținutul fișierului, inclusiv relațiile dintre versiuni și directoare, folosind criptografic un SHA1 ca algoritm de hashtag. Orice modificare accidentală sau rău intenționată a codului este complet urmăribilă.

4. Open-source

Fiind open-source, Git este gratuit, se bucură de un suport bun al comunității, verificat continuu pentru calitate și este susținut cu o mulțime de documentație și tutoriale pentru cursanți.

5. Lansări mai rapide

Dezvoltarea distribuită Git și ramificarea ușoară și crearea de noi caracteristici încurajează dezvoltatorii să facă schimbări mai frecvente într-un flux de lucru agil

Cele mai bune practici pentru Git

• Proiect nou? Un nou depozit

Are sens organizațional să creați un nou repo pentru fiecare proiect nou la care doriți să începeți să lucrați. Odată terminat, împingeți-l în GitHub.

• Optiune noua? Se ramifica

Acum că ați creat un nou proiect, ce ziceți de a crea câteva funcții Git noi? Git Branching vă permite să creați și să gestionați un flux de lucru organizat în cadrul depozitului dvs. Membrilor echipei li se pot atribui diverse ramuri Git, permițându-le să lucreze concomitent, dar într-o manieră izolata. Oferă întotdeauna un sens ramurii tale git, astfel încât ceilalți să știe la ce lucrezi exact.

• Începe-ți ziua rămânând la curent

Întotdeauna „rebazați” sau obțineți cea mai recentă, cea mai actuală versiune a proiectului (master) înainte de a începe să lucrați la funcțiile pe care le-ați creat/alocate. Nu doriți să faceți modificări la fișierele învechite.

• Aveți puncte de control periodice

Nu vă păstrați angajamentele pentru o mare schimbare. „Angajați” mici modificări frecvent, astfel încât codul să fie mai ușor de înțeles pentru dvs. și membrii echipei. Revenirea înapoi și urmărirea este, de asemenea, mai ușoară atunci când modificările sunt mici și frecvente.

• Ascunde-ți munca

Adesea, s-ar putea să întâlniți situații în care lucrați la o ramură Git, dar v-ați amintit brusc că aveți nevoie de lucru pe o altă ramură, dar nu doriți să „competeți” acele modificări pe jumătate făcute. Sau poate doriți pur și simplu o copie curată de lucru. „git stash” la salvare. Stashing vă permite să salvați modificările neterminate într-o stivă la care puteți reveni oricând!

• Zdrobirea lor comite

Dacă aveți mai puține comisioane în istoricul dvs., este mai ușor să monitorizați și să urmăriți unde ați greșit. Dacă doriți să păstrați un istoric de comitere curat, acesta este pentru dvs. Squash și îmbina toate commit-urile într-unul singur atunci când cererea de extragere este îmbinată.

• Trimiteți mesaje

Furnizați întotdeauna informații clare și ușor de înțeles în mesajul dvs. de angajare. Începeți prin a scrie un scurt rezumat al modificărilor dvs., lăsați un rând gol și apoi continuați cu o descriere detaliată a modificării. Nu vrei ca istoricul tău de comitere să arate așa :/

• Nu schimba istoria

Odată ce ați efectuat modificările în depozit, nu reveniți și modificați istoricul. Deși Git vă permite să faceți asta și să rescrieți istoria pubiană, nu este niciodată o practică bună să faceți acest lucru. Atât pentru tine, cât și pentru echipa ta.

• Aplicați un patch Git

Uneori, când nu aveți acces de scriere la depozit, dar doriți totuși să remediați o eroare – aplicați o corecție Git. Nu uitați întotdeauna să clonați depozitul principal și apoi să creați o ramură pentru noua caracteristică. Când aveți gata fișierul .patch, previzualizați-l întotdeauna și faceți o rulare uscată pentru a verifica dacă există erori. Git aplică patch-ul (git apply -R path/file.patch) odată terminat. NU uitați să testați și să verificați

• Nu lăsați cererile de extragere prea mult timp

O solicitare de „tragere” deschisă poate crea conflicte mai devreme sau mai târziu. Nu le lăsați nesupravegheate mai mult de 2 zile. Examinați întotdeauna codul și, dacă este în regulă, îmbinați cererea de extragere. Acest lucru nu numai că va accelera procesul de expediere, dar va evita și conflictele de coduri.

• O mai bună organizare cu instrumente de management de proiect

Dacă ați folosit instrumente de management de proiect precum Redmine, este o bună practică să le utilizați împreună cu Git pentru a putea gestiona mai bine mai mulți membri ai echipei și sarcinile acestora. Crearea ramurilor dvs. Git cu sarcina Redmine ca nume este una dintre cele mai bune practici Git, deoarece permite o mai bună transparență și organizare.

• GitLab CI/CD

Utilizarea unui instrument de Integrare continuă/Implementare continuă ca acesta vă permite să testați și să verificați erori și erori și asigură compatibilitatea cu standardele de cod. Aceste joburi sunt efectuate după ce codul este împins către serverul intermediar.