PC Laborator 2.1 (opțional): Diferență între versiuni

De la WikiLabs
(Pregătirea unui nou commit - staged files)
(Adăugarea de fișiere în repository - commit)
Linia 74: Linia 74:
  
 
[[Fișier:git_commit_stack.svg]]
 
[[Fișier:git_commit_stack.svg]]
 +
 +
Un fișier modificat dar care nu este pregătit pentru ''commit'', poate fi readus în stadiul din HEAD prin comanda <code style="color: green">git checkout ''fișier''</code>
  
 
=== Revenire la versiuni anterioare - '''detached state''' ===
 
=== Revenire la versiuni anterioare - '''detached state''' ===

Versiunea de la data 28 septembrie 2015 21:13

Obiective

  • definirea noțiunii de Version Control System;
  • utilizarea unui sistem de Version Control: Git.

Sisteme de control al versiunii

Gândiți-vă la următorul scenariu: lucrați la un proiect într-un limbaj de programare sau de descriere hardware; acest proiect este mare și nu poate fi terminat într-o zi, prin urmare vă faceți timp și lucrați cate o oră în fiecare zi. Apar următoarele situații:

  • peste două săptămâni vă dați seama că unele lucruri pe care le-ați adăugat în program nu sunt necesare, deci ați vrea să vă întoarceți la o versiune mai veche - este nevoie de un sistem care să țină o istorie a modificărilor și să permită oricând întoarcerea la o versiune anterioară;
  • proiectul e pe echipe, deci la el lucrează trei persoane; fiecare editează unul sau mai multe fișiere, fiind posibil ca doi membri ai echipei să editeze același fișier - e nevoie de un sistem care să poată să centralizeze modificările și să trateze situația în care același fișier e modificat de doi ingineri;
  • unul din membrii echipei găsește o problemă și dorește să vadă cine și ce a modificat în zona respectivă de cod și care a fost scopul modificării - este deci nevoie de un sistem care să permită documentarea fiecărei modificări pe perioada dezvoltării proiectului și vizualizarea acestor modificări;
  • după documentare, teser-ul dorește să poată nota problema, atribuid-o unui membru al echipei pentru rezolvare - este nevoie de un sistem care să permită înregistrarea și documentarea erorilor în scopul rezolvării;

Toate aceste cerințe sunt adresate de sistemele de control al versiunii, acestea pot:

  • ține evidența modificărilor și permite întoarcerea la o versiune mai veche;
  • permite ramificarea dezvoltării în mai multe direcții și unificarea ulterioară a acestor ramuri;
  • sincroniza modificările fiecărui utilizator cu un depozit central pentru a putea fi accesate de ceilalți membri ai proiectului;

Există mai multe sisteme de control al versiunii:

  • Pe model client - server:
    • Concurrent Versions System (CVS) - open Source
    • Subversion (SVN) - open source
    • Perforce – nu este open source, dar poate fi folosit gratis în proiecte open-source
  • Pe model distribuit:
    • Git - creat de Linus Torvalds pentru dezvoltarea kernel-ului de Linux - open source
    • BitKeeper – folosit pentru dezvoltarea kernel-ului de Linux între 2002 și aprilie 2005.

În continuare vom prezenta conceptele cele mai importante și funcționarea sistemului Git.

Git

Git este un sistem de control de versiune distribuit. Asta înseamnă că poate fi folosit de către un utilizator fără a fi conectat la un depozit central, copia locală de pe calculatorul utilizatorului ținând în baza ei de date toate informațiile legate de conținutul curent și de modificările anterioare.

 Odată instalat Git, fiecare utilizator trebuie să-și configureze adresa de e-mail și numele:
  git config --global user.name "Ion Vasile"
  git config --global user.email ion.vasile@gmail.com

Git - repository local

Fiecare proiect este stocat în Git într-un "depozit" numit repository.

Un repository se crează cu comanda git init.

Odată un repository creat, se pot adăuga apoi șterge sau modifica fișiere. Aceste modificări se adaugă în repository prin operații specifice inițiate de utilizator, numite commit.

Starea curentă a repository-ului se poate vedea în orice moment cu comanda git status.

Pregătirea unui nou commit - staged files

Un nou commit se pregătește selectând fișierele dorite și punându-le într-o stare numită "staged for commit" adică pregătite pentru commit. Fișierele care pot fi pregătite pentru commit sunt:

  • fișiere noi, care vor fi adăugate în repository - prin comanda git add fișier;
  • fișiere existente în repository, dar care au fost modificate - prin comanda git add fișier;
  • fișiere existente care se vor șterge din repository - prin comanda git rm fișier;
  • fișiere care există în repository, sunt nemodificate dar iși schimbă locația - prin comanda git mv fișier_sursă fișier_destinație;

Mai multe fișiere pot fi pregătite pentru un commit, apoi toate odată se actualizează într-un singur commit.

Un fișier pregătit pentru commit se poate șterge din lista de fișiere pregătite, păstrând modificările, cu comanda git reset fișier

Adăugarea de fișiere în repository - commit

Fiecare nou commit, care poate conține modificări pentru unul sau mai multe fișiere, se adaugă întotdeauna peste ultimul commit, și conține informații despre:

  • utilizatorul care făcut modificările;
  • data și ora când s-au realizat modificările respective;
  • mesajul adăugat de utilizator în momentul commit-ului;
  • un număr de identificare, generat din celelalte informații;
  • modificările efective.
Un commit nou se realizează cu comanda git commit -m "mesaj".

Ultimul commit se numește HEAD. Orice nou commit se poate pune doar peste HEAD-ul curent și va deveni noul HEAD.

Git commit stack.svg

Un fișier modificat dar care nu este pregătit pentru commit, poate fi readus în stadiul din HEAD prin comanda git checkout fișier

Revenire la versiuni anterioare - detached state

Lista commit-urilor existente se poate inspecta folosind comanda git log.

Dacă se dorește revenirea la un commit anterior, acest lucru se poate face în două feluri, specificând ID-ul commit-ului la care se dorește revenirea:

  • revenire fără pierderea commit-urilor ulterioare; în acest caz, starea devine detached și se creează automat o ramură nouă de dezvoltare (branch) - prin comanda git checkout commit_id
  • revenire cu pierderea commit-urilor ulterioare dar fără pierderea modificarilor fișierelor; în acest caz, commit-ul la care se revine devine HEAD - prin comanda git reset commit_id
  • revenire cu pierderea commit-urilor ulterioare și a modificărilor fișierelor; și în acest caz, commit-ul la care se revine devine HEAD - - prin comanda git reset --hard commit_id

În detached state nu se șterge nimic din repository, iar commit-urile noi se adaugă branch-ului nou creat temporar. Pentru a reveni din detached state, trebuie revenit la ramura principală de dezvoltare.

Revenire fără pierdere de commit-uri - detached state
Revenire cu pierdere de commit-uri

Comenzi și exemple

  • Prima oară după instalarea Git, trebuie configurat numele și adresa de e-mail a utilizatorului:
  student@pracsis01 ~ $ git config --global user.name "Ion Vasile"
  student@pracsis01 ~ $ git config --global user.email ion.vasile@gmail.com
  • Creați un director numit gitroot în directorul personal al userului student.
  • În directorul gitroot creați un alt director numit pc_lab.
Un repository nou este inițializat cu comanda git init.
  • În directorul ~/gitroot/pc_lab inițializați un repository Git:
  student@pracsis01 ~/gitroot/pc_lab $ git init
  Initialized empty Git repository in /home/student/gitroot/pc_lab/.git/
  • În directorul ~/gitroot/pc_lab creați un fișier text numit README.md care să conțină:
Acesta este primul meu repository Git
=====================================
Un fișier nou sau modificat se pregătește pentru commit cu comanda git add.
  • Pregătiți fișierul pentru commit:
  student@pracsis01 ~/gitroot/pc_lab $ git add README.md
  student@pracsis01 ~/gitroot/pc_lab $ 
Pentru a vedea starea curentă a repository-ului, se folosește comanda git status.
  • Vizualizați starea curentă a repository-ului:
  student@pracsis01 ~/gitroot/pc_lab $ git status
   On branch master
   
   Initial commit
   
   Changes to be committed:
     (use "git rm --cached <file>..." to unstage)
   
           new file:   README.md
Un commit nou se realizează cu comanda git commit.
  • Realizați primul commit:
  student@pracsis01 ~/gitroot/pc_lab $ git commit -m "Primul commit - fisierul README.md"
  [master (root-commit) 75f2cfb] Primul commit - fisierul README.md
   1 file changed, 0 insertions(+), 0 deletions(-)
   create mode 100644 README.md
  • Vizualizați din nou starea curentă a repository-ului.
Lista commit-urilor dintr-un repository se poate vizualiza cu comandagit log.
  • Vizualizați lista ultimelor commit-uri.
  student@pracsis01 ~/gitroot/pc_lab $ git log
  ...
  • Creați in directorul ~/gitroot/pc_lab un director numit lab2. În acest director creați un fișier cod sursă C care să afișeze pe ecran textul "Hello Git!". Creați și un Makefile care să compileze sursa C și să genereze un executabil.
  • Pregătiți cele două fișiere pentru commit.
  • Realizați al doilea commit cu mesajul "Am adaugat fisierele sursa pentru laboratorul 2.".
  • Vizualizați lista ultimelor commit-uri.
Întoarcerea la un commit anterior, în mod soft, se face cu comandagit checkout <ID>.
  • Identificați ID-ul primului commit. Întoarceți-vă la starea de după primul commit (atenție, ID-ul de mai jos este doar un exemplu):
  student@pracsis01 ~/gitroot/pc_lab $ git checkout 75f2cfb
  • Vizualizați conținutul directorului curent.
  • Vizualizați starea curentă a repository-ului.
  • Vizualizați branch-ul curent.
  • Creați un fișier text nou numit test.txt.

Git Remote

Platforma Gitlab

Exerciții