În tutorialele noastre anterioare pentru software-ul de control al versiunii git, am învățat comenzile esențiale de bază pentru utilizarea git, ca precum și cum să lucrați cu Github.com pentru a stabili un depozit și pentru a împinge codul proiectului nostru pe site.
Acum este timpul să începeți să lucrați efectiv cu GitHub (și git) așa cum trebuie să fie folosit: efectuarea de modificări în siguranță a proiectului într-o parte și îmbinarea acestora înapoi cu proiectul original odată ce s-au dovedit a fi corecte. Sau cel puțin nu dezastruos.
Până acum înțelegeți că git salvează fiecare versiune a proiectului dvs. ca instantaneu al codului exact așa cum a fost în momentul în care l-ați comis. Crearea, în esență, a unei cronologii a versiunilor unui proiect pe măsură ce progresează, astfel încât să puteți reveni la o versiune anterioară în caz de dezastru.
Modul în care git și GitHub gestionează această cronologie – mai ales atunci când sunt mai multe mai mult de o persoană lucrează în proiect și face modificări – este folosind sucursale. O ramură este în esență un set unic de modificări de cod cu un nume unic. Fiecare depozit poate avea una sau mai multe ramuri. Ramura principală – cea în care toate modificările se reunesc în cele din urmă și se numește master. Aceasta este versiunea oficială de lucru a proiectului dvs. și cea pe care o vedeți atunci când vizitați depozitul de proiecte la github.com/numele dvs./nume de proiect.
Nu vă încurcați cu maestrul. Dacă modificați ramura principală a unui proiect de grup în timp ce alți oameni lucrează și la el, modificările dvs. din mers se vor repeta pentru a afecta pe toți ceilalți și foarte repede vor apărea conflicte de îmbinare, plâns, îmbrăcare a hainelor, și plăgi de lăcuste. Este atât de grav.
De ce este atât de important stăpânul cu care să nu se încurce? Un singur cuvânt: ramura principală este implementabilă. Este codul dvs. de producție, gata să fie lansat în lume. Ramura master este menită să fie stabilă și este contractul social al software-ului open source care nu împinge niciodată, niciodată, ceva master care nu este testat sau care rupe construcția. Întregul motiv pentru care funcționează GitHub este că este întotdeauna sigur să lucrezi de la master.
Branching Out
În schimb, toată lumea folosește ramuri create de la master pentru a experimenta, a face modificări, adăugări și modificări , înainte de a rula în cele din urmă acea ramură înapoi în master odată ce au fost aprobate și se știe că funcționează. Masterul este apoi actualizat pentru a conține toate lucrurile noi.
Pentru a începe să lucrați la ceva nou într-un proiect sau pentru a schimba lucrurile existente, creați o ramură din ramura masteră stabilă. Să continuăm să lucrăm cu exemplul de proiect creat pentru tutorialul nostru anterior, bun studios_octo_carnival. Vă rugăm să deschideți acum versiunea pe computer și CD-ul în director.
Pasul 1: Faceți inventar.
Înainte de a crea noi sucursale, dorim să verificăm dacă există alte sucursale existente. . Știm despre stăpân, dar cine știe ce pot face colaboratorii noștri de proiect, acele maimuțe răutăcioase? Deci, putem vizualiza toate ramurile existente tastând „git branch -a” în terminal, ceea ce îi spune lui git că dorim să vedem TOATE ramurile din acest proiect, chiar și cele care nu se află în spațiul nostru de lucru local.
Aceasta returnează ieșirea pe care o vedeți în exemplul de cod de mai jos. Aspectul său poate varia oarecum în funcție de sistemul de operare și aplicația terminalului, dar informațiile sunt în cele din urmă aceleași. Asteriscul de lângă „master” din prima linie a ieșirii indică faptul că suntem în prezent pe acea ramură. A doua linie ne spune că pe originea noastră la distanță, numită, există o singură ramură, numită și master. (Amintiți-vă că telecomanda noastră este repo GitHub pentru acest proiect).
Pasul 2: creați o nouă ramură
Acum, că știm să vedem ramuri, să facem una! Țineți cont de faptul că avem filiala noastră principală, proiectul nostru original. Vom crea acum o nouă versiune a proiectului, o ramură, cu care să ne jucăm și să facem modificări la nivel local pe computerul nostru – în timp ce versiunea originală a proiectului, masterul, rămâne în siguranță neatinsă acolo sus pe GitHub. Dăm noii filiale un nume descriptiv pentru a ne reaminti ce intenționăm să facem în timp ce lucrăm în ea. În acest caz, va fi o chestie simplă „Hello World”, așa că hai să o numim hello_octo.
Pentru a crea această nouă ramură, tastați „git checkout -b branchNameHere” (deci, în cazul nostru, „git checkout -b hello_octo”).
Presupunând că nimeni altcineva nu a făcut deja o ramură numită „hello_octo”, git returnează „A trecut la o nouă ramură„ hello_octo ”.” (În cazul în care există deja o ramură cu acel nume, git ne-ar spune în schimb „fatal: o ramură numită„ hello_octo ”există deja.” Nu este mare lucru, doar faceți git checkout -b din nou cu o nouă variantă de nume).
Putem folosi și comanda git checkout pentru a comuta înainte și înapoi între cele două ramuri ale noastre. Tastați „git checkout branchName” pentru a comuta la acea ramură.Deci, „git checkout master” vă conduce la master, în timp ce „git checkout hello_octo” vă duce înapoi la hello_octo branch.
Dacă încercați să treceți la o ramură care nu există, cum ar fi „git checkout hello_kitty”, git vă va anunța că este o interzicere:
De unde știe git pe ce ramură vă aflați în prezent? Git urmărește întotdeauna ce faceți și păstrează un indicator special numit HEAD. Ca și acul de pe o busolă indică întotdeauna spre nord, HEAD indică întotdeauna sucursală locală în care vă aflați în prezent.
(Am fi putut crea, de asemenea, sucursala noastră folosind comanda git „git branch branchNameHere” și apoi să trecem la aceasta cu git checkout. Cu toate acestea, scurtătura îngrijită cu „-b” în „git checkout -b branchNameHere” creează ambele ramuri ȘI comută la ea. Nu vă pot spune câți codificatori noi-la-git generează mesaje de eroare și frustrare pentru că pur și simplu nu și-au amintit să se schimbe în noua lor ramură după crearea i t. Prin urmare, rămânem cu git checkout -b, mmmkay?)
Efectuăm modificări la ramura noastră de lucru
Acum că avem mai multe ramuri – ramura noastră de lucru pe care să facem modificări și filiala noastră principală rămânând în siguranță nemolestată – putem începe să lucrăm. În scenariul nostru, vom folosi ramura noastră „hello_octo” pentru a face și testa modificările noastre, apoi le vom împinge înapoi la ramura principală de pe GitHub.
Nu uitați să vă asigurați că sunteți pe ramură de lucru și nu master, cu ramură git veche bună -a.
Pasul 3. Creați un nou fișier gol, numit „hello_octo_world”:
(Acest fișier gol are doar scop demonstrativ, deci nu vă faceți griji că nu există un nume / tip de extensie de fișier).
Deoarece este nou, corect acum acest fișier este doar pe filiala dvs. Utilizați comanda „ls” pentru a o vizualiza:
Cu toate acestea, reamintim că ne aflăm în ramura noastră de lucru, hello_octo, unde am creat acest lucru nou. Maestrul nu știe nimic despre hello_octo, deoarece este izolat în siguranță de orice schimbări vrând-nevoi pe care le facem aici pe ramura de lucru. Este în continuare același maestru senin și neschimbat cu care am început:
Pasul 4: Etapați și trimiteți noul nostru fișier la ramura de lucru.
Acum este timpul să punem în scenă (adăugăm) și să angajăm noul nostru fișier pe ramura de lucru. (Sunteți familiar?). Aceasta va atașa această nouă entitate la ramura de lucru în pregătire pentru a o muta în cele din urmă la master. Acest fișier există acum pe ramura hello_octo; așa cum am văzut mai sus, nu există în prezent pe ramura principală.
În acest moment tocmai ați luat o instantaneu al modificărilor filialei. Într-un proiect din lumea reală, există probabil mai multe schimbări și funcționează să fie făcut. Acum este momentul în care ați merge să faceți acest lucru, făcând angajamente pe parcurs în puncte logice. Amintiți-vă că, pe GitHub, confirmările reprezintă salvările consecutive. Fiecare confirmare are un mesaj de confirmare asociat, care este o descriere care explică în mod specific ce ați făcut acolo și de ce. Mesajele de confirmare captează istoricul modificărilor dvs., astfel încât viitorul dvs., precum și alți colaboratori ai proiectului, să înțelegeți ce ați făcut și de ce.
Combinarea codului între ramuri
Odată ce sunt finalizate cu toate modificările și completările – și totul funcționează * – este timpul să fuzionăm. Partea interesantă vine după ce ne întoarcem la filiala noastră principală (care – spune-o cu mine! – o facem cu „git checkout master”). „Hello_octo_world” pare să lipsească, dar nu este – în prezent, există în funcționarea noastră ramură și suntem pe ramura noastră principală. Vă arăt din nou acest lucru, deoarece se află în centrul înțelegerii ramurilor din git:
Acum: în acest exercițiu , „hello_octo_world” reprezintă orice modificare a oricărui fișier (sau adăugarea unui fișier complet nou) care a trecut toate testele din ramura noastră de dezvoltare și este gata să fie în producție. Procesul de mutare a codului între ramuri (adesea de la dezvoltare la producție) este cunoscută sub numele de fuzionare.
Foarte important: atunci când fuzionăm, trebuie să fim pe ramura în care dorim să fuzionăm. Practic, îi vom spune git „Vedeți acel lucru nou? Este ok să îl aducem aici acum. ”
Pasul 5: Îmbinarea modificărilor ramurii de lucru
În acest caz, deoarece vrem să fuzionăm din ramura noastră de lucru, unde„ hello_octo_world ” fișierul există, în ramura noastră principală, trebuie să fim pe master.
Odată ce suntem în ramura principală, tot ce trebuie să facem este să rulăm comanda de îmbinare. Cel mai bun mod de a face acest lucru este să tastați „ git merge –no-ff ”- adiționalul„ –no-ff ”îi spune lui git că dorim să păstrăm toate mesajele de confirmare înainte de îmbinare. Acest lucru va facilita urmărirea modificărilor în viitor:
Revenirea la GitHub
Ultimul lucru pe care trebuie să-l facem acum este să îl anunțăm pe GitHub că ne-am străduit stăpâniți aici mediul nostru de dezvoltare locală.
Cu alte cuvinte, este timpul pentru git push. Ați obținut acest lucru!
Ieșirea git confirmă că îmbinarea de la ramura dvs. de dezvoltare la ramura principală din mediul dvs. local, a fost copiat acum pe serverul de la distanță: „master → master”.
Și gata! Am creat cu succes o ramură de lucru separată de master. Am făcut modificări la acesta. Am realizat aceste modificări. Am combinat-le apoi. înapoi la master în mediul nostru de lucru local. Apoi, în cele din urmă, am împins totul până la GitHub, astfel încât toate versiunile proiectului nostru să fie la fel, peste tot!
O notă finală
Câteva curățări este în ordine acum: deoarece am îmbinat cu succes ramura noastră hello_octo, nu mai avem nevoie de ea. Pentru a șterge o ramură combinată, pur și simplu tastați „git branch -d branchName”:
Nu vă faceți griji: dacă încercați din greșeală să ștergeți o ramură care nu a fost încă fuzionată, git va arunca o eroare.
Deci! Până aici am folosit un proiect eșantion extrem de simplificat, deoarece în acest moment cel mai important lucru este să înțelegem și să asimilăm fluxul de lucru git. Fuziunea are mult mai mult decât aceasta în lumea reală – de exemplu, ce se întâmplă dacă primiți mesaje de eroare deoarece îmbinarea dvs. are conflicte? Nu vă faceți griji, noul git-ster, vom ajunge acolo.
Tema dvs.: creați („atingeți”) mai multe fișiere noi în proiectul de exemplu și practicați-vă să faceți modificări, organizarea, angajarea și în cele din urmă fuzionarea acestora înapoi. Aveți grijă să înțelegeți unde vă îndreaptă HEAD – adică care este ramura dvs. actuală. Aduceți modificări numai ramurii dvs. de lucru.
Pentru că, amintiți-vă: Nu. Încurcați. Cu. Maestrul. .