O introducere în Controlul versiunilor și Git

Sunteți familiarizat cu Google Docs? Ei bine, dacă sunteți, este sigur să presupuneți că sunteți la curent cu mica filă „Istoricul versiunilor”, care permite scriitorilor și persoanelor implicate să verifice și să țină evidența tuturor modificărilor făcute în document. în orice moment dat. Un instrument la îndemână, nu-i așa?

Acum imaginați-vă că în loc de o foaie plină de paragrafe, există fișiere pline cu sute de rânduri de coduri. Și, spre deosebire de un singur document, există tone de fișiere diferite, actualizate constant.

Într-un scenariu ca acesta, în care există mii de rânduri de coduri în joc și rezultatul final, adică aplicația mobilă este ceea ce depinde viitorul unei afaceri, devine și mai important să existe un software care să țină o filă a tuturor modificărilor. realizate în fișierele de cod.

Aici intervine un software de control al versiunilor.

De ce este important controlul versiunilor în dezvoltarea de software

După cum sugerează și numele, un software de control al versiunilor le permite dezvoltatorilor de aplicații mobile să urmărească diferitele versiuni ale ciclului de dezvoltare a software-ului și să le modifice. Această capacitate de a urmări toate modificările care au loc în cod și apoi opțiunea de a anula modificările este ceea ce face din Controlul versiunilor o parte importantă a procesului unei companii de dezvoltare a aplicațiilor mobile, care implică mai mulți dezvoltatori.

Acum, când vine vorba de Controlul versiunilor, există o serie de software disponibile pe piață în prezent. Să ne uităm la unele dintre ele -

Software disponibil pentru controlul versiunilor

Deși în Sondajul său GitLab, liderul software-ului distribuit a constatat că 98% dintre utilizatori folosesc instrumentele open source Git și peste 92% dintre dezvoltatori folosesc Git ca limbaj de control al versiunilor în procesul de dezvoltare a aplicațiilor, există o serie de de motive pentru care dezvoltatorii ar putea privi alternativa Git. Unele dintre aceste motive pot varia de la – structura prețurilor GitHub și faptul că Github este lansat atât pe iOS, cât și pe Android, o aversiune față de Octocat sau un simplu nivel de confort cu limbajul de control al versiunilor care nu este Git.

Oricare ar fi motivul tău, iată alternativele Git pentru controlul versiunilor -

Acum, chiar și atunci când există o serie de alternative disponibile pentru Controlul versiunii și la Appinventiv, avem o experiență de primă mână în lucrul cu multe dintre ele, din cauza cerințelor variate ale clienților, suntem într-adevăr parțiali față de Git. Lasă-mă să-ți spun de ce.

De ce Appinventiv folosește Git pentru controlul versiunilor

1. Pentru viteza fulgerului

Dintre toate software-urile de control al versiunilor de pe piață, viteza cu care funcționează elementele Git log și Commit este inegalabilă cu oricare alta. Și atunci când echipa ta de dezvoltatori lucrează pe o platformă, devine absolut necesar ca software-ul să fie rapid.

2. Pentru abilitatea de a lucra offline

Când lucrați la un software care se bazează pe internet, poate fi riscant atunci când sunteți în mișcare și pierdeți conexiunea cu depozitul central. Dar, acesta nu este cazul cu Git. Cu Git, puteți face aproape toate sarcinile pe mașina dvs. locală - comite, răsfoiți istoricul proiectului, creați ramuri sau îmbinați.

3. Pentru Relieful Undo

Git vine cu o comandă „undo” care vă permite să corectați și să anulați întreaga comitere. De fapt, vă oferă chiar și opțiunea de a restabili comiterea „ștersă” prin opțiunea Reflog.

4. Pentru Backup

Când echipa lucrează pe Git, fiecare clonă pe care echipa o are pe mașina lor vine cu o copie de rezervă utilizabilă. În plus, aproape fiecare acțiune Git adaugă doar datele și nu le șterge.

5. Pentru realizarea de comisioane utile

Când echipa noastră de dezvoltatori efectuează un set de modificări fără legătură – luând unele funcții de la A, remediați unele erori în alta – poate fi foarte dificil pentru ceilalți membri ai echipei să înțeleagă ceea ce s-a întâmplat și poate fi dificil pentru ei să revină. Caracteristicile lui A dacă cauzează probleme.

Git rezolvă această mizerie prin crearea unui commit granual. Prin conceptul său de „zonă de pregătire”, se poate afla cu ușurință ce modificări ar fi incluse în următorul commit, chiar și atunci când sunteți dispus să vă uitați la linii individuale.

Deci, acestea au fost cele cinci motive principale pentru care folosim Git aici la Appinventiv. Acum că ne-am uitat la de ce, este timpul să ne uităm la Cum. Cum încorporăm Git în procesul nostru de control al versiunilor.

Să ajungem la asta acum.

Procesul de control al versiunilor atunci când se utilizează Git

Crearea depozitului

Scopul Git este de a gestiona un set de fișiere, numit Project. Pentru a face acest lucru, Git salvează toate informațiile în structura de date cunoscută sub numele de Repository. Un depozit este format din codurile sursă ale aplicației, resurse și seturi de date. Practic, are tot ceea ce definește proiectul aplicației.

Acum, există două moduri de a obține un depozit pe Git. Puteți fie să utilizați un director local și să îl convertiți într-un depozit Git folosind linia de comandă, fie să copiați un depozit Git deja încărcat în al dvs.

Când creați un depozit, de obicei aveți două opțiuni - Public și Private. Depozitul public este cel care poate fi vizualizat de alți dezvoltatori folosind Git, iar cel privat, pe de altă parte, este unul care poate fi vizualizat doar de câteva persoane.

Ramificare

Lângă Crearea depozitului este Branching. Într-o companie precum Appinventiv, în care la un moment dat peste 15 – 20 de dezvoltatori lucrează la un singur proiect, nu este neobișnuit ca dezvoltatorii să partajeze același cod sursă și să lucreze la el. Ceea ce se întâmplă este că, deoarece unii dezvoltatori sunt ocupați să rezolve probleme, alții ar putea implementa unele funcții.

Într-o situație ca aceasta, avem nevoie de un sistem care să faciliteze gestionarea diferitelor versiuni de cod în aceeași bază de cod.

Aici intervine Gitflow. Gitflow este un cadru folosit pentru ramificarea sistematică și eficientă.

Înainte de a continua cu modul în care funcționează procesul de Branching pe Gitflow, permiteți-mi să explic conceptul cu un exemplu.

Să presupunem că există 5 dezvoltatori în echipa ta și lucrează la dezvoltarea unei aplicații similare Instagram. Acum, funcțiile individuale ale aplicației, cum ar fi să presupunem că Feed și Notificările sunt desemnate ca Modul 1, Modul 2 și așa mai departe și așa mai departe. Acum aceste module diferite sunt ramuri de dezvoltare, care, după ce au fost lucrate, sunt îmbinate cu ramura părinte sau Master.

În momentul în care un dezvoltator adaugă o ramură, ei creează o linie de dezvoltare independentă, care izolează munca lor de cea a membrilor echipei. Diferitele ramuri sunt apoi fuzionate în ramura părinte.

Branching-ul este metoda care le permite membrilor echipei să identifice toate schimbările la care ar trebui să se aștepte și este ceea ce face ușoară întoarcerea.

În proiectele noastre, de obicei păstrăm aceste sucursale –

• Filiala Master
• Filiala Dezvoltare
• Ramura de caracteristici
• Ramura Eliberare
• Remedieri rapide și remedieri de erori

Angajează-te

Modificările pe care le face un dezvoltator în fișierul individual sunt cunoscute ca Commit. Modificările sau commit-ul sunt adăugate în depozitul local și nu în server. În continuare, dezvoltatorii noștri urmează obiceiul de a scrie un mesaj de commit, în care sunt postate descrierea commit-ului (modificările făcute în fișier), astfel încât alți dezvoltatori să cunoască și detaliile modificărilor făcute în fișier.

Apăsați

Când comiteți în depozitul local Git, ceea ce se întâmplă în continuare este că modificările sunt apoi trimise la server, care este cunoscut sub numele de Push .

Este destul de ușor să împingeți istoricul de comitere pe server atunci când sunteți singurul care lucrează la un fișier, dar în cazul în care există și alți dezvoltatori implicați în proces, va trebui să extrageți modificările înainte de a vă putea împinge setul de se angajează în Git.

În continuare, vom analiza ce se face în pasul Pull Change.

Cerere de tragere

Când mai mulți dezvoltatori lucrează la același fișier, ceea ce se întâmplă este că unele comite ar putea fi împinse pe server de către celălalt dezvoltator înainte de a le împinge. Și când se întâmplă asta, apare conflictul (mai multe despre asta mai târziu).

Pentru a evita încărcarea aceleiași baze de cod de două ori pe server, dezvoltatorii scot mai întâi modificările din depozit și se asigură că codurile sunt diferite. Acum, în general, când doi sau mai mulți dezvoltatori lucrează la același fișier și își împing commit-ul pe server, apare opțiunea „Merge”.

Să vorbim în continuare despre Merge.

Combina

Merge este pasul în care dezvoltatorii clubează toate ramurile mai întâi între ele și apoi cu ramura principală sau părinte.

De fiecare dată când o livrare introduce o comandă Push, ei primesc o opțiune Merge, care apoi le întreabă ramura cu care ar dori să îmbine commit-ul.

Acum, în etapa de fuziune, apariția conflictului este foarte frecventă. Conflictul apare de obicei atunci când cele două ramuri pe care intenționați să le îmbinați au fost modificate în aceeași parte din același fișier. Ce se întâmplă aici este că Git nu își poate da seama ce versiune ar trebui utilizată.

Când apare această problemă de conflict, Git oferă două soluții – automată și manuală.

După cum spune și numele, unul este locul în care Git află problema în sine, iar în cel din urmă, dezvoltatorii trebuie să o facă manual. La Appinventiv, ne concentrăm pe rezolvarea manuală a conflictelor, deoarece elimină chiar și șansele minime de apariție a erorilor.

În timp ce folosim Git pentru a controla versiunea procesului nostru de dezvoltare a aplicației, ceea ce se întâmplă simultan este Urmărirea problemelor.

Deoarece suntem un mare adept al Agile și avem încredere în Agile pentru procesul nostru de dezvoltare a aplicațiilor mobile , înțelegem importanța gestionării mai multor procese de dezvoltare în același timp. Și cu funcția de urmărire a problemelor, devine mult mai ușor pentru testeri să urmărească în timp real codul scris și introdus pe serverul Git.

Folosim placa ZenHub pentru a monitoriza fluxul de lucru din fiecare depozit. Tabloul ne permite să ținem evidența priorității modificării sugerate și, de asemenea, să îi ajutăm pe dezvoltatori să-și actualizeze comentariile pe tablă în timp real.