Atunci când colaborăm cu alte persoane la un același proiect este necesară folosirea unui sistem de versionare a surselor. Acesta ajută pentru a putea colabora la distanță și rezolvă problemele de partajare ale acelorași surse. Chiar și în cazurile în care suntem singurul dezvoltator al unui proiect, versionarea este indicată pentru că:
Câteva exemple de sisteme de versionare sunt:
O scurtă analiză a acestora găsiți Version control systems.
Pentru SO propunem folosirea git
din varii motive:
Așa cum am precizat anterior, Facultatea de Automatică și Calculatoare pune la dispoziție instanța GitLab, accesibilă tuturor studenților și membrilor facultății. Autentificarea se face pe baza contului de pe site-ul de cursuri.
Dashboard-ul
user-ului autentificat.Profile settings
(dreapta-sus)Profile
. Lăsați-le pe cele de pe curs.cs (adresa de e-mail fiind cea de stud.acs.upb.ro
)Design
)
Profile settings
foarte important este adăugarea unei chei SSH.
$ ssh-keygen
Profile settings
, pagina SSH keys
de pe GitLab va trebui să adăugați această cheie astfel:Add key
.Key
Odată autentificați pe GitLab, din Dashboard
în partea stângă apare următorul meniu:
Projects
: aceasta este pagina de gestionare a proiectelor. Aici puteți vedea toate proiectele în care sunteți implicat: fie ca owner, fie ca viewer/guest, fie ca developer.Activity
: care arată activitatea voastră: dacă v-ați alăturat unui nou proiect, dacă ați creat un nou proiect etc.Groups
: gestionarea grupurilor și vizualizarea grupurilor existente.Milestones
: gestionarea pașilor importanți ce țin de proiectele în care sunteți implicat.Issues
: posibile probleme active într-unul din proiectele voastre.Merge Requests
: oferă posibilitatea combinării branch-ului default (master-ului) cu un altul (în cazul rezolvării unui bug sau adăugării unui feature).Snippets
: bucăți de text ce pot fi făcute private sau publice.Help
: documentație GitLab.Pentru crearea unui nou proiect:
New project
(este un +
în dreapta-sus, lângă butonul de Profile settings
). Import existing repository by URL
Create project
.Members
din cadrul acestui proiect (left side)Maintainer
Add users to project
Acum puteți naviga prin fișierele existente în proiect și prin commit-urile din proiect: Files
și Commits
.
Pentru toate temele de la SO se va folosi proiectul l3-so-assignments. Astfel, în acest proiect se vor găsi în final:
Dacă aveți doar 1-multi în acest repo, pentru a adăuga 2-minishell puteți proceda astfel:
git clone ... cd l3-so-assignments mkdir -p 2-minishell/ cd 2-minishell/ wget http://ocw.cs.pub.ro/courses/_media/so/teme/2-skel-linux.zip unzip 2-skel-linux.zip rm -fr 2-skel-linux.zip wget http://elf.cs.pub.ro/so/res/teme/tema2-checker-lin.zip unzip tema2-checker-lin.zip # testele sunt dezarhivate în folderul tema2-checker-lin/ rm -fr tema2-checker-lin.zip mkdir checker-lin mv tema2-checker-lin/* checker-lin/ rmdir tema2-checker-lin cd ../ git add 2-minishell/ git commit -m "add Linux skeleton and tests" git push
Echipa de SO pune la dispozție un script pentru automatizarea etapelor prezentate în secțiunea anterioară. Astfel, un student nu va trebui să-și creeze singur proiectul în GitLab și să realizeze toate acele operații pentru a-și clona repo-ul, ci doar va rula acest script.
Scriptul este disponibil pe GitHub, în repo-ul public dedicat temelor de SO. Îl puteți descărca local folosind comanda:
wget https://raw.githubusercontent.com/systems-cs-pub-ro/so-assignments/master/so-create-repo.sh
Imaginea următoare prezintă pe scurt entitățile gestionate și acțiunile realizate de către script:
La prima rulare, scriptul va crea un repo privat pe GitLab și o clonă în directorul curent al mașinii unde a fost rulat. În acest moment repo-ul privat al studentului și clona de pe mașina sa vor fi copii fidele ale repo-ului public al temelor de SO.
Inițial scriptul va instala pachetele necesare pentru a rula și va realiza autentificarea cu serverul de GitLab, cerând utilizatorului credențialele de pe curs.cs.pub.ro. Următorul pas este să ofere posibilitatea de a încărca pe GitLab o cheie publică pentru SSH; în cazul în care nu există vreuna pe mașina locală, scriptul va genera o pereche de chei RSA. La final, va adăuga asistenții de SO responsabili de teme ca observatori ai proiectului de pe GitLab.
La următoarele rulări scriptul va încerca să sincronizeze clona locală cu repo-ul public. Astfel, dacă echipa de SO face unele modificări în repo-ul public voi vă puteți actualiza clona locală rulănd scriptul.
Mai departe, puteți interacționa cu repo-ul vostru privat prin git: o operație push va trimite modificările voastre în repo-ul de pe GitLab.
Pentru mai multe informații despre script, urmăriți README-ul asociat repo-ului public de pe GitHub.
Acum vă puteți clona local (puteți clona pe mai multe mașini, însă trebuie să aveți cheia privată corespunzătoare cheii publice de pe GitLab) acest repo folosind link-ul pentru SSH. Exemplu:
$ git clone git@gitlab.cs.pub.ro:nume.prenume/l3-so-assignments.git $ cd l3-so-assignments
Puteți adăuga fișiere noi:
$ vim test.c $ git add test.c $ git commit -m "my first C file" $ git push
Câteva tutoriale pentru folosirea Git sunt:
Pentru a înțelege mai ușor cum și mai ales de ce e bine să folosim git
, e cel mai bine să urmărim un exemplu concret. Scenariul propus este de fapt flow-ul de lucru pe care îl urmați la orice temă (nu doar la SO): sunt singur, lucrez la temă, am nevoie de un singur branch și nu vreau să pierd o variantă, să zicem incompletă, dar corectă, de temă.
Pentru ce vă trebuie la SO primele 26 de laboratoare sunt cele mai bune.
Până a ajunge la discuția despre cum să folosim git-ul corect, este bine să aducem în discuție o modalitate prin care putem configura git-ul local. Git-ul vine cu o opțiune numită git config
care ne permite să setăm câteva variabile care controlează modul în care git funcționează. Aceste variabile pot stocate în diverse fișiere pe sistemul nostru, însă ce ne interesează în acest moment este fișierul ~/.gitconfig
deoarece aici sunt păstrate date pentru utilizatorul curent autentificat în sistem (~
) care vor fi văzute de-a lungul tuturor repo-urilor ale acestuia. Mai multe detalii se pot afla aici.
Este important să setăm numele și email-ul nostru în git deoarece fiecare commit va conține aceste informații. Pentru a face acest lucru urmărim următorii pași:
student@vagrant:~$ git config --global user.name "Mr. Perfect" student@vagrant:~$ git config --global user.email mr@perfect.com
Aceste date pot fi modificate ulterior folosind aceleași comenzi.
Acum că avem numele și email-ul setate, putem trece mai departe. Primul pas în lucrul cu git este să inițializăm un repository local în directorul în care vom păstra toate fișierele din temă.
student@vagrant:~$ git init
Vrem să asociem repository-ul nostru local cu unul pe server. Fie că folosim Gitlab, Github, Bitbucket sau orice altă variantă, pașii de urmat sunt neschimbați. Repository-ul precizat trebuie să existe de dinainte.
student@vagrant:~$ git remote add origin link_to_online_repo
Pe git se vor ține doar fișierele sursă, niciodată cele obiect sau executabile, deoarece acestea pot fi generate de fiecare dată când avem nevoie, pe ce mașină avem nevoie foarte simplu dacă avem un fișier Makefile
cu reguli corespunzătoare.
Pentru a fi siguri că nu adăugăm din greșeală fișiere inutil în istoric, e necesar să avem în acest director un fisier .gitignore
pe care îl adăugăm. În acest fișier se scriu reguli, una pe rând, sub formă de expresii regulate, în care precizăm ce fișiere nu vrem să fie adăugate în acest repo.
După ce am terminat de editat fișierul, îl adăugăm în repository folosind comanda add
. E util ca fiecare schimbare pe care o comitem să fie asociată cu un mesaj scurt și la obiect pentru a ști ulterior exact ce schimbare a fost produsă cu acel commit.
student@vagrant:~$ touch .gitignore # evităm adăugarea fișierelor obiect student@vagrant:~$ echo "*.o" >> .gitignore student@vagrant:~$ git add .gitignore student@vagrant:~$ git commit -m "added .gitignore file to repo"
Pentru a publica schimbările locale și pe server, folosim comanda push
.
student@vagrant:~$ git push origin master
În momentul în care ne apucăm de temă, ne vom gândi întotdeauna care sunt milestone-urile pe care le atingem pe parcursul ei. Spre exemplu, putem împărți o tema noastră în următoarele etape:
Este bine ca după fiecare pas enumerat să salvăm versiunea de cod din mai multe motive:
Așadar, după fiecare pas trebuie să publicăm schimbările. Vom folosi următoarele comenzi:
# toate fișierele modificate student@vagrant:~$ git add changed_file1 changed_file2 # să zicem că am trecut de primele 5 teste student@vagrant:~$ git commit -m "first 5 tests working" student@vagrant:~$ git push origin master
Am continuat cu rezolvarea temei și mi-am dat seama că ceva nu e în regulă și aș vrea să revin la o versiunea în care mergeau doar primele 5 teste. Vom folosim mai întâi comanda git log
student@vagrant:~$ git log commit ca82a6dff817ec66f44342007202690a93763949 Author: Mr. Perfect <mr@perfect.com> Date: Tue Feb 19 16:52:11 2019 -3000 first 10 tests working commit ca82a6dff817ec66f44342007202690a93763969 Author: Mr. Perfect <mr@perfect.com> Date: Mon Feb 18 23:52:11 2019 -3000 first 5 tests working commit ca82a6dff817ec66f44342007202690a93763959 Author: Mr. Perfect <mr@perfect.com> Date: Mon Feb 18 22:52:11 2019 -3000 parsed input commit ca82a6dff817ec66f44342007202690a93763949 Author: Mr. Perfect <mr@perfect.com> Date: Mon Feb 18 21:52:11 2019 -3000 added .gitignore file
ca82a6dff817ec66f44342007202690a93763969
Pentru a ne întoarce la această variantă folosim comanda:
student@vagrant:~$ git revert ca82a6dff817ec66f44342007202690a93763969
Principalul motiv pentru care folosim git este să versionăm codul pe care îl scriem. Așa cum am precizat mai sus, atunci când lucrăm în echipă, este de preferat ca fiecare membru să lucreze pe un branch, iar ulterior codul să fie unificat prin operația de merge
.
Până acum am vorbit de commit
ca fiind modul prin care diferențiem o versiune de cod de alta. Acest lucru este de regulă folosit în contextul unui branch. Pentru un întreg repository folosim tags
pentru a versiona codul. Pentru mai multe detalii în ceea ce privește tag-urile folosite în lumea git, tipuri de tag-uri și modul în care pot fi create și gestionate, consultați pagina de aici aici.