WORKFLOW PE PLAN LOCAL Flashcards
Ce face comanda git clone [repository_name]?
Comanda creează o copie (sau clonă) a unui depozit git existent. În general, este folosit pentru a obține o copie a depozitului de la distanță la depozitul local.
Ce face comanda git add?
- Această comandă adaugă fișiere și modificări la indexul directorului existent.
- Puteți adăuga toate modificările simultan (fisiere modificate, noi sau sterse): git add .
- git add -a adaugă:
- Fișierele modificate.
- Fișierele șterse.
Excepție: Spre deosebire de git add ., git add -a nu adaugă fișiere noi, neaflate deja în Git. Este util dacă dorești să adaugi doar modificările și ștergerile fișierelor deja urmărite de Git, dar nu vrei să incluzi fișiere noi. - Puteți adăuga fișiere unul câte unul în mod specific folosind comanda git add [file_name]
- Puteți adăuga conținutul unui anumit folder utilizând comanda git add folder_name/
Ce face comanda git status?
Git Status este folosit în principal pentru a afișa starea zonei Staging Area /zonade așteptare/ și a depozitului. Ne ajută să urmărim toate modificările făcute, și semnalează fișierele neurmărite.
Care sunt 4 etape a ciclului fișierelor în GIT?
- Fisere neurmărite /netratate (Untracked files)
- Fisiere urmărite/tratate (Tracked files)
- Fisiere modificate (Modified files)
- Staged Files (fișiere „în așteptare” pentru comitere)
Explica etapa 1 Untracked files
În momentul in care se creeaza un nou fisier intr-un depozit (repo) al Git-ului, acesta primeste din start statusul de neurmărit/ netratat. Cu alte cuvinte, Git-ul nu va avea sub observatie acest fisier si va fi ignorat cand o modificare va aparea asupra acestuia.
Explică etapa 2 Tracked files
Daca fisierele netratate primesc acest statut in momentul in care sunt create intr-un director manipulat de Git, fiserele tratate pot dobandi acest status doar printr-o comanda explicita. Asadar, odata creat, fisierul poate fi trecut in etapa de “tracked” folosind comanda git add [nume fisier]. Din acest moment, fisierul intra in coordonarea Git-ului si orice modificare a acestuia va fi semnalizata.
Explică etapa 3 Fisiere modificate (Modified files)
Daca asupra unui fisier aflat in etapa de “tracked” se realizeaza o modificare, acesta va fi trecut de Git in etapa de “modified”. Asta presupune ca structura fisierelui s-a modificat si urmeaza sa se trimita mai departe.
Explica etapa 4 Staged Files (fișiere „în așteptare” pentru comitere)
În Git, Staged Files (fișiere „în așteptare” pentru comitere) sunt fișierele care au fost adăugate în Index sau Staging Area și sunt gata să fie incluse în următoarea comitere.
Pentru ca un fisier sa ajunga in aceasta ultima etapa este nevoie din nou de comanda git add nume fisier
Pe scurt:
* Modificare în fișiere: Când faci modificări în fișiere, acestea apar inițial doar în Working Directory (zona de lucru).
* Pregătirea modificărilor: Dacă vrei să incluzi aceste modificări în următoarea comitere, trebuie să le adaugi în Staging Area folosind comanda git add.
* Fișiere Staged: Fișierele care au fost adăugate în Staging Area sunt numite Staged Files. Ele nu sunt încă în istoria permanentă a Git, dar sunt pregătite pentru a fi incluse în următoarea comitere.
Ce face comanda git commit -m “mesaj”?
Comanda git commit -m “mesaj” este utilizată în Git pentru a crea o nouă comitere (sau salvare) în istoricul depozitului și pentru a adăuga un mesaj descriptiv care explică modificările realizate.
Ce face comanda git reset - - [nume fisier]?
Comanda git reset – [nume fisier] este utilizată pentru a elimina un fișier din Staging Area (Index) fără a șterge modificările sale din Working Directory. Cu alte cuvinte, comanda mută fișierul din starea de „pregătit pentru comitere” (staged) în starea de „modificat” (unstaged), lăsându-l neschimbat în sistemul tău de fișiere.
Cum funcționează:
* În Staging Area: Fișierul a fost adăugat cu git add și este pregătit pentru comitere.
* Cu git reset – nume fisier: Fișierul este scos din Staging Area, astfel că nu va mai fi inclus în următoarea comitere, dar orice modificare adusă acestuia rămâne vizibilă în Working Directory.
Ce comandă se folosește pentru a șterge un file din repo?
Comanda git rm este folosită pentru a șterge fișiere din depozit, eliminându-le atât din **Working Directory **(zona de lucru), cât și din Staging Area (Index). După ce folosești git rm, ștergerea fișierului este pregătită pentru comitere, iar fișierul nu va mai face parte din proiect după ce comiti această schimbare.
Cum funcționează:
* git rm nume fișier: Șterge fișierul specificat din Working Directory și din Staging Area.
* Comiterea modificării: Pentru a finaliza ștergerea, trebuie să rulezi git commit după git rm, astfel încât ștergerea să fie înregistrată în istoricul Git.
Variante ale comenzii:
git rm –cached [nume fișier]: Aceasta șterge fișierul doar din Staging Area (nu și din Working Directory), păstrându-l pe disc, dar eliminându-l din următoarea comitere. Este util atunci când dorești să nu mai urmărești un fișier în Git, dar să îl păstrezi în proiectul local.
Ce diferență este între git –reset și git rm și git rm –cached?
1. git reset
Funcție principală: ** git reset** [nume fișier] scoate fișierul din Staging Area, adică îl trece din starea „pregătit pentru comitere” în „modificat” (unstaged). Acesta rămâne în Working Directory cu modificările sale intacte, dar nu va mai fi inclus în următoarea comitere.
2. git rm
Funcție principală: git rm este folosit pentru a șterge complet un fișier atât din Staging Area cât și din Working Directory (sistemul de fișiere) după comitere.
3. git rm –cached
Funcție principală: **git rm –cached **este utilizat pentru a scoate un fișier din Staging Area, dar fără a-l șterge din Working Directory (de obicei utilizat pentru fișiere care nu mai trebuie urmărite).
Rezumat rapid:
git reset [nume fișier]: Scoate fișierul din Staging Area fără a-l afecta pe disc.
git rm [nume fișier]: Șterge fișierul complet din depozit și din sistemul de fișiere.
git rm –cached [nume fișier]: Elimină fișierul doar din Git, dar îl păstrează pe disc.
Istoricul depozitului local
Ce face git log?
git log ofera informatii legate de fiecare “commit” in parte efectuat pe depozitul curent, in ordine cronologica inversa: autor, data, mesaj, SHA-1
Argumente pt git log:
git log - -stat – arata statisticile pentru fisierele modificate in fiecare “commit”
git log - -oneline – arata doar primele 6 caractere din codul “SHA-1” pentru o citire mai usoara si mai rapida a istoricului.
git log - -relative-date – afiseaza informatiile continand data intr-un format relativ, ca de exemplu acum o saptamana.
git log - -grep – afiseaza toate informatiille pentru “commit-urile” care detin un anumit mesaj
git log - -author – afiseaza capturile facute doar de anumiti autori.
Istoricul depozitului local
Ce este SHA-1?
SHA-1” este un cod unic prin care se identifica fiecare “commit” alcatuit din 40 de caractere
Resetare depozit local
Care sunt comenzile de resetare a depozitului local?
reset
revert
checkout
clean
Ideea de baza a acestor comenzi este aceea de a mentine o copie sigura a proiectului astfel incat nici un utilizator sa nu-si faca probleme ca poate produce unele greseli majore care nu mai pot fi reparate.
Resetare depozit local
Ce face git checkout [SHA-1_comitere]?
Cand in urma vizionarii istoricului se doreste revenirea la un anumit “commit”.
Când vrei doar să vezi sau să testezi o versiune anterioară
Scop: Să accesezi o comitere specifică din trecut, fără a modifica ramura curentă.
Utilizare: Folosește git checkout [SHA_comitere] dacă vrei să inspectezi o versiune veche sau să testezi funcționalitatea la acel punct din istorie. Aceasta te plasează într-un detached HEAD, unde poți vedea sau testa versiunea, dar nu se modifică nimic în ramura curentă.
Atenție: Orice modificări făcute aici vor fi temporare și nu vor face parte din nicio ramură activă, decât dacă creezi o ramură nouă cu git checkout -b.
Resetare depozit local
Ce este HEAD?
În Git, HEAD este un indicator sau o referință care arată mereu spre ultima comitere din ramura curentă. Practic, arată unde ești poziționat în istoria depozitului.
Resetare depozit local
Ce este detached HEAD?
În Git, un detached HEAD înseamnă că HEAD nu mai indică o ramură, ci direct o comitere specifică. Practic, ești într-o stare în care faci modificări pe o anumită versiune a codului, dar aceste modificări nu sunt legate de nicio ramură.
Cum ajungi într-un detached HEAD:
Când rulezi git checkout pe o anumită comitere (folosind un SHA al comiterii), în loc de o ramură: git checkout a1b2c3d
Acum, HEAD este „detached” și arată direct către această comitere, nu către o ramură. Git te va anunța că ești în detached HEAD. Acum, HEAD arată direct la comiterea a1b2c3d, iar dacă faci modificări, ele nu sunt legate de vreo ramură.
Ce se întâmplă într-un detached HEAD:
Poți face modificări și chiar noi comiteri, dar acestea nu vor aparține niciunei ramuri. Dacă schimbi ramura sau închizi acest „detached HEAD”, poți pierde aceste comiteri.
Dacă vrei să păstrezi modificările, ar trebui să creezi o nouă ramură din detached HEAD: git checkout -b new branch
Resetare depozit local
Ce face git checkout [nume fisier]?
Intoarce un fisier la o versiune mai veche
Resetare depozit local
Ce face git revert [SHA_comitere]?
git revert[SHA_comitere] preia “commit-ul” specificat, inverseaza modificarile pana la acel moment si creeaza un nou “commit” ce contine mesajul de “revert commit”. Nu modifica istoria.
Când să folosești git revert:
* Pentru a reveni asupra unei modificări fără a afecta istoria: Este util în proiectele colaborative, unde nu vrei să rescrii istoria (spre deosebire de git reset, care rescrie).
* Pentru a corecta erorile într-un mod sigur, permițând altor colaboratori să vadă toate schimbările, inclusiv inversările.
Cand sa folosesc git checkout [SHA_comitere] si cand sa folosesc git revert [SHA_comitere]?
- git checkout [SHA_comitere] - Când vrei doar să vezi sau să testezi o versiune anterioară
Scop: Să accesezi o comitere specifică din trecut, fără a modifica ramura curentă.
Utilizare: Folosește git checkout [SHA_comitere] dacă vrei să inspectezi o versiune veche sau să testezi funcționalitatea la acel punct din istorie.
-
git revert [SHA_comitere] - Când vrei să anulezi efectiv o comitere anterioară/o modificare păstrând istoricul
Scop: Să creezi o comitere nouă care inversează modificările dintr-o comitere anterioară, în mod permanent și transparent.
Utilizare: Folosește git revert atunci când vrei să păstrezi toate modificările în istorie și să arăți că ai făcut o corectare sau revenire asupra unei modificări anterioare.
Ce face git clean?
Comanda git clean este folosită pentru a șterge fișierele neînregistrate (necontrolate de Git) din directorul de lucru. Aceste fișiere sunt cele care:
- Nu au fost adăugate în Staging Area.
- Nu fac parte din istoricul depozitului Git.
Cum funcționează:
- Sintaxă de bază:
bash git clean -f
Aceasta va șterge toate fișierele neînregistrate din directorul curent.
Opțiuni importante:
1. Ștergere fișiere și directoare neînregistrate:
- -f sau --force: Obligatoriu pentru a confirma ștergerea fișierelor.
- -d: Șterge și subdirectoarele neînregistrate, nu doar fișierele.
- Exemplu:
**git clean -fd** Aceasta șterge atât fișierele neînregistrate, cât și directoarele neînregistrate.
-
Simulare a ștergerii:
-
-nsau--dry-run: Afișează fișierele care ar fi șterse, fără a le șterge efectiv. Este util pentru a verifica înainte de a șterge ceva. -
Exemplu:git clean -nAceasta îți arată o listă a fișierelor care ar fi șterse dacă ai folosi
-f.
-
Atenție:
- Fișierele șterse cu git clean nu pot fi recuperate din Git, deoarece ele nu fac parte din istoricul depozitului.
- Este recomandat să folosești mai întâi git clean -n pentru a vedea ce va fi șters.
Pe scurt:git clean șterge fișierele și directoarele neînregistrate pentru a menține directorul de lucru curat.
