Dacă scrieți software pentru o viață în 2018, atunci pot spune cu încredere că sunteți familiarizat cu Git. instrumentul creat de Linus Torvalds a devenit sinonim cu controlul versiunilor. Și fără îndoială, una dintre cele mai bune caracteristici ale lui Git este modul în care elimină durerea ramificării și fuzionării. Există mai multe moduri în care puteți crea o sucursală în Git. În această postare, vom analiza unele dintre ele. Apoi, vom încheia cu o mică reflecție asupra modelului de ramificare Git și a ramificării în general.

Crearea unei ramuri de la Master

Creați sucursale în Git, în mod surprinzător, utilizând comanda sucursală. La fel ca multe alte comenzi Git, „sucursală” este foarte puternică și flexibilă. Pe lângă crearea sucursalelor, poate fi folosită și pentru listarea și ștergerea acestora și puteți personaliza în continuare comanda folosind o listă largă de parametri. Vom începe cu primul mod de a crea o ramură. Să spunem că doriți să creați un folder nou numit „aplicația mea”, introduceți-l și începeți un nou depozit Git. Exact așa ați face-o:

mkdir my-appcd my-appgit init

Acum aveți un depozit Git nou, gol. Dar depozitele goale sunt plictisitoare. Deci, ce zici de crearea unui nou fișier de reducere cu „Hello World!” scris? / p>

echo Hello World! > file.md

Dacă rulați „starea git”, ar trebui să vedeți un mesaj care să spună că fișierul dvs. nu este urmărit:

Totuși, fișierele care nu sunt urmărite sunt, de asemenea, neclare, așa că haideți să o urmărim:

git add file.md

Și, în sfârșit, să creăm primul commit:

git commit -m "First commit"

Acum avem un depozit cu o ramură, care are exact o commit. S-ar putea să nu sune ca cel mai interesant lucru din lume (pentru că nu este într-adevăr), dar este cu siguranță mai puțin plictisitor decât să ai un repo fără comisioane, nu? Acum, să spunem că, din orice motiv, trebuie să schimbi fișierul „Conținutul. Dar tu nu” simți că faci asta. Ce se întâmplă dacă ceva nu merge bine și cumva stricați conținutul frumos și curat al fișierului dvs.? (Da, știu că este doar un fișier prost cu „Hello World!” În el, dar folosiți minunatele puteri ale imaginației dvs. și gândiți-vă la fișier ca la un proxy pentru un proiect mult mai complex.) Soluția la această dilemă Desigur, creează o ramură nouă:

git branch exp

Deci, acum avem o nouă ramură numită „exp”, pentru experimentare Unii oameni obișnuiți să folosească diferite sisteme de versionare, în special cele centralizate, ar putea spune că ramurile au același „conținut”. Totuși, acest lucru nu este complet corect atunci când vorbim despre Git. Gândiți-vă la ramuri precum referințe care indică un commit dat.

Crearea unei ramuri dintr-un commit

Să presupunem că, indiferent de motiv, renunțăm la experimentul nostru, fără a adăuga un singur angajează-te la noua ramură. Să revenim la master și să ștergem ramura exp:

git checkout mastergit branch -d exp

Acum că ne întoarcem la o singură ramură, să adăugăm câteva angajamente la el, pentru a simula munca realizată:

Imaginați-vă că, după ce ați făcut toate aceste „lucrări”, aflați că, din orice motiv, trebuie să vă întoarceți în timp la au fost doar două linii în fișier și au creat noi modificări de atunci. Dar, în același timp, trebuie să păstrați progresul pe care l-ați făcut deja. Cu alte cuvinte, doriți să creați o ramură dintr-un commit trecut. Cum ați face asta ? În Git, fiecare commit are un identificator unic. Deci, puteți vedea cu ușurință acest lucru folosind comanda „git log”. Pentru a crea o nouă ramură bazată pe o anumită commit, treceți doar hash-ul ca parametru la comanda branch:

git branch new-branch 7e4decb

Ca o parte, nici măcar nu aveți nevoie de întregul hash de cele mai multe ori. Doar primele cinci sau șase caractere o vor face.

Crearea unei ramuri dintr-o etichetă

Dacă aveți un pic mai multă experiență în Git, atunci ar trebui să fiți familiarizați cu concept de etichete. Utilizați etichete pentru a indica faptul că o anumită confirmare este importantă sau specială într-un fel. De exemplu, etichetele sunt utilizate în general pentru a indica versiunile reale ale unui produs. Dacă ați lucrat în aplicația dvs. de ceva timp și credeți că este timpul să lansați versiunea 1.0, ceea ce ați face în mod obișnuit este să bateți numerele de versiune ori de câte ori este necesar, să comiteți aceste modificări și apoi să adăugați o etichetă la acel moment specific din timp. Pentru a crea o etichetă, de obicei executați așa ceva:

git tag -a v1.0 -m "First major version"

Parametrul „-a” indică faptul că se întâmplă să fie o etichetă adnotată. Spre deosebire de o etichetă ușoară, acesta este un obiect Git complet, care conține informații cum ar fi numele și adresa de e-mail a comitetului, marcajul de timp și un mesaj. Acum aveți o etichetă, o indicație că acest punct special din istorie este special și are un nume. Grozav. Puteți continua să lucrați, ca de obicei, creând și comitând modificări care vor face parte din versiunea 1.1. Până la apariția unui raport de erori. Unii clienți care au fost actualizați la 1.Versiunea 0 a produsului spune că o caracteristică de import nu funcționează conform intenției. Ei bine, teoretic ați putea remedia eroarea din ramura principală și o puteți implementa. Dar apoi clienții ar primi caracteristici potențial netestate și incomplete. Asta nu este -Nu. Deci ce faci? Răspunsul: creați o ramură nouă din eticheta pe care ați creat-o pentru a indica versiunea majoră. Remediați problema acolo, creați și implementați. Și probabil ar trebui să fuzionați acest lucru înapoi la master, astfel încât următoarele versiuni să conțină remedierea . Cum ați face acest lucru? Ușor:

git branch <NAME-OF-THE-BRANCH> <TAG>

Mai precis, folosind exemplul nostru anterior:

git branch fix-bug-123 v1.0

După aceea, puteți verifica noua filială ca de obicei. Sau mai bine, puteți face totul într-un singur pas:

git checkout -b fix-bug-1234 v1.0

Crearea unei sucursale în starea capului detașat

Ați dorit vreodată să vă întoarceți în timp? Cu Git acesta este posibil … cel puțin în ceea ce privește fișierele din depozitul nostru. Puteți, în orice moment, să verificați un commit dacă știți hash-ul său:

git checkout <SHA1>

După ce ați rulat acest lucru, Git vă va afișa un mesaj curios:

You are in "detached HEAD" state. You can look around, make experimentalchanges and commit them, and you can discard any commits you make in thisstate without impacting any branches by performing another checkout.

Când verificați un commit, intri într-un stat special c aled, după cum puteți vedea, „cap detașat”. În timp ce puteți să comiteți modificări în această stare, aceste confirmări nu aparțin niciunei sucursale și vor deveni inaccesibile de îndată ce verificați o altă sucursală. Dar dacă doriți să păstrați aceste confirmări? Răspunsul, în mod surprinzător, este să utilizați comanda „checkout” din nou pentru a crea o nouă ramură:

git checkout <sha1> #now you"re in detached head state# do some work and stage itgit commit -m "add some work while in detached head state"git branch new-branch-to-keep-commitsgit checkout new-branch-to-keep-commits

Și, bineînțeles, până acum știi că poți scrie ultimele două linii ca o singură comandă:

git checkout -b new-branch-to-keep-commits

Destul de ușor, nu?

Doar pentru că poți … Nu înseamnă că ar trebui să

Modelul de ramificare Git este unul dintre punctele sale de vânzare. Transformă ceea ce în alte sisteme de control sursă este un proces dureros și chiar lent într-o briză. S-ar putea spune că Git a democratizat cu succes ramificarea pentru mase. Dar există un pericol grav. Datorită ieftinității ramificării în Git, unii dezvoltatori ar putea cădea în capcana de a lucra cu sucursale extrem de longevive sau de a folosi fluxuri de lucru sau modele de ramificare care întârzie inte gratie. Noi, ca industrie, am fost acolo. „Am făcut asta. Nu funcționează. În schimb, îmbrățișați fluxuri de lucru care utilizează ramuri extrem de scurte. Veți avea o cutie de nisip sigură în care să codificați, fără teama de a sparge lucruri sau de a vă pierde timpul colegilor. Dar vă întrebați „Cum implementez codul cu funcții parțial finalizate?” În acest caz, acesta prezintă steaguri de salvare. Ramurile Git sunt un instrument puternic. Folosiți-le cu înțelepciune și nu le abuzați. Și când acestea nu sunt suficiente, utilizați livrare continuă / integrare continuă împreună cu semnalizatoare de caracteristici – inclusiv instrumente specializate la dispoziția dvs. – astfel încât aplicațiile dvs. să poată ajunge la nivelul următor.