Nu este cea mai exhaustivă, dar exactă abordare a lui Git, Github și Gitflow - pentru cei care sunt stânjeniți de aceste cuvinte, deși nu ar trebui.
Controlul versiunii ajută nu numai la evitarea jambilor enervant la efectuarea schimbărilor, dar este, de asemenea, necesar pentru munca în echipă pe proiect. În acest articol, vom examina comenzile de bază ale consolei și vom discuta despre cel mai popular model pentru gestionarea sucursalelor proiectului. Și despre ramurile, de asemenea, vom vorbi.
Git este un sistem de control al versiunii distribuite (VCS).
Versiunea înseamnă că stocați toate versiunile de documente care pot fi editate și puteți reveni oricând la orice versiune salvată. Se pare că o astfel de abordare este populară doar în rândul programatorilor, însă, de fapt, este folosită, de exemplu, de designeri și de alți oameni, mult mai înțeleși din punct de vedere tehnic, pentru a monitoriza schimbările în muncă.
Distribuția lui git'a o deosebește de celelalte vcs. În cadrul distribuției, ar trebui să înțelegem literalmente posibilitatea utilizării unui sistem de control al unui proiect de către un număr de dezvoltatori.
Apropo, Git a creat acest domn politicos:
Mai întâi, asigurați-vă că ați instalat Git.
Acum, tot ceea ce avem nevoie pentru a crea un depozit este comanda git init din directorul corect.
Deschideți linia de comandă și mergeți la Desctop (da, vom fi originale) și creați un director (de exemplu, proglib).
Acum, mergeți la noul director și rulați git init.
Totul, avem un depozit gol.
Să creăm un simplu fișier README.md, cum ar fi:
Acum, că știți cât de ușor este să lucrați cu ramificarea, nu veți fi surprins de faptul că mulți oameni au un fel de abordare a gestionării ramurilor.
Dar există o abordare populară în comunitate. Faceți cunoștință cu modulul popular de gestionare a firelor Gitflow:
Schema pare dezordonată când o vezi pentru prima dată, așa că să mergem în ordine. Avem două ramuri principale: master și dezvoltare.
Ramura master conține exact același cod ca și în versiunea de lucru (citită, produs) a proiectului. Și toată lucrarea se face în ramura dezvoltării.
În timpul lucrului pe baza dezvoltării, se creează așa-numitele ramuri de funcții. Ele pot fi un număr nelimitat.
Apoi, avem o filială de presă, care este folosită pentru a se pregăti pentru noua lansare a proiectului.
În cele din urmă, există o ramură de remediere rapidă, care servește pentru fixarea urgentă a bugurilor găsite, de exemplu, pe un produs.
Iată cum în teorie există un flux de lucru în Gitflow:
1. Se creează un depozit
2. Depozitul este inițializat
3. Începe lucrul la dezvoltarea ramurii
4. Este nevoie să încercați un lucru nou - se creează o ramură a caracteristicilor și se fac comitete
5. Când terminați lucrul la arborele cu caracteristică, îl îmbinați cu dezvoltarea
6. Dacă sunteți mulțumit de versiunea curentă, dar doriți să continuați să lucrați, este creată o ramură de lansare, unde versiunea curentă este mutată. Eroare de editare vor apărea pe aceeași ramură.
7. Când ramura de eliberare este terminată, este timpul să o îmbinați în master și să continuați să lucrați cu dezvoltarea
8. În plus, acest punct poate fi notat pe ramura-pilot
Vom face pasul de mai sus, dar mai întâi asigurați-vă că aveți gitflow-avh - un instrument pentru a lucra cu Gitflow. Pe mac poate fi instalat folosind homebrew:
git - flow - avh
gitflow-avh este o colecție de extensii pentru git care ajută la evitarea multor operații repetitive și, în general, ușurează viața (acest lucru nu este corect). De exemplu, atunci când lucrați cu o ramură de funcții, utilitarul va verifica dacă a fuzionat în dezvoltarea și ștergerea acestuia dacă totul ar merge bine. Desigur, puteți urma singur modelul Gitflow, făcând operațiuni cu mâinile, dar este mai ușor să folosiți o soluție gata, nu?
În continuare vor apărea câteva întrebări, însă dacă lăsați opțiunile în mod prestabilit, această comandă va crea și apela pur și simplu ramurile conform modelului Gtiflow.
Când totul se termină, veți vedea că sunteți pe ramura dezvoltării. Acum, creați un nou arbore de funcții:
git - flow caracteristică start new_docs
Apoi, deschideți README.md și efectuați modificările. După aceea, faceți o comitere:
git commit - m "A fost adăugată o nouă documentație"
Acum, dacă suntem cu toții fericiți, vom termina cu această ramură:
git - flow caracteristica finală new_docs
După cum puteți vedea în ieșirea consolei, această comandă a făcut următoarele:
1. Clătiți filialele new_docs și dezvoltați
2. Eliminat new_docs
3. Încheiați trecerea la ramura de dezvoltare, astfel încât să puteți continua să lucrați
Să presupunem că noua funcție ne convine, este testată și funcționează corect. Acum trebuie să facem o eliberare.
Pentru a începe, trebuie să executați următoarea comandă:
git - debitul de lansare 2.0
Aici puteți face rectificări potențiale recente, actualizați versiunea (este importantă pentru dezvoltarea aplicațiilor mobile) și așa mai departe.
Când lucrarea este terminată, scrieți pur și simplu:
git - debit finisare 2.0
Va trebui să adăugați mai multe mesaje și etichete, iar utilitarul va face următoarele:
1. Eliberați și sare principală
2. Va marca marcarea ca 2.0
3. Eliberați și dezvoltați sare
4. Șterge eliberarea
5. Va continua să se dezvolte
Uneori, lucrurile împreună seamănă cu elementele clasice:
Pe githaba puteți adăuga pe cineva pe care îl cunoașteți angajaților în setările Setări-colaboratori. Invitați în acest fel, participanților li se va permite să se strecoare în depozitul dvs. sau puteți crea o echipă de dezvoltare și puteți ajusta nivelurile de acces de la proiect la proiect.
Dar chiar dacă știți o persoană bine, s-ar putea să nu vă place întotdeauna că cineva se angajează să se angajeze în fața stăpânului fără să știe. Pentru astfel de cazuri în github există cereri de tragere și revizuire cod.
Acesta funcționează după cum urmează: faci un fel de îmbunătățire sau fixam featire-ramură, făcând cerere trage, unul dintre dezvoltatorii senior responsabile de proiect arată codul (de exemplu, face o revizuire cod), poate face orice comentarii și în cele din urmă adaugă codul în ramura de master (sau în altă parte).
De fapt, atitudinea față de revizuirea codului poate fi diferită. Din punct de vedere literal, de la
Și cum se referă la revizuirea codului? Desigur, acesta este un lucru foarte important și trebuie să aveți răbdare și să faceți o revizuire a întregului pachet de rechizite, dacă este vorba de proiectul dvs., de exemplu. Pe termen lung, se va plăti. Și, bineînțeles, este ușor să spui "fă-o", dar, în unele cazuri, tradițiile stabilite în echipa de dezvoltare vă pot face să vă reconsiderați atitudinea față de anumite lucruri.
Creați un nou arbore de funcții: