Differences
This shows you the differences between two versions of the page.
|
so:teme:folosire-gitlab [2019/02/20 12:12] liza_elena.babu [Folosire Git] |
so:teme:folosire-gitlab [2022/03/11 20:00] (current) ionut.mihalache1506 |
||
|---|---|---|---|
| Line 78: | Line 78: | ||
| - Adăugați URL-ul specific repo-ului de teme de SO ce va conține scheletele de cod pentru fiecare temă și testele: | - Adăugați URL-ul specific repo-ului de teme de SO ce va conține scheletele de cod pentru fiecare temă și testele: | ||
| - click pe ''Import existing repository by URL'' | - click pe ''Import existing repository by URL'' | ||
| - | - adăugați link-ul https://github.com/systems-cs-pub-ro/so-assignments.git | + | - adăugați link-ul https://github.com/systems-cs-pub-ro/so.git |
| + | - în directorul assignments vor fi toate fișierele de care aveți nevoie | ||
| - Click ''Create project''. | - Click ''Create project''. | ||
| - După ce proiectul a fost creat, selectați tab-ul ''Members'' din cadrul acestui proiect (left side) | - După ce proiectul a fost creat, selectați tab-ul ''Members'' din cadrul acestui proiect (left side) | ||
| - | - adăugați următorii useri: Mihai Bărbulescu (3172), Adrian Șendroiu (1701), Răzvan Tudor Crainea, Vladimir Diaconescu, Costin Lupu, Iustin Dumitrescu, Alexandru Jercăianu, George Muraru, Alex Morega, Bogdan Purcăreață (2086) | + | <hidden>- adăugați useri corespunzători: Mihai Bărbulescu (3172), Adrian Șendroiu (1701), Răzvan Tudor Crainea, George Muraru, Adrian-Mirel LUŢAN, Gabriel BERCARU (78505), Ionuț MIHALACHE (87724)</hidden> |
| - | - dați-le dreptul de access ''Reporter'' | + | - adăugați useri corespunzători(cineva din subechipa de teme pe baza username-ului de pe Microsoft Teams) |
| + | - dați-le dreptul de access ''Maintainer'' | ||
| - click pe ''Add users to project'' | - click pe ''Add users to project'' | ||
| Line 97: | Line 99: | ||
| Dacă aveți doar 1-multi în acest repo, pentru a adăuga 2-minishell puteți proceda astfel: | Dacă aveți doar 1-multi în acest repo, pentru a adăuga 2-minishell puteți proceda astfel: | ||
| - | <code> | + | <code bash> |
| - | $ git clone ... | + | git clone ... |
| - | $ cd l3-so-assignments | + | cd l3-so-assignments |
| - | $ mkdir -p 2-minishell/ | + | mkdir -p 2-minishell/ |
| - | $ cd 2-minishell/ | + | cd 2-minishell/ |
| - | $ wget http://ocw.cs.pub.ro/courses/_media/so/teme/2-skel-linux.zip | + | wget http://ocw.cs.pub.ro/courses/_media/so/teme/2-skel-linux.zip |
| - | $ unzip 2-skel-linux.zip | + | unzip 2-skel-linux.zip |
| - | $ rm -fr 2-skel-linux.zip | + | rm -fr 2-skel-linux.zip |
| - | $ wget http://elf.cs.pub.ro/so/res/teme/tema2-checker-lin.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/ | + | unzip tema2-checker-lin.zip # testele sunt dezarhivate în folderul tema2-checker-lin/ |
| - | $ rm -fr tema2-checker-lin.zip | + | rm -fr tema2-checker-lin.zip |
| - | $ mkdir checker-lin | + | mkdir checker-lin |
| - | $ mv tema2-checker-lin/* checker-lin/ | + | mv tema2-checker-lin/* checker-lin/ |
| - | $ rmdir tema2-checker-lin | + | rmdir tema2-checker-lin |
| - | $ cd ../ | + | cd ../ |
| - | $ git add 2-minishell/ | + | git add 2-minishell/ |
| - | $ git commit -m "add Linux skeleton and tests" | + | git commit -m "add Linux skeleton and tests" |
| - | $ git push | + | git push |
| </code> | </code> | ||
| Line 164: | Line 166: | ||
| * http://gitimmersion.com/ | * http://gitimmersion.com/ | ||
| - | <hidden> | + | |
| - | ===== Folosire git ===== | + | ===== Mic tutorial de folosire git ===== |
| 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 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ă. | ||
| Line 173: | Line 175: | ||
| </note> | </note> | ||
| - | Primul pas este să inițializăm un repository local în directorul în care vom păstra toate fișierele din temă. | + | <note tip> |
| + | Dacă vreți să faceți și ceva practic și să învățați //"git by doing"// cea mai bună resursă este http://gitimmersion.com/ | ||
| - | <code> | + | Pentru ce vă trebuie la SO primele 26 de laboratoare sunt cele mai bune. |
| - | $ git init | + | </note> |
| + | |||
| + | |||
| + | === Config === | ||
| + | |||
| + | 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 [[https://git-scm.com/book/en/v2/Getting-Started-First-Time-Git-Setup|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: | ||
| + | |||
| + | <code bash> | ||
| + | student@vagrant:~$ git config --global user.name "Mr. Perfect" | ||
| + | student@vagrant:~$ git config --global user.email mr@perfect.com | ||
| + | </code> | ||
| + | |||
| + | Aceste date pot fi modificate ulterior folosind aceleași comenzi. | ||
| + | |||
| + | === Simple tutorial === | ||
| + | |||
| + | 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ă. | ||
| + | |||
| + | <code bash> | ||
| + | student@vagrant:~$ git init | ||
| </code> | </code> | ||
| 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. | 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. | ||
| - | <code> | + | <code bash> |
| - | $ git remote add origin link_to_online_repo | + | student@vagrant:~$ git remote add origin link_to_online_repo |
| </code> | </code> | ||
| Line 191: | Line 215: | ||
| 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. | 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. | ||
| - | <code> | + | <code bash> |
| - | $ touch .gitignore | + | student@vagrant:~$ touch .gitignore |
| - | + | # evităm adăugarea fișierelor obiect | |
| - | $ echo "*.o" >> .gitignore # evităm adăugarea fișierelor obiect | + | student@vagrant:~$ echo "*.o" >> .gitignore |
| - | + | student@vagrant:~$ git add .gitignore | |
| - | $ git add .gitignore | + | student@vagrant:~$ git commit -m "added .gitignore file to repo" |
| - | + | ||
| - | $ git commit -m "added .gitignore file to repo" | + | |
| </code> | </code> | ||
| Pentru a publica schimbările locale și pe server, folosim comanda ''push''. | Pentru a publica schimbările locale și pe server, folosim comanda ''push''. | ||
| - | <code> | + | <code bash> |
| - | $ git push origin master | + | student@vagrant:~$ git push origin master |
| </code> | </code> | ||
| Line 213: | Line 235: | ||
| Î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: | Î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: | ||
| - | * definirea structurilor necesare rezolvării temei (cel puțin în faza preliminară, putem face modificări asupra lor ulterior) | + | * definirea structurilor necesare rezolvării temei (cel puțin în faza preliminară, putem face modificări asupra lor ulterior) |
| - | * citirea și parsarea datelor de intrare (citirea operațiilor care trebuie efectuate asupra listei, pe rând) | + | * citirea și parsarea datelor de intrare (citirea operațiilor care trebuie efectuate asupra listei, pe rând) |
| - | * rezolvarea primelor 5 teste (toate acoperă diverse cazuri legate de adăugarea unui element în listă: la început, la mijloc, la final) | + | * rezolvarea primelor 5 teste (toate acoperă diverse cazuri legate de adăugarea unui element în listă: la început, la mijloc, la final) |
| - | * rezolvarea următoarelor 5 teste (toate acoperă diverse cazuri în care se șterg elemente din listă: primul element, ultimul element, element după valoare) | + | * rezolvarea următoarelor 5 teste (toate acoperă diverse cazuri în care se șterg elemente din listă: primul element, ultimul element, element după valoare) |
| - | * rezolvarea următoarelor 5 teste (referitoare la sortarea unei liste simplu înlănțuite) | + | * rezolvarea următoarelor 5 teste (referitoare la sortarea unei liste simplu înlănțuite) |
| - | * rezolvarea următoarelor 3 teste (mixte, adăugări, ștergeri, sortări, iar adăugări etc) | + | * rezolvarea următoarelor 3 teste (mixte, adăugări, ștergeri, sortări, iar adăugări etc) |
| - | * rezolvarea următoarelor 2 teste (referitoare la eliberarea corectă a memoriei în momentul ștergerii unuia sau mai multor elemente din listă) | + | * rezolvarea următoarelor 2 teste (referitoare la eliberarea corectă a memoriei în momentul ștergerii unuia sau mai multor elemente din listă) |
| - | * eventuale modificări de coding-style (după nevoie) | + | * eventuale modificări de coding-style (după nevoie) |
| + | |||
| - | <note important> | ||
| Este bine ca după fiecare pas enumerat să salvăm versiunea de cod din mai multe motive: | Este bine ca după fiecare pas enumerat să salvăm versiunea de cod din mai multe motive: | ||
| - | - putem, din neatenție, oboseală sau grabă, să stricăm ce avem până în momentul de față și să ne vină prea greu să revenim la varianta bună de cod | + | - Putem, din neatenție, oboseală sau grabă, să stricăm ce avem până în momentul de față și să ne vină prea greu să revenim la varianta bună de cod |
| - | - organizare mai bună | + | - Organizare mai bună |
| - | - [În cazul lucrului în echipă] se poate vedea cine a făcut o anumită schimbare a codului | + | - **În cazul lucrului în echipă**: se poate vedea cine a făcut o anumită modificare a codului |
| - | </note> | + | |
| - | După fiecare pas trebuie să publicăm schimbările. Vom folosi următoarele comenzi: | + | Așadar, după fiecare pas trebuie să publicăm schimbările. Vom folosi următoarele comenzi: |
| - | <code> | + | <code bash> |
| - | $ git add changed_file1 changed_file2 # toate fișierele modificate | + | # toate fișierele modificate |
| - | $ git commit -m "first 5 tests working" # să zicem că am trecut de primele 5 teste | + | student@vagrant:~$ git add changed_file1 changed_file2 |
| - | $ git push origin master | + | # să zicem că am trecut de primele 5 teste |
| + | student@vagrant:~$ git commit -m "first 5 tests working" | ||
| + | student@vagrant:~$ git push origin master | ||
| </code> | </code> | ||
| - | ===Am greșit, ce fac?=== | + | === Am greșit, ce fac? === |
| 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 | 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 | ||
| - | <code> | + | <code bash> |
| - | $ git log | + | student@vagrant:~$ git log |
| commit ca82a6dff817ec66f44342007202690a93763949 | commit ca82a6dff817ec66f44342007202690a93763949 | ||
| Author: Mr. Perfect <mr@perfect.com> | Author: Mr. Perfect <mr@perfect.com> | ||
| Line 275: | Line 298: | ||
| Pentru a ne întoarce la această variantă folosim comanda: | Pentru a ne întoarce la această variantă folosim comanda: | ||
| - | <code> | + | <code bash> |
| - | $ git revert ca82a6dff817ec66f44342007202690a93763969 | + | student@vagrant:~$ git revert ca82a6dff817ec66f44342007202690a93763969 |
| </code> | </code> | ||
| + | === Git tags === | ||
| + | |||
| + | 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''. | ||
| - | </hidden> | + | 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 [[https://git-scm.com/book/en/v2/Git-Basics-Tagging|aici]]. |
| ===== Resurse ===== | ===== Resurse ===== | ||
| * [[https://docs.joyent.com/jpc/getting-started-with-your-joyent-cloud-account/generating-an-ssh-key/generating-an-ssh-key-manually/manually-generating-your-ssh-key-in-windows|Generare cheie SSH Windows Putty]] | * [[https://docs.joyent.com/jpc/getting-started-with-your-joyent-cloud-account/generating-an-ssh-key/generating-an-ssh-key-manually/manually-generating-your-ssh-key-in-windows|Generare cheie SSH Windows Putty]] | ||
