Ce este GIT-ul?
In procesul de dezvoltare a unui produs software sunt angrenati de obicei mai multi programatori, pentru a fi mai usoara partea de asamblare a codului sursa, se foloseste GIT. Acesta este un version control foarte efficient si utilizat la scara larga in industria IT. Cu ajutorul comenzilor din consola (linia de comanda) sau a unor aplicatii dedicate pentru managementul repository-urilor (care au la baza tot comenzile GIT), un programator poate sa preia codul scris de altii, sa-si creeze propriul branch (o ramura pe care se regaseste o copie a codului deja existent), sa adauge cod scris intr-un branch, sa comita codul scris si multe alte comenzi. Un repository este un deposit unde sunt tinute toate branch-urile codului sursa. Acesta poate fi local sau urcat pe una din multiplele platforme care sustin repository-uri, precum: Bitbucket, GitHub, GitLab, etc.
Invata GIT
Cand vine vorba de GIT, sunt doua tipuri de programatori:
- cei care prefera sa utilizeze linia de comanda, ruland efectiv comenzile intr-o consola pentru a manipula repository-ul in care lucreaza, aceasta varianta fiind una mai putin vizuala, dar e de multe ori mult mai eficienta si lipsita de posibile erori. In general se poate utiliza orice consola, cum ar fi CMD, PowerShell sau Terminal, dar exista si Git Bash, dedicat comenzilor GIT si foarte eficient. Mare parte din IDE-uri (precum Microsoft Visual Studio sau produsele JetBrains) au integrat deja consolele pentru a fi mai accesibile.
- cei care prefera o metoda mai vizuala si elaboratea a situatiei din punct de vedere al codului, alegand una din multele aplicatii dedicate managementului repository-urilor precum Sourcetree, GitKraken, GitFork, etc. Aceste aplicatii prezinta cu exactitate modificarile aduse anumitor fisiere, afisand inclusiv versiunea veche pentru a putea fi verificate inca o data modificarile aduse codului, detecteaza adaugarea sau stergerea unor fisiere si trimit notificari in diverse moduri pentru a informa programatorul cu privire la modificarile dintr-un branch, aduse de catre colegii lui. Unele IDE-uri au propria lor varianta vizuala prin care poti avea un overview asupra repository-urilor, un exemplu ar fi produsele celor de la JetBrains (IntelliJ, WebStorm, PyCharm, etc).
In general structurile de dezvoltare din punct de vedere al repository-urilor difera in functie de echipa, cerinte, necesitati, etc. Cel mai frecvent se utilizeaza branch-ul numit master pentru aplicatia propriuzisa, cea care deja este lansata, branch-ul numit develop este branch-ul principal pe care se implementeaza proiectul, iar de la develop pleaca branch-urile fiecarui programator, in functie de necesitati. Un flow de lucru pentru un task nou ar fi: se creaza un branch nou din develop, se implementeaza pe el, este verificat printr-un pull request de catre colegi, iar daca totul e in regula, acesta este merge-uit in develop, ulterior branch-ul poate fi sters.
Sa consideram ca Mike este .NET developer si trebuie sa implenteze o funtionalitate noua in aplicatia pe care o dezvolta impreuna cu alti 3 programatori. Acesta a lipsit cu o zi inainte de la birou, iar colegii lui au adaugat in branch-ul principal (develop) mai multe commit-uri. Mike prefera sa foloseasca Sourcetree (iar pentru anumite comenzi Git Bash), selectand ca branch de lucru branch-ul develop, acesta observa ca, colegii lui au adaugat cu o zi inainte 7 commit-uri, pentru a fi sigur ca nu mai sunt si alte commit-uri noi pe care el nu le vede, acesta apasa pe Fetch (buton care ruleaza comanda git fetch), cu ajutorul careia poate vedea numarul de modificari existente la momentul respectiv. Ulterior butonul Pull (care ruleaza cumanda git pull), aducand local toate commit-urile colegilor si astfel avand ultima versiune posibila a branch-ului develop. Acesta creaza un branch nou, plecand de la develop, implementeza noua functionalitate, ulterior in Sourcetree (care a detectat intre timp modificarile), comite modificarile local, scriind un mesaj scurt despre ce a implementat. Urmatorul pas este apasarea butonului de Push (care executa git push), urcand practic branch-ul creat de el in cloud, de unde si colegii lui il pot accesa daca vor. Ca, codul scris de Mike sa ajunga in develop, acesta va trebuii sa creeze un Pull Request, proces in care colegii lui Mike verifica tot codul scris de acesta si eventual lasa comentarii, daca sunt greseli sau unele sintaxe se pot simplifica, imbunatatii, etc. Colegii lui Mike au aprobat pull request-ul, deoarece codul scris de acesta e bine scris, ulterior codul a fost merge-uit in branch-ul develop de catre platforma utilizata de acestia, iar branch-ul creat anterior de Mike nu mai este util si acesta o sa-l stearga cu ajutorul Sourcetree. Cam asa arata un flow normal de lucru cu GIT.
Majoritatea programatorilor utilizeaza intr-o forma sau alta GIT, deoarece le usureaza foarte mult munca si procesul propriuzis de dezvoltare software. In combinatie cu pipeline-uri, GIT usureaza inclusiv procesul de deploy al unui produs software nou. Unii utilizeaza o alta metoda de lucru bazata pe git rebase, dar procesul este cel putin la fel de complex precum varianta git merge (exemplificata mai sus) si poate face ea insasi subiectul unui articol.
