PC Laborator 2.1 (opțional) - Revizia istoricului

Rhobincu: /* Ramuri de dezvoltare - branch */

2017-10-29T21:08:42Z

Ramuri de dezvoltare - branch

Rhobincu: /* Pregătirea unui nou commit - staged files */

2017-10-29T21:04:43Z

Pregătirea unui nou commit - staged files

Rhobincu: Radu Hobincu a redenumit pagina PC Laborator 2 în PC Laborator 2.1 (opțional) fără a lăsa o redirecționare în loc

2017-09-25T11:22:30Z

Radu Hobincu a redenumit pagina PC Laborator 2 în PC Laborator 2.1 (opțional) fără a lăsa o redirecționare în loc

Rhobincu: /* Exerciții */

2015-10-12T14:59:45Z

Exerciții

Rhobincu: /* Exemple */

2015-10-12T14:59:24Z

Exemple

Rhobincu: /* Merges și rezolvarea conflictelor */

2015-10-08T18:12:27Z

Merges și rezolvarea conflictelor

Rhobincu: /* Revenire la versiuni anterioare - detached state */

2015-10-08T18:09:51Z

Revenire la versiuni anterioare - detached state

Rhobincu: /* Revenire la versiuni anterioare - detached state */

2015-10-08T18:09:23Z

Revenire la versiuni anterioare - detached state

Rhobincu: /* Sisteme de control al versiunii */

2015-10-08T18:06:48Z

Sisteme de control al versiunii

Rhobincu: /* Sisteme de control al versiunii */

2015-10-08T18:06:36Z

Sisteme de control al versiunii

@@ Linia 94: / Linia 94: @@
 === Ramuri de dezvoltare - ''branch'' ===
-Ramurile de dezvoltare (branches) sunt o componentă foarte importantă a sistemelor de control al versiunii care permit dezvoltarea simultană a mai multor funcționalități sau componente pentru același sistem, precum si posibilitatea de a avea în lucru mai multe versiuni ale aceleiași aplicații. Ideea de '''branch''' este aceea că dintr-un anumit punct al dezvoltării produsului (adică de la un '''commit'''), stiva de ''commit''-uri se poate ramifica și apoi direcțiile de dezvoltare vor diverge:
+Ramurile de dezvoltare (branches) sunt o componentă foarte importantă a sistemelor de control al versiunii care permit dezvoltarea simultană a mai multor ''feature''-uri sau componente pentru același sistem, precum și posibilitatea de a avea în lucru mai multe versiuni ale aceleiași aplicații. Ideea de '''branch''' este aceea că dintr-un anumit punct al dezvoltării programului (adică de la un '''commit'''), stiva de ''commit''-uri se poate ramifica și apoi direcțiile de dezvoltare vor diverge:
 [[Fișier:branches.svg|none|frame|Schema bloc a unui ''repository'' cu două ''branch''-uri]]

@@ Linia 54: / Linia 54: @@
 * fișiere existente în repository, dar care au fost modificate - prin comanda <code style="color: green">git add ''fișier''</code>;
 * fișiere existente care se vor șterge din repository - prin comanda <code style="color: green">git rm ''fișier''</code>;
-* fișiere care există în repository, sunt nemodificate dar iși schimbă locația - prin comanda <code style="color: green">git mv ''fișier_sursă'' ''fișier_destinație''</code>;
+* fișiere care există în repository, dar iși schimbă locația - prin comanda <code style="color: green">git mv ''fișier_sursă'' ''fișier_destinație''</code>;
 Mai multe fișiere pot fi pregătite pentru un ''commit'', apoi toate odată se actualizează într-un singur ''commit''.

← Versiunea anterioară		Versiunea de la data 12 octombrie 2015 14:59
Linia 245:		Linia 245:
	* Listați '''commit'''-urile din ''branch''-ul curent.		* Listați '''commit'''-urile din ''branch''-ul curent.
	* Observați aceleași modificări și în interfața web a platformei Gitlab.		* Observați aceleași modificări și în interfața web a platformei Gitlab.
−
−	~~= Exerciții =~~

@@ Linia 240: / Linia 240: @@
 * Adăugați o modificare unuia din fișierele din <code style="color: blue">pc_lab_temp</code> sau adăugați un fișier nou.
 * Pregătiți fișierul și apoi realizați ''commit''-ul.
-* Sincronizați ''repository''-ul cu '''origin''':
+* Sincronizați ''repository''-ul cu '''origin''', branch-ul '''master''':
-  '''<span style="color: green">student@pracsis01</span> <span style="color: blue">~/gitroot/pc_lab_temp $</span> git push origin'''
+  '''<span style="color: green">student@pracsis01</span> <span style="color: blue">~/gitroot/pc_lab_temp $</span> git push origin master'''
 * Reveniți în ''repository''-ul personal și sincronizați-l aducând modificările din '''origin'''.
 * Listați '''commit'''-urile din ''branch''-ul curent.

@@ Linia 123: / Linia 123: @@
 </syntaxhighlight>
-Dacă modificările de pe branch-ul componentei sunt complet disjuncte față de modificările de pe branch-ul sistemului, atunci operația de ''merge'' se poate face automat. Dacă în schimb aceleași fișiere au fost modificate pe aceleași linii, atunci fișierele respective se marchează ca fiind în conflict, operația de ''merge'' se oprește, iar utilizatorul trebuie să rezolve conflictele editând fișierele cu probleme, în care va găsi marcate variantele din cele două branch-uri. După ce fișierele sunt salvate cu modificările dorite, acestea trebuie pregătite pentru ''commit'', iar apoi trebuie realizat ''commit''-ul care va aduce modificările pe branch-ul sistemului.
+Dacă modificările de pe branch-ul componentei sunt complet disjuncte față de modificările de pe branch-ul sistemului, atunci operația de ''merge'' se poate face automat. Dacă în schimb aceleași fișiere au fost modificate pe aceleași linii, atunci fișierele respective se marchează ca fiind în conflict, operația de ''merge'' se oprește, iar utilizatorul trebuie să rezolve conflictele editând fișierele cu probleme, în care va găsi marcate variantele din cele două branch-uri. După ce fișierele sunt salvate cu modificările dorite, acestea trebuie pregătite pentru ''commit'', iar apoi trebuie realizat ''commit''-ul care va aduce modificările pe branch-ul curent.
 === Exemple ===

← Versiunea anterioară	Versiunea de la data 25 septembrie 2017 11:22
(Nicio diferență)

@@ Linia 83: / Linia 83: @@
 Dacă se dorește revenirea la un commit anterior, acest lucru se poate face în trei 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 <code style="color: green">git checkout ''commit_id''</code>
-* 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 <code style="color: green">git reset ''commit_id''</code>
+* revenire cu pierderea ''commit''-urilor ulterioare dar fără pierderea modificărilor fișierelor; în acest caz, ''commit''-ul la care se revine devine HEAD - prin comanda <code style="color: green">git reset ''commit_id''</code>
 * 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 <code style="color: green">git reset --hard ''commit_id''</code>

@@ Linia 10: / Linia 10: @@
 * 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, tester-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;
+* după documentare, tester-ul dorește să poată nota problema, atribuind-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 [https://en.wikipedia.org/wiki/Version_contro control al versiunii], acestea pot: