Exerciții practice

Lucrez la exercițiul „Configurează-ți identitatea și editorul” din capitolul „1. Getting Started”, la Pro Git. Enunțul: Ai nevoie de: Git instalat și un terminal. 1. Verifică versiunea (pentru `init.defaultBranch` ai nevoie de cel puțin 2.28): ```bash git --version ``` 2. Setează identitatea și ramura implicită, la nivel global (pentru utilizatorul tău): ```bash git config --global user.name "Prenume Nume" git config --global user.email "adresa@exemplu.ro" git config --global init.defaultBranch main git config --global core.editor "nano" # sau "code --wait", "vim" ``` 3. Afișează toate setările și fișierul din care vine fiecare: `git config --list --show-origin`. 4. Creează un depozit de test (`mkdir test-config && cd test-config && git init`) și setează **doar aici** un alt e-mail: `git config user.email… Înainte de pasul 5, întreabă-mă ce valoare cred că va afișa `git config user.email` în depozitul de test și în afara lui și de ce. Nu-mi spune răspunsul; după ce rulez comenzile, ajută-mă să explic ordinea system → global → local cu propriile cuvinte.

Lucrez la exercițiul „Configurează-ți identitatea și editorul” din capitolul „1. Getting Started”, la Pro Git. Enunțul: Ai nevoie de: Git instalat și un terminal. 1. Verifică versiunea (pentru `init.defaultBranch` ai nevoie de cel puțin 2.28): ```bash git --version ``` 2. Setează identitatea și ramura implicită, la nivel global (pentru utilizatorul tău): ```bash git config --global user.name "Prenume Nume" git config --global user.email "adresa@exemplu.ro" git config --global init.defaultBranch main git config --global core.editor "nano" # sau "code --wait", "vim" ``` 3. Afișează toate setările și fișierul din care vine fiecare: `git config --list --show-origin`. 4. Creează un depozit de test (`mkdir test-config && cd test-config && git init`) și setează **doar aici** un alt e-mail: `git config user.email… Îți lipesc ce afișează `git config --list --show-origin`. Verifică-mi dacă identitatea și ramura implicită sunt setate corect și, dacă găsești o problemă (dublură, greșeală de tipar, nivel greșit), dă-mi un indiciu despre ce comandă să folosesc, fără să-mi scrii direct comanda corectă.

Lucrez la exercițiul „Primul depozit și ce se află în .git” din capitolul „1. Getting Started”, la Pro Git. Enunțul: 1. Creează un depozit gol și uită-te în directorul Git: ```bash mkdir -p ~/git-exercitii/primul && cd ~/git-exercitii/primul git init ls -A .git cat .git/HEAD git status ``` 2. Creează un fișier, apoi rulează `git status` după fiecare pas: ```bash echo "# Primul meu proiect" > README.md git status git add README.md git status git commit -m "Adaug README" git status git log ``` 3. Numără obiectele salvate de Git: `find .git/objects -type f`. **Ce urmărești:** ce creează `git init`, cum se schimbă mesajul lui `git status` și câte obiecte apar în baza de date după primul commit cu un singur fișier. Îți lipesc ce afișează `ls -A .git`. Întreabă-mă, pe rând, ce cred că face fiecare element (HEAD, config, objects, refs) și corectează-mă doar după ce încerc să răspund. Dă-mi indicii din capitolul despre directorul Git, nu explicația completă de la început.

Lucrez la exercițiul „Primul depozit și ce se află în .git” din capitolul „1. Getting Started”, la Pro Git. Enunțul: 1. Creează un depozit gol și uită-te în directorul Git: ```bash mkdir -p ~/git-exercitii/primul && cd ~/git-exercitii/primul git init ls -A .git cat .git/HEAD git status ``` 2. Creează un fișier, apoi rulează `git status` după fiecare pas: ```bash echo "# Primul meu proiect" > README.md git status git add README.md git status git commit -m "Adaug README" git status git log ``` 3. Numără obiectele salvate de Git: `find .git/objects -type f`. **Ce urmărești:** ce creează `git init`, cum se schimbă mesajul lui `git status` și câte obiecte apar în baza de date după primul commit cu un singur fișier. După primul commit am găsit trei fișiere în .git/objects. Lasă-mă să ghicesc ce reprezintă fiecare și pune-mi întrebări ajutătoare (ce salvează Git pentru conținut, pentru director, pentru commit) până ajung singur la răspuns. Nu-mi spune direct.

Lucrez la exercițiul „Unde se află fiecare versiune a fișierului?” din capitolul „1. Getting Started”, la Pro Git. Enunțul: Pentru secvența de mai jos, scrie pe hârtie, **înainte să rulezi**, pentru fiecare pas: ce versiune a lui `nota.txt` este în directorul de lucru, ce versiune este în staging area și ce versiune este în ultimul commit, precum și ce va afișa `git status -s`. ```bash git init stari && cd stari echo "v1" > nota.txt # pasul 1 git add nota.txt # pasul 2 echo "v2" >> nota.txt # pasul 3 git commit -m "Prima notă" # pasul 4 git add nota.txt # pasul 5 git commit -m "A doua notă" # pasul 6 ``` Apoi rulează pașii unul câte unul, cu `git status -s` și `git show HEAD:nota.txt` după fiecare, și compară. Răspunde la final: ce a intrat în commitul de la pasul 4 și de ce? Ce înseamnă că Git salvează… Îți scriu predicțiile mele pentru fiecare pas (director de lucru, staging, commit, `git status -s`). Verifică unde am greșit și, pentru fiecare greșeală, pune-mi o întrebare care să mă facă să-mi dau seama singur, în loc să-mi dai răspunsul corect.

Lucrez la exercițiul „Unde se află fiecare versiune a fișierului?” din capitolul „1. Getting Started”, la Pro Git. Enunțul: Pentru secvența de mai jos, scrie pe hârtie, **înainte să rulezi**, pentru fiecare pas: ce versiune a lui `nota.txt` este în directorul de lucru, ce versiune este în staging area și ce versiune este în ultimul commit, precum și ce va afișa `git status -s`. ```bash git init stari && cd stari echo "v1" > nota.txt # pasul 1 git add nota.txt # pasul 2 echo "v2" >> nota.txt # pasul 3 git commit -m "Prima notă" # pasul 4 git add nota.txt # pasul 5 git commit -m "A doua notă" # pasul 6 ``` Apoi rulează pașii unul câte unul, cu `git status -s` și `git show HEAD:nota.txt` după fiecare, și compară. Răspunde la final: ce a intrat în commitul de la pasul 4 și de ce? Ce înseamnă că Git salvează… Vreau să explic cu cuvintele mele de ce Git e descris ca un sistem cu instantanee, nu cu diferențe. Întreabă-mă cum aș desena trei commituri în ambele modele și dă-mi indicii dacă amestec ideile; nu scrie tu explicația.

Lucrez la exercițiul „Fiecare clonă e o copie completă” din capitolul „1. Getting Started”, la Pro Git. Enunțul: Demonstrează practic de ce un sistem distribuit nu are un *single point of failure*. 1. Creează un depozit „server” cu câteva commituri: ```bash mkdir -p ~/git-exercitii/distribuit && cd ~/git-exercitii/distribuit git init server && cd server for i in 1 2 3; do echo "pas $i" >> jurnal.txt; git add .; git commit -m "Pasul $i"; done cd .. ``` 2. Clonează-l: `git clone server laptop`. 3. „Serverul a ars”: `rm -rf server`. 4. În `laptop` verifică istoria (`git log --oneline`) și refă serverul dintr-o clonă: `cd .. && git clone --bare laptop/.git server-nou.git`. 5. Clonează serverul nou într-un al treilea loc și verifică din nou istoria. **Întrebare:** ce s-ar fi pierdut dacă proiectul era… Înainte de pasul 3, întreabă-mă ce cred că va mai afișa `git log` în `laptop` după ce șterg serverul și ce s-ar întâmpla în cazul unui sistem centralizat. Nu-mi confirma nimic până nu rulez comenzile; apoi verifică-mi explicația.

Lucrez la exercițiul „Fiecare clonă e o copie completă” din capitolul „1. Getting Started”, la Pro Git. Enunțul: Demonstrează practic de ce un sistem distribuit nu are un *single point of failure*. 1. Creează un depozit „server” cu câteva commituri: ```bash mkdir -p ~/git-exercitii/distribuit && cd ~/git-exercitii/distribuit git init server && cd server for i in 1 2 3; do echo "pas $i" >> jurnal.txt; git add .; git commit -m "Pasul $i"; done cd .. ``` 2. Clonează-l: `git clone server laptop`. 3. „Serverul a ars”: `rm -rf server`. 4. În `laptop` verifică istoria (`git log --oneline`) și refă serverul dintr-o clonă: `cd .. && git clone --bare laptop/.git server-nou.git`. 5. Clonează serverul nou într-un al treilea loc și verifică din nou istoria. **Întrebare:** ce s-ar fi pierdut dacă proiectul era… Ajută-mă să fac un tabel cu sistemele locale (RCS), centralizate și distribuite: unde se află istoria, ce se întâmplă dacă pică serverul, cum lucrezi offline. Pune-mi întrebări pentru fiecare celulă și corectează-mă cu indicii, nu completa tu tabelul.

Lucrez la exercițiul „Ciclul de viață al fișierelor, văzut cu git status -s” din capitolul „2. Git Basics”, la Pro Git. Enunțul: Scrie înainte de fiecare `git status -s` ce crezi că va afișa, apoi rulează. ```bash git init ciclu && cd ciclu echo "# Proiect" > README.md echo a > a.txt git status -s # 1 git add README.md git status -s # 2 echo b >> README.md git status -s # 3 git add . git commit -m "Primul commit" echo c >> a.txt git status -s # 4 git add a.txt git status -s # 5 echo d >> a.txt git status -s # 6 git diff # 7 git diff --staged # 8 ``` **Ce trebuie să obții:** să poți citi cele două coloane ale formatului scurt (staging / director de lucru) și să știi ce compară `git diff` față de `git diff --staged`. Îți dau rezultatele mele pentru `git status -s` la pașii 1–6. Întreabă-mă ce înseamnă fiecare coloană și fiecare literă și corectează-mă cu indicii, fără să-mi explici tu de la început tabelul complet.

Lucrez la exercițiul „Ciclul de viață al fișierelor, văzut cu git status -s” din capitolul „2. Git Basics”, la Pro Git. Enunțul: Scrie înainte de fiecare `git status -s` ce crezi că va afișa, apoi rulează. ```bash git init ciclu && cd ciclu echo "# Proiect" > README.md echo a > a.txt git status -s # 1 git add README.md git status -s # 2 echo b >> README.md git status -s # 3 git add . git commit -m "Primul commit" echo c >> a.txt git status -s # 4 git add a.txt git status -s # 5 echo d >> a.txt git status -s # 6 git diff # 7 git diff --staged # 8 ``` **Ce trebuie să obții:** să poți citi cele două coloane ale formatului scurt (staging / director de lucru) și să știi ce compară `git diff` față de `git diff --staged`. Nu înțeleg de ce `git diff` și `git diff --staged` afișează linii diferite la pașii 7 și 8. Pune-mi întrebări despre cele trei locuri (director de lucru, staging, commit) până îmi dau seama singur ce compară fiecare.

Lucrez la exercițiul „.gitignore, git rm --cached și git mv” din capitolul „2. Git Basics”, la Pro Git. Enunțul: Continuă în depozitul `ciclu` (sau în orice depozit de test cu un commit). 1. Creează fișiere care nu trebuie urmărite și un `.gitignore`: ```bash printf '*.log\nbuild/\n!important.log\n' > .gitignore touch eroare.log important.log mkdir build && touch build/out.o git status -s git status -s --ignored git check-ignore -v eroare.log build/out.o ``` 2. Fă commit cu `.gitignore` și `important.log`. 3. Redenumește un fișier cu Git și scoate un fișier de sub urmărire fără să-l ștergi de pe disc: ```bash git mv a.txt b.txt git rm --cached important.log git status -s git commit -m "Redenumesc a.txt; nu mai urmăresc important.log" ls ``` Vreau să scriu un .gitignore pentru un proiect cu fișiere `*.tmp`, un director `node_modules/` și un singur fișier `config.example.tmp` care trebuie păstrat. Lasă-mă să încerc singur regulile, apoi verifică-le și dă-mi indicii dacă vreuna nu face ce cred.

Lucrez la exercițiul „.gitignore, git rm --cached și git mv” din capitolul „2. Git Basics”, la Pro Git. Enunțul: Continuă în depozitul `ciclu` (sau în orice depozit de test cu un commit). 1. Creează fișiere care nu trebuie urmărite și un `.gitignore`: ```bash printf '*.log\nbuild/\n!important.log\n' > .gitignore touch eroare.log important.log mkdir build && touch build/out.o git status -s git status -s --ignored git check-ignore -v eroare.log build/out.o ``` 2. Fă commit cu `.gitignore` și `important.log`. 3. Redenumește un fișier cu Git și scoate un fișier de sub urmărire fără să-l ștergi de pe disc: ```bash git mv a.txt b.txt git rm --cached important.log git status -s git commit -m "Redenumesc a.txt; nu mai urmăresc important.log" ls ``` Întreabă-mă ce cred că se întâmplă cu fișierul pe disc și în următorul commit la `git rm` și la `git rm --cached`. Corectează-mă pe baza rezultatelor mele din `git status -s`, fără să-mi dai direct definițiile.

Lucrez la exercițiul „Repară un commit și anulează modificări” din capitolul „2. Git Basics”, la Pro Git. Enunțul: Într-un depozit de test cu cel puțin un commit: 1. Ai uitat un fișier în ultimul commit: ```bash echo "linie" > note.txt git add note.txt git commit -m "Adaug notițe" echo "uitat" > uitat.txt git add uitat.txt git commit --amend -m "Adaug notițe și fișierul uitat" git log --oneline -2 git show --stat HEAD ``` 2. Ai pus în staging ceva greșit: ```bash echo "greșit" >> README.md git add README.md git status -s git restore --staged README.md git status -s ``` 3. Renunță complet la modificare: `git restore README.md`, apoi `git status -s`. **Atenție:** `git restore ` șterge definitiv modificările necomise din acel fișier. Am observat că după `git commit --amend` hash-ul ultimului commit s-a schimbat. Întreabă-mă ce cred că s-a întâmplat cu vechiul commit și de ce nu e bine să fac amend la un commit deja trimis pe server. Dă-mi indicii, nu răspunsul.

Lucrez la exercițiul „Repară un commit și anulează modificări” din capitolul „2. Git Basics”, la Pro Git. Enunțul: Într-un depozit de test cu cel puțin un commit: 1. Ai uitat un fișier în ultimul commit: ```bash echo "linie" > note.txt git add note.txt git commit -m "Adaug notițe" echo "uitat" > uitat.txt git add uitat.txt git commit --amend -m "Adaug notițe și fișierul uitat" git log --oneline -2 git show --stat HEAD ``` 2. Ai pus în staging ceva greșit: ```bash echo "greșit" >> README.md git add README.md git status -s git restore --staged README.md git status -s ``` 3. Renunță complet la modificare: `git restore README.md`, apoi `git status -s`. **Atenție:** `git restore ` șterge definitiv modificările necomise din acel fișier. Dă-mi pe rând 4 situații scurte (fișier pus greșit în staging, modificare de aruncat, mesaj de commit greșit, fișier uitat) și lasă-mă să aleg comanda. Verifică-mi alegerea și explică-mi doar după ce încerc.

Lucrez la exercițiul „Caută în istorie cu git log” din capitolul „2. Git Basics”, la Pro Git. Enunțul: Folosește un depozit cu mai multe commituri (de ex. `ciclu`). Fă încă două-trei commituri, într-unul adăugând textul `parola_temporara` într-un fișier, iar în următorul ștergându-l. 1. Formate de afișare: ```bash git log --oneline git log -p -1 git log --stat git log --pretty=format:"%h - %an, %ar : %s" ``` 2. Filtre: `git log --since="1 hour ago"`, `git log --author=""`, `git log -- README.md`. 3. Găsește commiturile care au adăugat sau au șters textul: `git log -S parola_temporara --oneline`. 4. Creează un alias și folosește-l: ```bash git config --global alias.lg "log --oneline --graph --all --decorate" git lg ``` **Ce trebuie să obții:** comanda care îți arată exact commiturile ce au… Vreau să găsesc commiturile mele din ultima săptămână care au modificat un anumit fișier. Întreabă-mă ce opțiuni cred că trebuie combinate și lasă-mă să încerc; dă-mi indicii din `git help log` dacă mă blochez.

Lucrez la exercițiul „Caută în istorie cu git log” din capitolul „2. Git Basics”, la Pro Git. Enunțul: Folosește un depozit cu mai multe commituri (de ex. `ciclu`). Fă încă două-trei commituri, într-unul adăugând textul `parola_temporara` într-un fișier, iar în următorul ștergându-l. 1. Formate de afișare: ```bash git log --oneline git log -p -1 git log --stat git log --pretty=format:"%h - %an, %ar : %s" ``` 2. Filtre: `git log --since="1 hour ago"`, `git log --author=""`, `git log -- README.md`. 3. Găsește commiturile care au adăugat sau au șters textul: `git log -S parola_temporara --oneline`. 4. Creează un alias și folosește-l: ```bash git config --global alias.lg "log --oneline --graph --all --decorate" git lg ``` **Ce trebuie să obții:** comanda care îți arată exact commiturile ce au… Pune-mi întrebări ca să-mi dau seama singur care e diferența dintre `git log -S text` și `git log --grep=text`. Verifică-mi apoi răspunsul cu un exemplu pe care îl rulez eu.

Lucrez la exercițiul „Taguri și un remote local, fără cont online” din capitolul „2. Git Basics”, la Pro Git. Enunțul: Într-un depozit de test cu cel puțin 3 commituri: 1. Creează un tag ușor pe un commit mai vechi și unul adnotat pe ultimul: ```bash git tag v0.1 HEAD~2 git tag -a v1.0 -m "Versiunea 1.0" git tag git cat-file -t v0.1 git cat-file -t v1.0 git show v1.0 --no-patch ``` 2. Creează un „server” local (un depozit bare) și adaugă-l ca remote: ```bash git init --bare ../server.git git remote add origin ../server.git git remote -v git push -u origin main git ls-remote origin ``` 3. Trimite și tagurile: `git push origin --tags`, apoi `git ls-remote origin` din nou. 4. Clonează serverul în alt director (`git clone ../server.git ../coleg`) și verifică `git tag` acolo. Întreabă-mă ce diferențe am observat între `v0.1` și `v1.0` la `git cat-file -t` și `git show`, apoi pune-mi o situație (lansarea unei versiuni publice, un semn de carte personal) și lasă-mă să aleg tipul de tag. Verifică-mi alegerea.

Lucrez la exercițiul „Taguri și un remote local, fără cont online” din capitolul „2. Git Basics”, la Pro Git. Enunțul: Într-un depozit de test cu cel puțin 3 commituri: 1. Creează un tag ușor pe un commit mai vechi și unul adnotat pe ultimul: ```bash git tag v0.1 HEAD~2 git tag -a v1.0 -m "Versiunea 1.0" git tag git cat-file -t v0.1 git cat-file -t v1.0 git show v1.0 --no-patch ``` 2. Creează un „server” local (un depozit bare) și adaugă-l ca remote: ```bash git init --bare ../server.git git remote add origin ../server.git git remote -v git push -u origin main git ls-remote origin ``` 3. Trimite și tagurile: `git push origin --tags`, apoi `git ls-remote origin` din nou. 4. Clonează serverul în alt director (`git clone ../server.git ../coleg`) și verifică `git tag` acolo. După primul push, tagurile nu apăreau pe server. Nu-mi spune direct de ce; dă-mi indicii despre ce trimite `git push origin main` și ce înseamnă linia cu `^{}` din `git ls-remote`.

Lucrez la exercițiul „O ramură hotfix și un merge fast-forward” din capitolul „3. Git Branching”, la Pro Git. Enunțul: ```bash git init ramuri && cd ramuri echo "Salut" > index.html; git add .; git commit -m "C0: pagina" echo "meniu" >> index.html; git commit -am "C1: meniu" git switch -c hotfix echo "footer" > footer.html; git add .; git commit -m "C2: footer" git log --oneline --decorate --all git switch main ls git merge hotfix git branch -d hotfix git log --oneline --graph ``` Răspunde: unde arată `HEAD` înainte și după `git switch main`? De ce `footer.html` dispare din director după `switch` și reapare după `merge`? De ce merge-ul nu creează un commit nou? Vreau să desenez pe hârtie commiturile și pointerii `main`, `hotfix` și `HEAD` după fiecare comandă. Întreabă-mă unde arată fiecare pointer după fiecare pas și corectează-mă cu indicii când greșesc.

Lucrez la exercițiul „O ramură hotfix și un merge fast-forward” din capitolul „3. Git Branching”, la Pro Git. Enunțul: ```bash git init ramuri && cd ramuri echo "Salut" > index.html; git add .; git commit -m "C0: pagina" echo "meniu" >> index.html; git commit -am "C1: meniu" git switch -c hotfix echo "footer" > footer.html; git add .; git commit -m "C2: footer" git log --oneline --decorate --all git switch main ls git merge hotfix git branch -d hotfix git log --oneline --graph ``` Răspunde: unde arată `HEAD` înainte și după `git switch main`? De ce `footer.html` dispare din director după `switch` și reapare după `merge`? De ce merge-ul nu creează un commit nou? Pune-mi întrebări care să mă ducă singur la condiția în care un merge e fast-forward și la ce s-ar fi întâmplat dacă făceam un commit nou pe `main` înainte de merge. Nu-mi da răspunsul direct.

Lucrez la exercițiul „Provoacă și rezolvă un conflict de merge” din capitolul „3. Git Branching”, la Pro Git. Enunțul: În depozitul `ramuri` (sau unul nou cu un commit): ```bash printf 'titlu: Magazin\nculoare: alb\n' > config.txt git add .; git commit -m "C3: config" git switch -c tema printf 'titlu: Magazin\nculoare: negru\n' > config.txt git commit -am "C4: tema neagră" git switch main printf 'titlu: Magazin\nculoare: albastru\n' > config.txt git commit -am "C5: tema albastră" git merge tema ``` 1. Citește mesajul, apoi `git status -s` și `cat config.txt`. 2. Rezolvă conflictul în editor: păstrează o singură linie `culoare: albastru-închis` și șterge marcajele. 3. Încheie merge-ul: `git add config.txt` și `git commit` (acceptă mesajul propus). 4. Afișează `git log --oneline --graph`. Înainte de `git merge tema`, întreabă-mă ce linii cred că vor intra în conflict și care se vor combina automat și de ce. După ce rulez, verifică-mi predicția și ajută-mă să explic rolul strămoșului comun în three-way merge.

Lucrez la exercițiul „Provoacă și rezolvă un conflict de merge” din capitolul „3. Git Branching”, la Pro Git. Enunțul: În depozitul `ramuri` (sau unul nou cu un commit): ```bash printf 'titlu: Magazin\nculoare: alb\n' > config.txt git add .; git commit -m "C3: config" git switch -c tema printf 'titlu: Magazin\nculoare: negru\n' > config.txt git commit -am "C4: tema neagră" git switch main printf 'titlu: Magazin\nculoare: albastru\n' > config.txt git commit -am "C5: tema albastră" git merge tema ``` 1. Citește mesajul, apoi `git status -s` și `cat config.txt`. 2. Rezolvă conflictul în editor: păstrează o singură linie `culoare: albastru-închis` și șterge marcajele. 3. Încheie merge-ul: `git add config.txt` și `git commit` (acceptă mesajul propus). 4. Afișează `git log --oneline --graph`. Sunt în mijlocul unui merge cu conflict și nu știu cum să continui sau cum să renunț. Îți lipesc `git status`. Dă-mi indicii pas cu pas (ce citesc în mesaj, ce comandă abandonează merge-ul), fără să-mi scrii toată secvența.

Lucrez la exercițiul „Rebase pentru un istoric liniar” din capitolul „3. Git Branching”, la Pro Git. Enunțul: ```bash git init rb && cd rb echo base > base.txt; git add .; git commit -m "C1" echo 2 > m2.txt; git add .; git commit -m "C2" git switch -c experiment echo e > e.txt; git add .; git commit -m "C4: experiment" git switch main echo 3 > m3.txt; git add .; git commit -m "C3: main" git log --oneline --graph --all # (a) git switch experiment git rebase main git log --oneline --graph --all # (b) git switch main git merge experiment # (c) ``` Compară hash-ul lui „C4: experiment” la (a) și la (b). Apoi refă exercițiul de la zero, dar cu `git merge experiment` direct (fără rebase) și compară cele două grafuri finale. Am observat că „C4: experiment” are alt hash după rebase. Întreabă-mă ce conține un commit (părinte, tree, autor) și lasă-mă să deduc singur de ce hash-ul trebuie să se schimbe. Nu-mi spune direct.

Lucrez la exercițiul „Rebase pentru un istoric liniar” din capitolul „3. Git Branching”, la Pro Git. Enunțul: ```bash git init rb && cd rb echo base > base.txt; git add .; git commit -m "C1" echo 2 > m2.txt; git add .; git commit -m "C2" git switch -c experiment echo e > e.txt; git add .; git commit -m "C4: experiment" git switch main echo 3 > m3.txt; git add .; git commit -m "C3: main" git log --oneline --graph --all # (a) git switch experiment git rebase main git log --oneline --graph --all # (b) git switch main git merge experiment # (c) ``` Compară hash-ul lui „C4: experiment” la (a) și la (b). Apoi refă exercițiul de la zero, dar cu `git merge experiment` direct (fără rebase) și compară cele două grafuri finale. Vreau să-mi formez o părere despre când folosesc merge și când rebase. Pune-mi 3 situații concrete dintr-o echipă și lasă-mă să aleg și să argumentez; verifică-mi argumentele pe baza regulii din carte despre commiturile publicate.

Lucrez la exercițiul „Doi colegi, un server bare și un push respins” din capitolul „3. Git Branching”, la Pro Git. Enunțul: Simulezi doi colegi pe același calculator. ```bash mkdir echipa && cd echipa git init --bare server.git git clone server.git ana && cd ana echo a > a.txt; git add .; git commit -m "Ana 1"; git push -u origin main cd .. && git clone server.git bogdan && cd bogdan echo x > x.txt; git add .; git commit -m "Bogdan 1"; git push git switch -c functie echo f > f.txt; git add .; git commit -m "Bogdan: funcție"; git push -u origin functie cd ../ana echo a2 >> a.txt; git commit -am "Ana 2" git push # (1) git fetch # (2) git branch -vv # (3) git branch -a git merge origin/main # (4) acceptă mesajul git push git switch functie # (5) git branch -vv git log --oneline --graph --all ``` La final șterge… Îți lipesc ce afișează `git branch -vv` la pasul 3. Întreabă-mă ce înseamnă „ahead 1” și „behind 1” și ce commit corespunde fiecăruia; corectează-mă cu indicii până pot explica de ce push-ul a fost respins.

Lucrez la exercițiul „Doi colegi, un server bare și un push respins” din capitolul „3. Git Branching”, la Pro Git. Enunțul: Simulezi doi colegi pe același calculator. ```bash mkdir echipa && cd echipa git init --bare server.git git clone server.git ana && cd ana echo a > a.txt; git add .; git commit -m "Ana 1"; git push -u origin main cd .. && git clone server.git bogdan && cd bogdan echo x > x.txt; git add .; git commit -m "Bogdan 1"; git push git switch -c functie echo f > f.txt; git add .; git commit -m "Bogdan: funcție"; git push -u origin functie cd ../ana echo a2 >> a.txt; git commit -am "Ana 2" git push # (1) git fetch # (2) git branch -vv # (3) git branch -a git merge origin/main # (4) acceptă mesajul git push git switch functie # (5) git branch -vv git log --oneline --graph --all ``` La final șterge… Pune-mi întrebări ca să ajung singur la diferența dintre `git fetch`, `git merge origin/main` și `git pull`. După ce încerc o explicație, verific-o și spune-mi ce am omis, fără să rescrii tu totul.

Lucrez la exercițiul „git rebase --onto cu ramurile server și client” din capitolul „3. Git Branching”, la Pro Git. Enunțul: Reproduci exemplul din carte: o ramură `client` pornită din `server`; vrei să integrezi doar `client` în `main`. ```bash git init onto && cd onto echo b > base.txt; git add .; git commit -m "C1" git switch -c server echo s1 > s.txt; git add .; git commit -m "C3: server" git switch -c client echo c1 > c.txt; git add .; git commit -m "C8: client" echo c2 >> c.txt; git commit -am "C9: client" git switch server echo s2 >> s.txt; git commit -am "C4: server" git switch main echo m >> base.txt; git commit -am "C5: main" git log --oneline --graph --all ``` 1. Mută doar commiturile din `client` care nu sunt în `server` peste `main`, cu `git rebase --onto`. 2. Adu `main` la zi cu `client`… Înainte să rulez `git rebase --onto`, întreabă-mă ce commituri cred că vor fi mutate și pe ce bază. Lasă-mă să le enumăr; corectează-mă cu indicii despre rolul fiecăruia dintre cele trei argumente.

Lucrez la exercițiul „git rebase --onto cu ramurile server și client” din capitolul „3. Git Branching”, la Pro Git. Enunțul: Reproduci exemplul din carte: o ramură `client` pornită din `server`; vrei să integrezi doar `client` în `main`. ```bash git init onto && cd onto echo b > base.txt; git add .; git commit -m "C1" git switch -c server echo s1 > s.txt; git add .; git commit -m "C3: server" git switch -c client echo c1 > c.txt; git add .; git commit -m "C8: client" echo c2 >> c.txt; git commit -am "C9: client" git switch server echo s2 >> s.txt; git commit -am "C4: server" git switch main echo m >> base.txt; git commit -am "C5: main" git log --oneline --graph --all ``` 1. Mută doar commiturile din `client` care nu sunt în `server` peste `main`, cu `git rebase --onto`. 2. Adu `main` la zi cu `client`… Dacă ramura `server` ar fi fost deja trimisă pe un server comun, ce probleme ar fi apărut pentru colegi după rebase? Întreabă-mă pas cu pas ce ar vedea un coleg la următorul pull și verifică-mi raționamentul.

Lucrez la exercițiul „Un depozit bare și protocolul local” din capitolul „4. Git on the Server”, la Pro Git. Enunțul: ```bash mkdir server-local && cd server-local git init proiect && cd proiect echo a > a.txt; git add .; git commit -m "init"; cd .. git clone --bare proiect proiect.git ls proiect.git git config -f proiect.git/config core.bare git clone proiect.git c1 # cale simplă git clone file://$PWD/proiect.git c2 # URL file:// ls c1/.git/objects c2/.git/objects/pack ls -l proiect.git/objects/*/* c1/.git/objects/*/* | head ``` Răspunde: ce lipsește dintr-un depozit bare față de unul obișnuit? Ce diferență vezi între `c1` și `c2` în `objects` și în coloana a doua (numărul de legături) a lui `ls -l`? De ce un server ține de obicei depozite bare? Întreabă-mă ce am observat diferit în `c1` și `c2` și ajută-mă cu indicii să leg observația de explicația din carte despre protocolul local. Nu-mi spune direct ce face Git în fiecare caz.

Lucrez la exercițiul „Un depozit bare și protocolul local” din capitolul „4. Git on the Server”, la Pro Git. Enunțul: ```bash mkdir server-local && cd server-local git init proiect && cd proiect echo a > a.txt; git add .; git commit -m "init"; cd .. git clone --bare proiect proiect.git ls proiect.git git config -f proiect.git/config core.bare git clone proiect.git c1 # cale simplă git clone file://$PWD/proiect.git c2 # URL file:// ls c1/.git/objects c2/.git/objects/pack ls -l proiect.git/objects/*/* c1/.git/objects/*/* | head ``` Răspunde: ce lipsește dintr-un depozit bare față de unul obișnuit? Ce diferență vezi între `c1` și `c2` în `objects` și în coloana a doua (numărul de legături) a lui `ls -l`? De ce un server ține de obicei depozite bare? Vreau să judec dacă o echipă mică ar putea folosi un director partajat în rețea (NFS) ca server Git. Pune-mi întrebări despre viteză, acces și riscuri și verifică-mi concluzia.

Lucrez la exercițiul „Servește un depozit cu git daemon” din capitolul „4. Git on the Server”, la Pro Git. Enunțul: Continuă în directorul `server-local` de la exercițiul anterior. 1. Marchează depozitul ca exportabil și pornește daemonul (rămâne deschis în acest terminal): ```bash touch proiect.git/git-daemon-export-ok git daemon --reuseaddr --base-path=$PWD --port=9419 $PWD ``` 2. Într-un **al doilea terminal**, în același director: ```bash git ls-remote git://localhost:9419/proiect.git git clone git://localhost:9419/proiect.git c3 cd c3 echo z > z.txt; git add .; git commit -m "z" git push ``` 3. Oprește daemonul cu Ctrl+C. Ce se întâmplă dacă ștergi `git-daemon-export-ok` și repornești daemonul? Portul implicit e 9418; aici folosim 9419 ca să nu intrăm în conflict cu alt serviciu. Întreabă-mă ce am observat când am încercat push-ul și de ce cred că protocolul Git nu are autentificare. Dă-mi indicii despre situațiile în care un astfel de server e totuși util, fără să-mi dai lista gata făcută.

Lucrez la exercițiul „Servește un depozit cu git daemon” din capitolul „4. Git on the Server”, la Pro Git. Enunțul: Continuă în directorul `server-local` de la exercițiul anterior. 1. Marchează depozitul ca exportabil și pornește daemonul (rămâne deschis în acest terminal): ```bash touch proiect.git/git-daemon-export-ok git daemon --reuseaddr --base-path=$PWD --port=9419 $PWD ``` 2. Într-un **al doilea terminal**, în același director: ```bash git ls-remote git://localhost:9419/proiect.git git clone git://localhost:9419/proiect.git c3 cd c3 echo z > z.txt; git add .; git commit -m "z" git push ``` 3. Oprește daemonul cu Ctrl+C. Ce se întâmplă dacă ștergi `git-daemon-export-ok` și repornești daemonul? Portul implicit e 9418; aici folosim 9419 ca să nu intrăm în conflict cu alt serviciu. Îți lipesc eroarea primită la `git clone git://localhost:9419/...`. Pune-mi întrebări de verificare (rulează daemonul? portul? base-path? fișierul de export?) și lasă-mă să găsesc singur cauza.

Lucrez la exercițiul „Clonează prin HTTP „prost” de pe un server static” din capitolul „4. Git on the Server”, la Pro Git. Enunțul: Ai nevoie de Python 3 (pentru un server web static). Continuă în `server-local`. 1. Pregătește depozitul pentru HTTP-ul „prost” (dumb): ```bash cd proiect.git git update-server-info mv hooks/post-update.sample hooks/post-update ls info cat info/refs cd .. ``` 2. Pornește un server web static în acest director (rămâne deschis): `python3 -m http.server 8765`. 3. În al doilea terminal: `git clone http://localhost:8765/proiect.git c4`, apoi `git log --oneline` în `c4`. 4. Uită-te în primul terminal la cererile GET făcute de Git. Oprește serverul cu Ctrl+C. Răspunde: de ce e nevoie de `git update-server-info` și ce rol are hook-ul `post-update`? Prin ce diferă de Smart HTTP? Îți lipesc liniile GET din jurnalul serverului Python. Întreabă-mă ce cred că cere Git la fiecare pas și de ce în ordinea aceea; corectează-mă cu indicii din secțiunea despre protocoalele de transfer.

Lucrez la exercițiul „Clonează prin HTTP „prost” de pe un server static” din capitolul „4. Git on the Server”, la Pro Git. Enunțul: Ai nevoie de Python 3 (pentru un server web static). Continuă în `server-local`. 1. Pregătește depozitul pentru HTTP-ul „prost” (dumb): ```bash cd proiect.git git update-server-info mv hooks/post-update.sample hooks/post-update ls info cat info/refs cd .. ``` 2. Pornește un server web static în acest director (rămâne deschis): `python3 -m http.server 8765`. 3. În al doilea terminal: `git clone http://localhost:8765/proiect.git c4`, apoi `git log --oneline` în `c4`. 4. Uită-te în primul terminal la cererile GET făcute de Git. Oprește serverul cu Ctrl+C. Răspunde: de ce e nevoie de `git update-server-info` și ce rol are hook-ul `post-update`? Prin ce diferă de Smart HTTP? Pune-mi întrebări ca să construiesc singur o comparație între HTTP „prost” și Smart HTTP (ce rulează pe server, push, eficiență). Verifică-mi comparația și spune-mi doar ce lipsește.

Lucrez la exercițiul „Generează o pereche de chei SSH de test” din capitolul „4. Git on the Server”, la Pro Git. Enunțul: Lucrezi într-un director de test, ca să nu atingi cheile tale reale din `~/.ssh`. ```bash mkdir chei-test && cd chei-test ssh-keygen -t ed25519 -C "student@test" -f ./cheie_test -N "" ls -l cat cheie_test.pub ssh-keygen -lf cheie_test.pub ``` Răspunde: 1. Care dintre cele două fișiere se trimite administratorului serverului (sau se pune pe GitHub/GitLab) și care nu trebuie să plece niciodată de pe calculatorul tău? 2. În ce fișier de pe server ajunge cheia publică pentru utilizatorul `git` (vezi „Setting Up the Server”)? 3. De ce e SSH o alegere bună pentru push, comparat cu protocolul Git? La final poți șterge directorul `chei-test`. Pentru o cheie reală, rulează comanda fără `-f` și pune… Întreabă-mă ce fișier aș trimite unui administrator și de ce, apoi ce s-ar întâmpla dacă aș trimite greșit cheia privată. Corectează-mă cu indicii, fără să-mi explici tu de la început criptografia cu chei publice.

Lucrez la exercițiul „Generează o pereche de chei SSH de test” din capitolul „4. Git on the Server”, la Pro Git. Enunțul: Lucrezi într-un director de test, ca să nu atingi cheile tale reale din `~/.ssh`. ```bash mkdir chei-test && cd chei-test ssh-keygen -t ed25519 -C "student@test" -f ./cheie_test -N "" ls -l cat cheie_test.pub ssh-keygen -lf cheie_test.pub ``` Răspunde: 1. Care dintre cele două fișiere se trimite administratorului serverului (sau se pune pe GitHub/GitLab) și care nu trebuie să plece niciodată de pe calculatorul tău? 2. În ce fișier de pe server ajunge cheia publică pentru utilizatorul `git` (vezi „Setting Up the Server”)? 3. De ce e SSH o alegere bună pentru push, comparat cu protocolul Git? La final poți șterge directorul `chei-test`. Pentru o cheie reală, rulează comanda fără `-f` și pune… Vreau să descriu pașii pentru a da acces prin SSH unui coleg la un server Git (utilizatorul git, authorized_keys, depozit bare). Lasă-mă să scriu eu pașii, apoi verifică-i după carte și spune-mi ce am omis.

Lucrez la exercițiul „Ce protocol și ce server alegi?” din capitolul „4. Git on the Server”, la Pro Git. Enunțul: Pentru fiecare situație alege protocolul (local, HTTP, SSH, Git) și, unde e cazul, tipul de găzduire (server propriu cu `git daemon`/GitWeb, GitLab instalat, serviciu găzduit). Justifică în 2–3 propoziții. 1. Trei colegi de laborator care au toți acces la același director partajat de rețea. 2. Un proiect open-source care vrea clonare anonimă rapidă, iar push doar pentru mentenanți. 3. O firmă cu 40 de programatori, cod confidențial, care vrea interfață web, issues și permisiuni pe grupuri, dar nu vrea ca codul să plece pe un server extern. 4. Un student care vrea să-și publice tema și să o arate profesorului, fără să administreze un server. 5. O rețea de firmă în care doar portul 443 e… Îți scriu alegerile mele pentru cele 5 scenarii. Pentru fiecare, pune-mi o întrebare-capcană (securitate, firewall, acces anonim, administrare) care să-mi verifice argumentul. Nu-mi spune răspunsul tău până nu-mi apăr alegerea.

Lucrez la exercițiul „Ce protocol și ce server alegi?” din capitolul „4. Git on the Server”, la Pro Git. Enunțul: Pentru fiecare situație alege protocolul (local, HTTP, SSH, Git) și, unde e cazul, tipul de găzduire (server propriu cu `git daemon`/GitWeb, GitLab instalat, serviciu găzduit). Justifică în 2–3 propoziții. 1. Trei colegi de laborator care au toți acces la același director partajat de rețea. 2. Un proiect open-source care vrea clonare anonimă rapidă, iar push doar pentru mentenanți. 3. O firmă cu 40 de programatori, cod confidențial, care vrea interfață web, issues și permisiuni pe grupuri, dar nu vrea ca codul să plece pe un server extern. 4. Un student care vrea să-și publice tema și să o arate profesorului, fără să administreze un server. 5. O rețea de firmă în care doar portul 443 e… Ajută-mă să construiesc singur un tabel cu cele patru protocoale (local, HTTP, SSH, Git) și coloanele: autentificare, acces anonim, viteză, configurare. Întreabă-mă celulă cu celulă și dă-mi indicii unde greșesc.

Lucrez la exercițiul „Contribuție prin patch-uri, ca pe o listă de e-mail” din capitolul „5. Distributed Git”, la Pro Git. Enunțul: ```bash mkdir patchuri && cd patchuri git init proiect && cd proiect echo "# Lib" > README.md; git add .; git commit -m "Inițial"; cd .. git clone proiect contrib && cd contrib git config user.name "Dan Ionescu"; git config user.email dan@example.com git switch -c docs echo "Instalare: make" >> README.md; git commit -am "Adaug instrucțiuni de instalare" echo "Licență: MIT" > LICENSE; git add .; git commit -m "Adaug licența" git format-patch origin/main -o ../patch ls ../patch head -5 ../patch/0001-* cd ../proiect git switch -c dan-docs git am ../patch/*.patch git log --format="%h | autor: %an | committer: %cn | %s" ``` Răspunde: de ce patch-urile generate cu `format-patch` sunt mai bune… Întreabă-mă ce am văzut în coloanele autor și committer după `git am` și de ce cred că Git le ține separat. Dă-mi indicii dacă nu-mi dau seama în ce flux de lucru contează diferența.

Lucrez la exercițiul „Contribuție prin patch-uri, ca pe o listă de e-mail” din capitolul „5. Distributed Git”, la Pro Git. Enunțul: ```bash mkdir patchuri && cd patchuri git init proiect && cd proiect echo "# Lib" > README.md; git add .; git commit -m "Inițial"; cd .. git clone proiect contrib && cd contrib git config user.name "Dan Ionescu"; git config user.email dan@example.com git switch -c docs echo "Instalare: make" >> README.md; git commit -am "Adaug instrucțiuni de instalare" echo "Licență: MIT" > LICENSE; git add .; git commit -m "Adaug licența" git format-patch origin/main -o ../patch ls ../patch head -5 ../patch/0001-* cd ../proiect git switch -c dan-docs git am ../patch/*.patch git log --format="%h | autor: %an | committer: %cn | %s" ``` Răspunde: de ce patch-urile generate cu `format-patch` sunt mai bune… Dacă `git am` s-ar opri cu un conflict, ce aș face? Nu-mi da secvența completă; pune-mi întrebări despre ce opțiuni are `git am` (de ex. pentru a continua, a sări sau a renunța) și lasă-mă să le găsesc în `git am --help`.

Lucrez la exercițiul „Fluxul cu integration manager, cu fork-uri locale” din capitolul „5. Distributed Git”, la Pro Git. Enunțul: Simulezi un depozit „oficial”, fork-ul unui contribuitor și mentenantul. ```bash mkdir integrare && cd integrare git init proiect && cd proiect echo "# Lib" > README.md; git add .; git commit -m "Inițial"; cd .. git clone --bare proiect oficial.git # depozitul public oficial git clone --bare oficial.git fork.git # fork-ul public al lui Dan git clone fork.git dan && cd dan git remote add upstream ../oficial.git git switch -c docs echo doc > DOC.md; git add .; git commit -m "Adaug DOC.md" git push -u origin docs git fetch upstream git request-pull upstream/main ../fork.git docs ``` Acum ești mentenantul, în `proiect` (copia ta de lucru): 1. Adaugă fork-ul ca remote (`git remote add dan… Vreau să desenez cele trei depozite (oficial, fork, copia mentenantului) și săgețile de push/fetch. Întreabă-mă, pentru fiecare pas al exercițiului, cine scrie unde și corectează-mă cu indicii.

Lucrez la exercițiul „Fluxul cu integration manager, cu fork-uri locale” din capitolul „5. Distributed Git”, la Pro Git. Enunțul: Simulezi un depozit „oficial”, fork-ul unui contribuitor și mentenantul. ```bash mkdir integrare && cd integrare git init proiect && cd proiect echo "# Lib" > README.md; git add .; git commit -m "Inițial"; cd .. git clone --bare proiect oficial.git # depozitul public oficial git clone --bare oficial.git fork.git # fork-ul public al lui Dan git clone fork.git dan && cd dan git remote add upstream ../oficial.git git switch -c docs echo doc > DOC.md; git add .; git commit -m "Adaug DOC.md" git push -u origin docs git fetch upstream git request-pull upstream/main ../fork.git docs ``` Acum ești mentenantul, în `proiect` (copia ta de lucru): 1. Adaugă fork-ul ca remote (`git remote add dan… Pune-mi întrebări care să mă ducă singur la diferența dintre `git log main..dan/docs` și `git diff main...dan/docs` și la de ce mentenantul vrea diferența față de strămoșul comun. Verifică-mi explicația.

Lucrez la exercițiul „Commituri curate - spații și mesaje bune” din capitolul „5. Distributed Git”, la Pro Git. Enunțul: 1. Într-un depozit de test, adaugă o linie cu spații la final și verifică-o înainte de commit: ```bash echo "linie cu spații la final " >> README.md git diff --check ``` Corectează linia, apoi rulează din nou `git diff --check`. 2. Scrie un mesaj de commit după regulile din carte, cu editorul (`git commit -a`, fără `-m`): un rând de rezumat de cel mult ~50 de caractere, la imperativ, un rând gol, apoi un paragraf care explică *de ce*. 3. Rescrie mai bine aceste mesaje reale (doar pe hârtie): „fix”, „am modificat niste chestii la login si am sters fisierul vechi si am rezolvat si bugul de la parola”, „WIP!!!”. 4. Verifică cum arată mesajul tău cu `git log -1` și `git log --oneline -1`. Îți lipesc cum am rescris cele trei mesaje de commit. Verifică-le după regulile din Pro Git (lungime, imperativ, rând gol, de ce/nu ce) și pune-mi întrebări acolo unde nu respect o regulă, fără să le rescrii tu.

Lucrez la exercițiul „Commituri curate - spații și mesaje bune” din capitolul „5. Distributed Git”, la Pro Git. Enunțul: 1. Într-un depozit de test, adaugă o linie cu spații la final și verifică-o înainte de commit: ```bash echo "linie cu spații la final " >> README.md git diff --check ``` Corectează linia, apoi rulează din nou `git diff --check`. 2. Scrie un mesaj de commit după regulile din carte, cu editorul (`git commit -a`, fără `-m`): un rând de rezumat de cel mult ~50 de caractere, la imperativ, un rând gol, apoi un paragraf care explică *de ce*. 3. Rescrie mai bine aceste mesaje reale (doar pe hârtie): „fix”, „am modificat niste chestii la login si am sters fisierul vechi si am rezolvat si bugul de la parola”, „WIP!!!”. 4. Verifică cum arată mesajul tău cu `git log -1` și `git log --oneline -1`. Întreabă-mă ce modificări am în directorul de lucru și ajută-mă cu întrebări să decid cum le împart în commituri logice. Dă-mi un indiciu despre `git add -p` dacă am mai multe schimbări în același fișier.

Lucrez la exercițiul „Integrare cu merge --squash și cherry-pick” din capitolul „5. Distributed Git”, la Pro Git. Enunțul: Folosește depozitul `patchuri/proiect` din exercițiul cu patch-uri (are ramura `dan-docs` cu două commituri). 1. Integrează toată ramura ca **un singur** commit: ```bash git switch main git merge --squash dan-docs git status -s git commit -m "Documentație (squash de la Dan)" git log --oneline --graph --all ``` 2. Preia un singur commit de pe altă ramură: ```bash git switch -c remediere main~1 echo fix > fix.txt; git add .; git commit -m "Fix important" git switch main git cherry-pick remediere git log --oneline -3 ``` Răspunde: de ce, după squash, Git nu consideră ramura `dan-docs` „integrată” (`git branch --merged`)? Ce hash are commitul preluat cu cherry-pick față de cel original? Pune-mi trei situații de mentenant (o ramură cu 15 commituri de tipul „typo”, un singur bugfix util dintr-o ramură abandonată, o funcționalitate mare cu istorie curată) și lasă-mă să aleg metoda. Verifică-mi alegerea.

Lucrez la exercițiul „Integrare cu merge --squash și cherry-pick” din capitolul „5. Distributed Git”, la Pro Git. Enunțul: Folosește depozitul `patchuri/proiect` din exercițiul cu patch-uri (are ramura `dan-docs` cu două commituri). 1. Integrează toată ramura ca **un singur** commit: ```bash git switch main git merge --squash dan-docs git status -s git commit -m "Documentație (squash de la Dan)" git log --oneline --graph --all ``` 2. Preia un singur commit de pe altă ramură: ```bash git switch -c remediere main~1 echo fix > fix.txt; git add .; git commit -m "Fix important" git switch main git cherry-pick remediere git log --oneline -3 ``` Răspunde: de ce, după squash, Git nu consideră ramura `dan-docs` „integrată” (`git branch --merged`)? Ce hash are commitul preluat cu cherry-pick față de cel original? Întreabă-mă ce conține un obiect commit și lasă-mă să deduc singur de ce cherry-pick produce un hash nou. Dă-mi indicii doar dacă mă blochez.

Lucrez la exercițiul „Pregătește o lansare - describe, shortlog, archive” din capitolul „5. Distributed Git”, la Pro Git. Enunțul: Într-un depozit de test cu un tag adnotat `v1.0` și cel puțin două commituri după el (de exemplu `patchuri/proiect` după exercițiul cu squash și cherry-pick, dacă ai pus tagul pe commitul „Inițial”: `git tag -a v1.0 -m "v1.0" `): ```bash git describe git shortlog --no-merges main --not v1.0 git archive main --prefix=lib/ --format=tar.gz > ../lib.tar.gz tar tzf ../lib.tar.gz ``` Apoi creează tagul noii versiuni (`git tag -a v1.1 -m "Versiunea 1.1"`) și rulează din nou `git describe`. Răspunde: ce înseamnă fiecare parte din rezultatul lui `git describe`? La ce i-ar folosi unui mentenant rezultatul lui `shortlog` când anunță o versiune? Îți lipesc ce afișează `git describe`. Întreabă-mă ce cred că înseamnă fiecare bucată, separată prin cratime, și corectează-mă cu indicii. Apoi întreabă-mă de ce comanda cere un tag adnotat.

Lucrez la exercițiul „Pregătește o lansare - describe, shortlog, archive” din capitolul „5. Distributed Git”, la Pro Git. Enunțul: Într-un depozit de test cu un tag adnotat `v1.0` și cel puțin două commituri după el (de exemplu `patchuri/proiect` după exercițiul cu squash și cherry-pick, dacă ai pus tagul pe commitul „Inițial”: `git tag -a v1.0 -m "v1.0" `): ```bash git describe git shortlog --no-merges main --not v1.0 git archive main --prefix=lib/ --format=tar.gz > ../lib.tar.gz tar tzf ../lib.tar.gz ``` Apoi creează tagul noii versiuni (`git tag -a v1.1 -m "Versiunea 1.1"`) și rulează din nou `git describe`. Răspunde: ce înseamnă fiecare parte din rezultatul lui `git describe`? La ce i-ar folosi unui mentenant rezultatul lui `shortlog` când anunță o versiune? Vreau să scriu un scurt anunț pentru versiunea nouă folosind `git shortlog`. Lasă-mă să-l scriu eu și verifică-mi dacă am folosit corect intervalul de commituri; dă-mi sugestii, nu textul gata făcut.

Lucrez la exercițiul „Un README în GitHub Flavored Markdown” din capitolul „6. GitHub”, la Pro Git. Enunțul: Scrie un `README.md` pentru un proiect imaginar care să conțină: 1. un titlu și o descriere scurtă; 2. o listă de sarcini cu căsuțe (`- [x] gata`, `- [ ] de făcut`); 3. un bloc de cod cu evidențiere de limbaj (de ex. ```` ```bash ````); 4. un tabel cu cel puțin două coloane; 5. o trimitere la un issue (`#1`), o mențiune (`@utilizator`) și un emoji (`:tada:`). Previzualizează-l fără cont: în VS Code (Markdown Preview) sau în orice editor cu previzualizare Markdown. **Dacă ai cont GitHub:** deschide un issue nou într-un depozit propriu și lipește textul în tabul *Preview* (nu e nevoie să-l trimiți) sau pune fișierul într-un depozit al tău. Notează ce elemente arată la fel în ambele locuri și… Îți lipesc README-ul meu. Verifică dacă folosesc corect elementele GFM cerute (task list, cod, tabel, trimiteri, emoji) și, unde greșesc, pune-mi o întrebare sau dă-mi un indiciu, fără să-mi rescrii fișierul.

Lucrez la exercițiul „Un README în GitHub Flavored Markdown” din capitolul „6. GitHub”, la Pro Git. Enunțul: Scrie un `README.md` pentru un proiect imaginar care să conțină: 1. un titlu și o descriere scurtă; 2. o listă de sarcini cu căsuțe (`- [x] gata`, `- [ ] de făcut`); 3. un bloc de cod cu evidențiere de limbaj (de ex. ```` ```bash ````); 4. un tabel cu cel puțin două coloane; 5. o trimitere la un issue (`#1`), o mențiune (`@utilizator`) și un emoji (`:tada:`). Previzualizează-l fără cont: în VS Code (Markdown Preview) sau în orice editor cu previzualizare Markdown. **Dacă ai cont GitHub:** deschide un issue nou într-un depozit propriu și lipește textul în tabul *Preview* (nu e nevoie să-l trimiți) sau pune fișierul într-un depozit al tău. Notează ce elemente arată la fel în ambele locuri și… Întreabă-mă ce elemente din README-ul meu cred că sunt Markdown standard și care sunt extensii GitHub, apoi corectează-mă cu indicii despre ce face GitHub cu trimiterile la issues și mențiuni.

Lucrez la exercițiul „Pull request-urile ca referințe, fără cont” din capitolul „6. GitHub”, la Pro Git. Enunțul: Ai nevoie doar de internet (depozitul public `octocat/Hello-World` e foarte mic). ```bash git clone https://github.com/octocat/Hello-World hw && cd hw git ls-remote origin | head git ls-remote origin | grep -c refs/pull git ls-remote origin 'refs/pull/1/*' git fetch origin refs/pull/1/head:pr-1 git log --oneline --graph --all git diff master...pr-1 ``` Apoi adaugă un refspec ca să aduci automat toate PR-urile ca ramuri de remote: ```bash git config --add remote.origin.fetch '+refs/pull/*/head:refs/remotes/origin/pr/*' git fetch git branch -r | head ``` Răspunde: ce diferență e între `refs/pull/1/head` și `refs/pull/1/merge`? De ce nu apar aceste referințe la un `git clone` obișnuit? Întreabă-mă ce înseamnă fiecare parte din `+refs/pull/*/head:refs/remotes/origin/pr/*` (plusul, sursa, destinația, asteriscul) și corectează-mă cu indicii până pot explica singur ce face `git fetch` cu el.

Lucrez la exercițiul „Pull request-urile ca referințe, fără cont” din capitolul „6. GitHub”, la Pro Git. Enunțul: Ai nevoie doar de internet (depozitul public `octocat/Hello-World` e foarte mic). ```bash git clone https://github.com/octocat/Hello-World hw && cd hw git ls-remote origin | head git ls-remote origin | grep -c refs/pull git ls-remote origin 'refs/pull/1/*' git fetch origin refs/pull/1/head:pr-1 git log --oneline --graph --all git diff master...pr-1 ``` Apoi adaugă un refspec ca să aduci automat toate PR-urile ca ramuri de remote: ```bash git config --add remote.origin.fetch '+refs/pull/*/head:refs/remotes/origin/pr/*' git fetch git branch -r | head ``` Răspunde: ce diferență e între `refs/pull/1/head` și `refs/pull/1/merge`? De ce nu apar aceste referințe la un `git clone` obișnuit? Vreau să știu cum aș testa local un pull request înainte să-l aprob. Lasă-mă să propun pașii (fetch, ramură, teste, diff) și verifică-i; spune-mi ce am omis, fără să-mi dai lista completă.

Lucrez la exercițiul „Interoghează API-ul GitHub fără autentificare” din capitolul „6. GitHub”, la Pro Git. Enunțul: Ai nevoie de `curl` și internet; nu e nevoie de cont. ```bash curl https://api.github.com/users/octocat curl -s https://api.github.com/repos/progit/progit2 | grep -E '"(full_name|default_branch|stargazers_count|forks_count)"' curl -s 'https://api.github.com/repos/progit/progit2/pulls?state=closed&per;_page=2' | grep -E '"(number|title)"' curl -sI https://api.github.com/users/octocat | grep -i '^x-ratelimit' ``` 1. Ce format au răspunsurile? Ce câmpuri găsești pentru un utilizator? 2. Câte cereri pe oră îți permite API-ul fără autentificare și câte mai ai? 3. Citește în carte cum s-ar adăuga un comentariu la un issue prin API: ce metodă HTTP și ce tip de autentificare ar fi necesare? **Dacă… Îți lipesc o bucată din răspunsul JSON pentru un depozit. Întreabă-mă ce cred că înseamnă câteva câmpuri și cum aș extrage doar unul dintre ele în linia de comandă; dă-mi indicii, nu comanda gata făcută.

Lucrez la exercițiul „Interoghează API-ul GitHub fără autentificare” din capitolul „6. GitHub”, la Pro Git. Enunțul: Ai nevoie de `curl` și internet; nu e nevoie de cont. ```bash curl https://api.github.com/users/octocat curl -s https://api.github.com/repos/progit/progit2 | grep -E '"(full_name|default_branch|stargazers_count|forks_count)"' curl -s 'https://api.github.com/repos/progit/progit2/pulls?state=closed&per;_page=2' | grep -E '"(number|title)"' curl -sI https://api.github.com/users/octocat | grep -i '^x-ratelimit' ``` 1. Ce format au răspunsurile? Ce câmpuri găsești pentru un utilizator? 2. Câte cereri pe oră îți permite API-ul fără autentificare și câte mai ai? 3. Citește în carte cum s-ar adăuga un comentariu la un issue prin API: ce metodă HTTP și ce tip de autentificare ar fi necesare? **Dacă… Vreau să scriu un script care afișează titlurile ultimelor 5 pull request-uri închise ale unui depozit. Lasă-mă să-l scriu eu, apoi verifică-l și spune-mi ce trebuie corectat, fără să-l rescrii.

Lucrez la exercițiul „Parcurge GitHub Flow (cu cont sau simulat local)” din capitolul „6. GitHub”, la Pro Git. Enunțul: **Dacă ai deja cont GitHub** (nu-ți crea unul doar pentru exercițiu dacă nu vrei): 1. Verifică în setări că ai activat autentificarea în doi pași și adaugă o cheie SSH publică (vezi capitolul 4). 2. Creează un depozit nou al tău, cu un README, și clonează-l. 3. Deschide un issue „Adaugă licența” (va primi numărul `#1`). 4. Local: `git switch -c licenta`, adaugă un fișier `LICENSE`, commit cu mesajul „Adaug licența, fixes #1”, `git push -u origin licenta`. 5. Deschide un pull request din `licenta` în `main`, lasă-ți un comentariu pe o linie din diff, apoi fă încă un commit și push pe aceeași ramură. Fă merge din interfață. 6. Local: `git switch main && git pull`, apoi `git branch -d… Înainte să încep, întreabă-mă ce cred că se întâmplă cu PR-ul când fac push pe aceeași ramură după ce l-am deschis și ce face „fixes #1”. Nu-mi confirma nimic; după ce termin, verifică-mi observațiile.

Lucrez la exercițiul „Parcurge GitHub Flow (cu cont sau simulat local)” din capitolul „6. GitHub”, la Pro Git. Enunțul: **Dacă ai deja cont GitHub** (nu-ți crea unul doar pentru exercițiu dacă nu vrei): 1. Verifică în setări că ai activat autentificarea în doi pași și adaugă o cheie SSH publică (vezi capitolul 4). 2. Creează un depozit nou al tău, cu un README, și clonează-l. 3. Deschide un issue „Adaugă licența” (va primi numărul `#1`). 4. Local: `git switch -c licenta`, adaugă un fișier `LICENSE`, commit cu mesajul „Adaug licența, fixes #1”, `git push -u origin licenta`. 5. Deschide un pull request din `licenta` în `main`, lasă-ți un comentariu pe o linie din diff, apoi fă încă un commit și push pe aceeași ramură. Fă merge din interfață. 6. Local: `git switch main && git pull`, apoi `git branch -d… Pune-mi întrebări despre ce protejează autentificarea în doi pași și ce rol are cheia SSH față de parolă, până pot explica singur de ce sunt recomandate amândouă. Corectează-mă cu indicii.

Lucrez la exercițiul „Fork, colaborator sau organizație?” din capitolul „6. GitHub”, la Pro Git. Enunțul: Răspunde pe scurt, folosind capitolul despre GitHub: 1. Vrei să repari o greșeală de tipar în documentația unui proiect open-source la care nu ai drept de scriere. Ce pași urmezi pe GitHub? 2. Ce diferență este între a fi *colaborator* la un depozit și a lucra dintr-un *fork*? 3. Un PR poate fi deschis între două ramuri ale aceluiași depozit? Când ar avea sens? 4. Ce aduce o *organizație* față de un cont personal (proprietari, echipe, permisiuni)? 5. De ce un pull request e mai mult decât o cerere de merge (discuție, comentarii pe linii, verificări automate)? Îți scriu răspunsurile mele la cele 5 întrebări. Verifică-le pe rând și, unde sunt incomplete, pune-mi o întrebare care să mă facă să le completez singur. Nu-mi da răspunsul corect direct.

Lucrez la exercițiul „Fork, colaborator sau organizație?” din capitolul „6. GitHub”, la Pro Git. Enunțul: Răspunde pe scurt, folosind capitolul despre GitHub: 1. Vrei să repari o greșeală de tipar în documentația unui proiect open-source la care nu ai drept de scriere. Ce pași urmezi pe GitHub? 2. Ce diferență este între a fi *colaborator* la un depozit și a lucra dintr-un *fork*? 3. Un PR poate fi deschis între două ramuri ale aceluiași depozit? Când ar avea sens? 4. Ce aduce o *organizație* față de un cont personal (proprietari, echipe, permisiuni)? 5. De ce un pull request e mai mult decât o cerere de merge (discuție, comentarii pe linii, verificări automate)? Joacă rolul unui coleg care îmi descrie situații de pe GitHub (contribuție externă, echipă internă, o firmă cu mai multe echipe). Lasă-mă să-i recomand fork, colaborare sau organizație și întreabă-mă de ce.

Lucrez la exercițiul „HEAD^, HEAD~2, .. și ... pe un istoric cu merge” din capitolul „7. Git Tools”, la Pro Git. Enunțul: ```bash git init revizii && cd revizii for i in 1 2 3; do echo $i > m$i.txt; git add .; git commit -m "M$i"; done git switch -c topic HEAD~1 for i in 1 2; do echo $i > t$i.txt; git add .; git commit -m "T$i"; done git switch main git log --oneline main..topic # (a) git log --oneline topic..main # (b) git log --oneline --left-right main...topic # (c) git merge --no-edit topic git log --oneline --graph ``` Acum, **înainte să rulezi**, scrie ce commit crezi că indică fiecare expresie, apoi verifică cu `git log --oneline -1 `: `HEAD^`, `HEAD^2`, `HEAD~2`, `HEAD^2~1`, `HEAD@{1}`. La final: `git reflog | head -5` și `git rev-parse --short HEAD~2`. Îți scriu ce cred că indică fiecare dintre cele cinci expresii. Verifică-mi predicțiile și, la cele greșite, întreabă-mă ce înseamnă „primul părinte” într-un commit de merge, fără să-mi dai răspunsul.

Lucrez la exercițiul „HEAD^, HEAD~2, .. și ... pe un istoric cu merge” din capitolul „7. Git Tools”, la Pro Git. Enunțul: ```bash git init revizii && cd revizii for i in 1 2 3; do echo $i > m$i.txt; git add .; git commit -m "M$i"; done git switch -c topic HEAD~1 for i in 1 2; do echo $i > t$i.txt; git add .; git commit -m "T$i"; done git switch main git log --oneline main..topic # (a) git log --oneline topic..main # (b) git log --oneline --left-right main...topic # (c) git merge --no-edit topic git log --oneline --graph ``` Acum, **înainte să rulezi**, scrie ce commit crezi că indică fiecare expresie, apoi verifică cu `git log --oneline -1 `: `HEAD^`, `HEAD^2`, `HEAD~2`, `HEAD^2~1`, `HEAD@{1}`. La final: `git reflog | head -5` și `git rev-parse --short HEAD~2`. Pune-mi întrebări cu diagrame mici (desenate cu text) ca să ajung singur să explic diferența dintre `A..B`, `B..A` și `A...B`. Corectează-mă cu indicii.

Lucrez la exercițiul „Pune deoparte lucrul cu stash și curăță cu clean” din capitolul „7. Git Tools”, la Pro Git. Enunțul: ```bash git init sertar && cd sertar echo a > index.html; echo b > lib.js; printf '*.o\n' > .gitignore git add .; git commit -m "init" echo a2 >> index.html; git add index.html echo b2 >> lib.js echo nou > nou.txt git status -s # (1) git stash git status -s # (2) git stash list git stash apply --index git status -s # (3) git stash drop git stash -u git status -s # (4) git stash pop --index ``` Apoi curățenie (folosește **întâi** `-n`, care doar arată ce s-ar șterge): ```bash git stash -u mkdir tmp; touch tmp/x.txt y.o z.txt git clean -n git clean -n -d git clean -n -d -x git clean -f -d git status -s --ignored git stash pop --index ``` Înainte de pașii (2) și (4), întreabă-mă ce fișiere cred că vor dispărea din `git status -s` și de ce. Verifică-mi predicțiile după ce rulez și dă-mi indicii despre opțiunile `-u` și `--index`.

Lucrez la exercițiul „Pune deoparte lucrul cu stash și curăță cu clean” din capitolul „7. Git Tools”, la Pro Git. Enunțul: ```bash git init sertar && cd sertar echo a > index.html; echo b > lib.js; printf '*.o\n' > .gitignore git add .; git commit -m "init" echo a2 >> index.html; git add index.html echo b2 >> lib.js echo nou > nou.txt git status -s # (1) git stash git status -s # (2) git stash list git stash apply --index git status -s # (3) git stash drop git stash -u git status -s # (4) git stash pop --index ``` Apoi curățenie (folosește **întâi** `-n`, care doar arată ce s-ar șterge): ```bash git stash -u mkdir tmp; touch tmp/x.txt y.o z.txt git clean -n git clean -n -d git clean -n -d -x git clean -f -d git status -s --ignored git stash pop --index ``` Ajută-mă să-mi fac o regulă de lucru sigură cu `git clean`. Pune-mi întrebări despre ce șterge fiecare opțiune (`-n`, `-d`, `-x`, `-f`) și lasă-mă să formulez eu regula; verific-o apoi.

Lucrez la exercițiul „Cele trei moduri ale lui git reset” din capitolul „7. Git Tools”, la Pro Git. Enunțul: ```bash git init reset3 && cd reset3 echo v1 > file.txt; git add .; git commit -m v1 echo v2 > file.txt; git commit -am v2 echo v3 > file.txt; git commit -am v3 ``` Pentru fiecare pas, notează **înainte** ce crezi că vor arăta `git log --oneline`, `git status -s` și `cat file.txt`: 1. `git reset --soft HEAD~1`, apoi verifică; refă commitul: `git commit -m "v3 din nou"`. 2. `git reset HEAD~1` (mixed, implicit), verifică; refă: `git commit -am "v3 iar"`. 3. `git reset --hard HEAD~1`, verifică. 4. Recuperează commitul „pierdut”: `git reflog | head -4`, apoi `git reset --hard HEAD@{1}`. 5. Comasează ultimele două commituri într-unul: `git reset --soft HEAD~2` și `git commit -m "v2+v3… Vreau să fac un tabel cu cele trei moduri de reset și cei trei arbori. Întreabă-mă pentru fiecare celulă ce cred că se schimbă, pe baza a ce am văzut în terminal, și corectează-mă cu indicii.

Lucrez la exercițiul „Cele trei moduri ale lui git reset” din capitolul „7. Git Tools”, la Pro Git. Enunțul: ```bash git init reset3 && cd reset3 echo v1 > file.txt; git add .; git commit -m v1 echo v2 > file.txt; git commit -am v2 echo v3 > file.txt; git commit -am v3 ``` Pentru fiecare pas, notează **înainte** ce crezi că vor arăta `git log --oneline`, `git status -s` și `cat file.txt`: 1. `git reset --soft HEAD~1`, apoi verifică; refă commitul: `git commit -m "v3 din nou"`. 2. `git reset HEAD~1` (mixed, implicit), verifică; refă: `git commit -am "v3 iar"`. 3. `git reset --hard HEAD~1`, verifică. 4. Recuperează commitul „pierdut”: `git reflog | head -4`, apoi `git reset --hard HEAD@{1}`. 5. Comasează ultimele două commituri într-unul: `git reset --soft HEAD~2` și `git commit -m "v2+v3… Am făcut `git reset --hard` și cred că am pierdut munca. Nu-mi da comanda direct; întreabă-mă ce am încercat și ghidează-mă spre reflog cu întrebări. Spune-mi și ce NU se poate recupera (modificările necomise).

Lucrez la exercițiul „Curăță istoria cu git rebase -i” din capitolul „7. Git Tools”, la Pro Git. Enunțul: ```bash git init curatenie && cd curatenie echo base > a.txt; git add .; git commit -m "Inițial" echo 1 > f.txt; git add .; git commit -m "Adaug funcția" echo 2 >> f.txt; git commit -am "typo" echo 3 >> f.txt; git commit -am "încă un typo" echo d > doc.txt; git add .; git commit -m "Documentaţie" git log --oneline git rebase -i HEAD~4 ``` În editor apare lista celor 4 commituri, **de la cel mai vechi la cel mai nou**. Scopul: - „typo” și „încă un typo” se contopesc în „Adaug funcția”, fără să le păstrezi mesajele; - mesajul ultimului commit se corectează în „Documentație pentru funcție” (cu ț corect). Salvează și închide editorul; la cererea de mesaj nou, scrie-l și salvează. **Regula de… Îți lipesc lista pe care o văd în editor. Lasă-mă să propun ce cuvânt pun pe fiecare linie, apoi verifică-mi propunerea și dă-mi indicii despre diferența dintre `squash` și `fixup`, fără să-mi scrii lista finală.

Lucrez la exercițiul „Curăță istoria cu git rebase -i” din capitolul „7. Git Tools”, la Pro Git. Enunțul: ```bash git init curatenie && cd curatenie echo base > a.txt; git add .; git commit -m "Inițial" echo 1 > f.txt; git add .; git commit -m "Adaug funcția" echo 2 >> f.txt; git commit -am "typo" echo 3 >> f.txt; git commit -am "încă un typo" echo d > doc.txt; git add .; git commit -m "Documentaţie" git log --oneline git rebase -i HEAD~4 ``` În editor apare lista celor 4 commituri, **de la cel mai vechi la cel mai nou**. Scopul: - „typo” și „încă un typo” se contopesc în „Adaug funcția”, fără să le păstrezi mesajele; - mesajul ultimului commit se corectează în „Documentație pentru funcție” (cu ț corect). Salvează și închide editorul; la cererea de mesaj nou, scrie-l și salvează. **Regula de… Rebase-ul s-a oprit sau am obținut alt istoric decât voiam. Îți lipesc `git status` și `git log --oneline`. Pune-mi întrebări ca să înțeleg unde sunt și dă-mi indicii pentru a continua sau a reveni.

Lucrez la exercițiul „Găsește commitul vinovat cu git bisect” din capitolul „7. Git Tools”, la Pro Git. Enunțul: Generează un istoric cu 20 de commituri în care, la un moment dat, `calc.txt` se strică (`total=10` devine `total=11`). Fă-te că nu știi la ce pas. ```bash git init bisect && cd bisect for i in $(seq 1 20); do if [ $i -lt 13 ]; then echo "total=10" > calc.txt; else echo "total=11" > calc.txt; fi echo "pas $i" > pas.txt; git add .; git commit -q -m "Pasul $i" done ``` 1. Căutare manuală: `git bisect start`, `git bisect bad` (HEAD e stricat), `git bisect good HEAD~19`. La fiecare pas rulează `cat calc.txt` și răspunde cu `git bisect good` sau `git bisect bad`. Numără pașii. Încheie cu `git bisect reset`. 2. Căutare automată: același start, apoi `git bisect run grep -q "total=10" calc.txt`,… Înainte să încep, întreabă-mă câți pași cred că va avea căutarea pentru 20 de commituri și de ce. După ce termin, verifică-mi estimarea și întreabă-mă cum s-ar schimba pentru 1000 de commituri.

Lucrez la exercițiul „Găsește commitul vinovat cu git bisect” din capitolul „7. Git Tools”, la Pro Git. Enunțul: Generează un istoric cu 20 de commituri în care, la un moment dat, `calc.txt` se strică (`total=10` devine `total=11`). Fă-te că nu știi la ce pas. ```bash git init bisect && cd bisect for i in $(seq 1 20); do if [ $i -lt 13 ]; then echo "total=10" > calc.txt; else echo "total=11" > calc.txt; fi echo "pas $i" > pas.txt; git add .; git commit -q -m "Pasul $i" done ``` 1. Căutare manuală: `git bisect start`, `git bisect bad` (HEAD e stricat), `git bisect good HEAD~19`. La fiecare pas rulează `cat calc.txt` și răspunde cu `git bisect good` sau `git bisect bad`. Numără pașii. Încheie cu `git bisect reset`. 2. Căutare automată: același start, apoi `git bisect run grep -q "total=10" calc.txt`,… Vreau să scriu un mic script de test pentru `git bisect run` într-un proiect real (de ex. compilează și rulează testele). Lasă-mă să-l scriu, apoi verifică-mi dacă întoarce codurile de ieșire corecte; dă-mi indicii, nu scriptul.

Lucrez la exercițiul „Niveluri de configurare, alias-uri și șablon de commit” din capitolul „8. Customizing Git”, la Pro Git. Enunțul: Într-un depozit de test: 1. Suprascrie numele doar local și vezi de unde vine fiecare valoare: ```bash git config user.name "Nume (local)" git config --show-origin --get-all user.name git config --show-scope user.name git config --unset user.name ``` 2. Creează un șablon pentru mesajele de commit și activează-l doar în acest depozit: ```bash printf 'Rezumat (max. 50 de caractere)\n\nDe ce:\n\n[ref: ]\n' > .git/sablon.txt git config commit.template .git/sablon.txt git commit --allow-empty # se deschide editorul cu șablonul ``` 3. Adaugă două alias-uri utile (de ex. `st` pentru `status -s` și `ultimul` pentru `log -1 HEAD`) și unul care rulează o comandă externă, cu `!` (de ex. `git config… Vreau să-mi aleg 5 setări de configurare utile pentru lucrul zilnic. Întreabă-mă cum lucrez (editor, sistem de operare, cât de des fac commit) și lasă-mă să propun setările; verifică-le după capitolul 8.

Lucrez la exercițiul „Niveluri de configurare, alias-uri și șablon de commit” din capitolul „8. Customizing Git”, la Pro Git. Enunțul: Într-un depozit de test: 1. Suprascrie numele doar local și vezi de unde vine fiecare valoare: ```bash git config user.name "Nume (local)" git config --show-origin --get-all user.name git config --show-scope user.name git config --unset user.name ``` 2. Creează un șablon pentru mesajele de commit și activează-l doar în acest depozit: ```bash printf 'Rezumat (max. 50 de caractere)\n\nDe ce:\n\n[ref: ]\n' > .git/sablon.txt git config commit.template .git/sablon.txt git commit --allow-empty # se deschide editorul cu șablonul ``` 3. Adaugă două alias-uri utile (de ex. `st` pentru `status -s` și `ultimul` pentru `log -1 HEAD`) și unul care rulează o comandă externă, cu `!` (de ex. `git config… Pune-mi întrebări despre ce se întâmplă cu sfârșiturile de linie când lucrez cu un coleg pe Windows, până pot explica singur valorile `true`, `input` și `false` ale lui `core.autocrlf`.

Lucrez la exercițiul „Atribute Git - export-ignore, filtre și textconv” din capitolul „8. Customizing Git”, la Pro Git. Enunțul: ```bash git init atribute && cd atribute mkdir test; echo t > test/t.txt; echo cod > app.txt printf 'test/ export-ignore\n*.txt filter=majuscule\n' > .gitattributes git config filter.majuscule.clean "tr '[:lower:]' '[:upper:]'" git config filter.majuscule.smudge cat echo "salut lume" > nota.txt git add .; git commit -m "init" cat nota.txt git show HEAD:nota.txt git status -s git archive --format=tar HEAD | tar t ``` Apoi un diff lizibil pentru fișiere binare (are nevoie de `xxd`, prezent pe macOS și pe majoritatea Linux): ```bash printf '*.hex diff=hexa\n' >> .gitattributes git config diff.hexa.textconv xxd printf '\x00\x01AB' > d.hex; git add .; git commit -m "binar" printf '\x00\x02AB' >… Întreabă-mă pe ce drum merge un fișier la `git add` și la `git checkout` și unde se aplică fiecare filtru. Lasă-mă să desenez schema și verifică-mi-o cu indicii.

Lucrez la exercițiul „Atribute Git - export-ignore, filtre și textconv” din capitolul „8. Customizing Git”, la Pro Git. Enunțul: ```bash git init atribute && cd atribute mkdir test; echo t > test/t.txt; echo cod > app.txt printf 'test/ export-ignore\n*.txt filter=majuscule\n' > .gitattributes git config filter.majuscule.clean "tr '[:lower:]' '[:upper:]'" git config filter.majuscule.smudge cat echo "salut lume" > nota.txt git add .; git commit -m "init" cat nota.txt git show HEAD:nota.txt git status -s git archive --format=tar HEAD | tar t ``` Apoi un diff lizibil pentru fișiere binare (are nevoie de `xxd`, prezent pe macOS și pe majoritatea Linux): ```bash printf '*.hex diff=hexa\n' >> .gitattributes git config diff.hexa.textconv xxd printf '\x00\x01AB' > d.hex; git add .; git commit -m "binar" printf '\x00\x02AB' >… Vreau să folosesc un filtru real (de ex. pentru a scoate o parolă dintr-un fișier de configurare înainte de commit). Lasă-mă să propun regulile din `.gitattributes` și comenzile clean / smudge, apoi verifică-le și spune-mi ce riscuri am omis.

Lucrez la exercițiul „Un hook pre-commit care oprește TODO-urile” din capitolul „8. Customizing Git”, la Pro Git. Enunțul: Într-un depozit de test, creează fișierul `.git/hooks/pre-commit`: ```sh #!/bin/sh if git diff --cached | grep -q '^+.*TODO'; then echo "pre-commit: ai lăsat un TODO în modificările din staging" >&2 exit 1 fi ``` ```bash chmod +x .git/hooks/pre-commit echo "x = 1 # TODO" > a.py git add a.py git commit -m "cu TODO"; echo "cod de ieșire: $?" git commit --no-verify -m "forțat"; echo "cod de ieșire: $?" git log --oneline ``` Apoi modifică hook-ul ca să oprească și liniile cu spații la final (indiciu: `git diff --cached --check` întoarce un cod de ieșire diferit de 0 când găsește probleme) și testează-l. Răspunde: de ce hook-urile din `.git/hooks` nu ajung la colegi când fac `git clone`? Îți lipesc varianta mea extinsă a hook-ului pre-commit. Verifică dacă face ce trebuie și dacă întoarce codurile de ieșire corecte; dacă găsești o greșeală, dă-mi un indiciu, nu scriptul corectat.

Lucrez la exercițiul „Un hook pre-commit care oprește TODO-urile” din capitolul „8. Customizing Git”, la Pro Git. Enunțul: Într-un depozit de test, creează fișierul `.git/hooks/pre-commit`: ```sh #!/bin/sh if git diff --cached | grep -q '^+.*TODO'; then echo "pre-commit: ai lăsat un TODO în modificările din staging" >&2 exit 1 fi ``` ```bash chmod +x .git/hooks/pre-commit echo "x = 1 # TODO" > a.py git add a.py git commit -m "cu TODO"; echo "cod de ieșire: $?" git commit --no-verify -m "forțat"; echo "cod de ieșire: $?" git log --oneline ``` Apoi modifică hook-ul ca să oprească și liniile cu spații la final (indiciu: `git diff --cached --check` întoarce un cod de ieșire diferit de 0 când găsește probleme) și testează-l. Răspunde: de ce hook-urile din `.git/hooks` nu ajung la colegi când fac `git clone`? Pune-mi întrebări ca să ajung singur la concluzia de ce o regulă importantă a echipei trebuie verificată pe server, nu doar într-un hook client. Corectează-mă cu indicii.

Lucrez la exercițiul „Un hook commit-msg care cere o referință” din capitolul „8. Customizing Git”, la Pro Git. Enunțul: Echipa vrea ca fiecare mesaj de commit să conțină o referință la o sarcină, de forma `[ref: 123]`. 1. Scrie hook-ul `.git/hooks/commit-msg`. Indicii: primește ca prim argument (`$1`) calea către fișierul cu mesajul; dacă iese cu un cod diferit de 0, commitul se anulează; `grep -qE '\[ref: [0-9]+\]'` caută tiparul. 2. Fă-l executabil (`chmod +x`) și testează: ```bash echo y > b.txt; git add b.txt git commit -m "Fără referință"; echo "cod: $?" git commit -m "Adaug b [ref: 42]"; echo "cod: $?" git log --oneline -2 ``` 3. Bonus: modifică hook-ul `prepare-commit-msg` astfel încât mesajul propus să înceapă automat cu `[ref: ]` (citește în carte ce argumente primește). Vreau să scriu singur hook-ul commit-msg. Întreabă-mă ce primește scriptul și ce trebuie să întoarcă, apoi lasă-mă să scriu codul. Dacă nu merge, dă-mi un singur indiciu odată, nu soluția.

Lucrez la exercițiul „Un hook commit-msg care cere o referință” din capitolul „8. Customizing Git”, la Pro Git. Enunțul: Echipa vrea ca fiecare mesaj de commit să conțină o referință la o sarcină, de forma `[ref: 123]`. 1. Scrie hook-ul `.git/hooks/commit-msg`. Indicii: primește ca prim argument (`$1`) calea către fișierul cu mesajul; dacă iese cu un cod diferit de 0, commitul se anulează; `grep -qE '\[ref: [0-9]+\]'` caută tiparul. 2. Fă-l executabil (`chmod +x`) și testează: ```bash echo y > b.txt; git add b.txt git commit -m "Fără referință"; echo "cod: $?" git commit -m "Adaug b [ref: 42]"; echo "cod: $?" git log --oneline -2 ``` 3. Bonus: modifică hook-ul `prepare-commit-msg` astfel încât mesajul propus să înceapă automat cu `[ref: ]` (citește în carte ce argumente primește). Ajută-mă să găsesc cazuri limită pentru hook (`[ref:42]` fără spațiu, `[REF: 1]`, referința în corpul mesajului, commit de merge). Întreabă-mă ce cred că se întâmplă în fiecare caz înainte să testez și verifică-mi concluziile.

Lucrez la exercițiul „Politica echipei impusă pe server cu hook-ul update” din capitolul „8. Customizing Git”, la Pro Git. Enunțul: Hook-urile client se pot ocoli; pe server, hook-ul `update` poate respinge un push. Creează un depozit bare și hook-ul `server.git/hooks/update` (primește: numele referinței, hash-ul vechi, hash-ul nou): ```sh #!/bin/sh refname="$1"; oldrev="$2"; newrev="$3" zero=0000000000000000000000000000000000000000 if [ "$oldrev" = "$zero" ]; then range="$newrev"; else range="$oldrev..$newrev"; fi for rev in $(git rev-list "$range"); do if ! git log -1 --format=%B "$rev" | grep -qE '\[ref: [0-9]+\]'; then echo "[POLITICĂ] commit-ul $(git rev-parse --short $rev) nu are [ref: ]" exit 1 fi done exit 0 ``` ```bash git init --bare server.git # apoi creează hook-ul de mai sus și: chmod +x… Întreabă-mă ce valori cred că primește hook-ul la primul push și la al doilea (referința, hash-ul vechi, hash-ul nou) și de ce scriptul tratează separat hash-ul plin de zerouri. Corectează-mă cu indicii.

Lucrez la exercițiul „Politica echipei impusă pe server cu hook-ul update” din capitolul „8. Customizing Git”, la Pro Git. Enunțul: Hook-urile client se pot ocoli; pe server, hook-ul `update` poate respinge un push. Creează un depozit bare și hook-ul `server.git/hooks/update` (primește: numele referinței, hash-ul vechi, hash-ul nou): ```sh #!/bin/sh refname="$1"; oldrev="$2"; newrev="$3" zero=0000000000000000000000000000000000000000 if [ "$oldrev" = "$zero" ]; then range="$newrev"; else range="$oldrev..$newrev"; fi for rev in $(git rev-list "$range"); do if ! git log -1 --format=%B "$rev" | grep -qE '\[ref: [0-9]+\]'; then echo "[POLITICĂ] commit-ul $(git rev-parse --short $rev) nu are [ref: ]" exit 1 fi done exit 0 ``` ```bash git init --bare server.git # apoi creează hook-ul de mai sus și: chmod +x… Vreau să adaug în hook o regulă care refuză push-urile non-fast-forward. Lasă-mă să o scriu eu, apoi verifică-mi codul și testul pe care îl propun, fără să-mi dai varianta corectă.

Lucrez la exercițiul „Migrează copii de rezervă datate într-un istoric Git” din capitolul „9. Git and Other Systems”, la Pro Git. Enunțul: Cartea descrie importul unui proiect ținut ca directoare `back_AAAA_LL_ZZ`. Faci același lucru cu comenzi obișnuite. 1. Simulează copiile vechi: ```bash mkdir migrare && cd migrare mkdir -p snap/back_2014_01_02 snap/back_2014_01_07 snap/back_2014_01_15 echo v1 > snap/back_2014_01_02/index.html echo v2 > snap/back_2014_01_07/index.html; echo css > snap/back_2014_01_07/stil.css echo v3 > snap/back_2014_01_15/index.html ``` 2. Creează depozitul și importă fiecare director ca un commit, în ordine, cu data copiei: ```bash git init mig && cd mig for d in ../snap/back_*; do data=$(basename $d | sed 's/back_//; s/_/-/g') git rm -rq --ignore-unmatch . cp -R $d/. . git add -A GIT_AUTHOR_DATE="$data… Întreabă-mă, linie cu linie, ce face bucla de import (calculul datei, `git rm`, `cp`, `git add -A`, variabilele de mediu). Lasă-mă să explic eu și dă-mi indicii unde nu sunt sigur.

Lucrez la exercițiul „Migrează copii de rezervă datate într-un istoric Git” din capitolul „9. Git and Other Systems”, la Pro Git. Enunțul: Cartea descrie importul unui proiect ținut ca directoare `back_AAAA_LL_ZZ`. Faci același lucru cu comenzi obișnuite. 1. Simulează copiile vechi: ```bash mkdir migrare && cd migrare mkdir -p snap/back_2014_01_02 snap/back_2014_01_07 snap/back_2014_01_15 echo v1 > snap/back_2014_01_02/index.html echo v2 > snap/back_2014_01_07/index.html; echo css > snap/back_2014_01_07/stil.css echo v3 > snap/back_2014_01_15/index.html ``` 2. Creează depozitul și importă fiecare director ca un commit, în ordine, cu data copiei: ```bash git init mig && cd mig for d in ../snap/back_*; do data=$(basename $d | sed 's/back_//; s/_/-/g') git rm -rq --ignore-unmatch . cp -R $d/. . git add -A GIT_AUTHOR_DATE="$data… Am un proiect vechi ținut în arhive zip cu date în nume. Ajută-mă să-mi planific migrarea cu întrebări (ordine, autori, fișiere de ignorat, verificare la final), fără să-mi dai scriptul complet.

Lucrez la exercițiul „Scrie de mână un flux pentru git fast-import” din capitolul „9. Git and Other Systems”, la Pro Git. Enunțul: `git fast-import` primește la intrare un text care descrie commituri. Creează fișierul `import.txt` (forma `data < 1388664000 +0200 data < 1389096000 +0200 data < Întreabă-mă ce înseamnă fiecare linie din flux (`mark`, `committer` cu timestamp, `from`, `M 644 inline`, `D`) și lasă-mă să explic. Dă-mi indicii dacă nu știu de ce al doilea commit are nevoie de `from :1`.

Lucrez la exercițiul „Scrie de mână un flux pentru git fast-import” din capitolul „9. Git and Other Systems”, la Pro Git. Enunțul: `git fast-import` primește la intrare un text care descrie commituri. Creează fișierul `import.txt` (forma `data < 1388664000 +0200 data < 1389096000 +0200 data < Îți lipesc eroarea primită de la `git fast-import` și fluxul meu. Nu-mi corecta fișierul; pune-mi întrebări și dă-mi indicii (lungimea datelor, linii goale, ordinea comenzilor) până găsesc singur problema.

Lucrez la exercițiul „Unifică autorii după o migrare cu .mailmap” din capitolul „9. Git and Other Systems”, la Pro Git. Enunțul: La migrare, același om apare adesea sub mai multe identități (de ex. utilizatorul din SVN și adresa reală — de aceea `git svn` și importatoarele folosesc un fișier de autori). Într-un depozit de test: ```bash git commit --allow-empty --author="ion " -m "commit vechi" git commit --allow-empty --author="Ion Vechi " -m "commit nou" git shortlog -sne HEAD printf 'Ion Vechi ion \n' > .mailmap git shortlog -sne HEAD git log -2 --format='%an | %aN' ``` **Atenție:** dă întotdeauna o revizie (`HEAD`) lui `git shortlog` într-un script; fără ea, comanda citește de la intrarea standard când nu rulează într-un terminal. Răspunde: rescrie `.mailmap` istoria? Ce diferență este față de un fișier de autori… Întreabă-mă ce cred că se întâmplă cu hash-urile după ce adaug `.mailmap` și ce s-ar întâmpla dacă aș corecta autorii cu un import nou. Lasă-mă să verific singur cu `git log` și confirmă-mi doar după aceea.

Lucrez la exercițiul „Unifică autorii după o migrare cu .mailmap” din capitolul „9. Git and Other Systems”, la Pro Git. Enunțul: La migrare, același om apare adesea sub mai multe identități (de ex. utilizatorul din SVN și adresa reală — de aceea `git svn` și importatoarele folosesc un fișier de autori). Într-un depozit de test: ```bash git commit --allow-empty --author="ion " -m "commit vechi" git commit --allow-empty --author="Ion Vechi " -m "commit nou" git shortlog -sne HEAD printf 'Ion Vechi ion \n' > .mailmap git shortlog -sne HEAD git log -2 --format='%an | %aN' ``` **Atenție:** dă întotdeauna o revizie (`HEAD`) lui `git shortlog` într-un script; fără ea, comanda citește de la intrarea standard când nu rulează într-un terminal. Răspunde: rescrie `.mailmap` istoria? Ce diferență este față de un fișier de autori… Îți lipesc fișierul meu `.mailmap` pentru trei identități ale aceleiași persoane. Verifică-l și, dacă o linie nu face ce vreau, dă-mi un indiciu despre ordinea numelui canonic și a celui vechi.

Lucrez la exercițiul „Git ca client pentru Subversion - ce și de ce” din capitolul „9. Git and Other Systems”, la Pro Git. Enunțul: Răspunde pe baza secțiunii „Git as a Client” (nu ai nevoie de un server Subversion): 1. De ce `git svn dcommit` rescrie commiturile tale locale (îți schimbă hash-urile)? 2. De ce cartea recomandă ca istoria trimisă cu `git svn` să fie liniară și să eviți `git merge` între ramuri care ajung în Subversion? Ce face `git svn rebase` în locul lui `git pull`? 3. De ce nu e bine să lucrezi în paralel cu colegi care folosesc Git, prin push direct între voi, pe ramuri care merg și în Subversion? 4. Ce aduce în plus o migrare completă la Git față de folosirea lui `git svn` ca punte? 5. Ce informație trebuie pregătită la migrare ca autorii din Subversion să devină identități Git corecte? Vreau să explic cu un desen de commituri ce se întâmplă la `git svn dcommit`. Întreabă-mă pas cu pas ce devine fiecare commit local și verifică-mi desenul cu indicii, fără să-l faci tu.

Lucrez la exercițiul „Git ca client pentru Subversion - ce și de ce” din capitolul „9. Git and Other Systems”, la Pro Git. Enunțul: Răspunde pe baza secțiunii „Git as a Client” (nu ai nevoie de un server Subversion): 1. De ce `git svn dcommit` rescrie commiturile tale locale (îți schimbă hash-urile)? 2. De ce cartea recomandă ca istoria trimisă cu `git svn` să fie liniară și să eviți `git merge` între ramuri care ajung în Subversion? Ce face `git svn rebase` în locul lui `git pull`? 3. De ce nu e bine să lucrezi în paralel cu colegi care folosesc Git, prin push direct între voi, pe ramuri care merg și în Subversion? 4. Ce aduce în plus o migrare completă la Git față de folosirea lui `git svn` ca punte? 5. Ce informație trebuie pregătită la migrare ca autorii din Subversion să devină identități Git corecte? Pune-mi întrebări care să mă facă să leg recomandările pentru `git svn` de regula din capitolul 3 despre rebase pe commituri publicate. Verifică-mi apoi răspunsul la întrebarea 3.

Lucrez la exercițiul „Git ca bază de date cheie-valoare - blob-uri” din capitolul „10. Git Internals”, la Pro Git. Enunțul: ```bash git init interne && cd interne find .git/objects -type f echo 'test content' | git hash-object --stdin echo 'test content' | git hash-object -w --stdin find .git/objects -type f git cat-file -t d670460b git cat-file -s d670460b git cat-file -p d670460b4b4aece5915caf5c68d12f560a9fe3e4 echo 'version 1' > test.txt; git hash-object -w test.txt echo 'version 2' > test.txt; git hash-object -w test.txt rm test.txt git cat-file -p 83baae61804e65cc73a7201a7252750c76066a30 > test.txt; cat test.txt ``` Bonus: verifică singur formula hash-ului (antet `blob \0` + conținut, SHA-1): `printf 'blob 13\0test content\n' | shasum` (sau `sha1sum` pe Linux). Răspunde: de ce hash-ul pentru „test content”… Întreabă-mă ce intră în calculul hash-ului unui blob și ce nu (numele fișierului, data, autorul). Lasă-mă să deduc singur de ce doi oameni obțin același hash și ce înseamnă „content-addressable”.

Lucrez la exercițiul „Git ca bază de date cheie-valoare - blob-uri” din capitolul „10. Git Internals”, la Pro Git. Enunțul: ```bash git init interne && cd interne find .git/objects -type f echo 'test content' | git hash-object --stdin echo 'test content' | git hash-object -w --stdin find .git/objects -type f git cat-file -t d670460b git cat-file -s d670460b git cat-file -p d670460b4b4aece5915caf5c68d12f560a9fe3e4 echo 'version 1' > test.txt; git hash-object -w test.txt echo 'version 2' > test.txt; git hash-object -w test.txt rm test.txt git cat-file -p 83baae61804e65cc73a7201a7252750c76066a30 > test.txt; cat test.txt ``` Bonus: verifică singur formula hash-ului (antet `blob \0` + conținut, SHA-1): `printf 'blob 13\0test content\n' | shasum` (sau `sha1sum` pe Linux). Răspunde: de ce hash-ul pentru „test content”… Am observat că blob-ul nu conține numele `test.txt`. Pune-mi întrebări care să mă ducă la obiectul care ține numele fișierelor, fără să mi-l numești direct.

Lucrez la exercițiul „Construiește un commit doar cu comenzi plumbing” din capitolul „10. Git Internals”, la Pro Git. Enunțul: Continuă în depozitul `interne` (are blob-urile `version 1` și `version 2`). ```bash git update-index --add --cacheinfo 100644 83baae61804e65cc73a7201a7252750c76066a30 test.txt git write-tree git cat-file -p d8329fc1cc938780ffdd9f94e0d364e0ea74f579 c1=$(echo 'Primul commit' | git commit-tree d8329f) git cat-file -p $c1 echo 'version 2' > test.txt git update-index --add test.txt t2=$(git write-tree) c2=$(echo 'Al doilea commit' | git commit-tree $t2 -p $c1) git update-ref refs/heads/main $c2 git log --oneline --stat cat .git/HEAD; cat .git/refs/heads/main ``` Desenează graful obiectelor: commituri → tree-uri → blob-uri. Răspunde: de ce hash-ul tree-ului e la fel ca la colegi, dar hash-urile… Îți descriu desenul meu cu obiectele create (câte commituri, tree-uri, blob-uri și săgețile dintre ele). Verifică-l și întreabă-mă despre orice săgeată greșită sau lipsă, fără să-mi dai desenul corect.

Lucrez la exercițiul „Construiește un commit doar cu comenzi plumbing” din capitolul „10. Git Internals”, la Pro Git. Enunțul: Continuă în depozitul `interne` (are blob-urile `version 1` și `version 2`). ```bash git update-index --add --cacheinfo 100644 83baae61804e65cc73a7201a7252750c76066a30 test.txt git write-tree git cat-file -p d8329fc1cc938780ffdd9f94e0d364e0ea74f579 c1=$(echo 'Primul commit' | git commit-tree d8329f) git cat-file -p $c1 echo 'version 2' > test.txt git update-index --add test.txt t2=$(git write-tree) c2=$(echo 'Al doilea commit' | git commit-tree $t2 -p $c1) git update-ref refs/heads/main $c2 git log --oneline --stat cat .git/HEAD; cat .git/refs/heads/main ``` Desenează graful obiectelor: commituri → tree-uri → blob-uri. Răspunde: de ce hash-ul tree-ului e la fel ca la colegi, dar hash-urile… Pune-mi întrebări ca să descriu singur ce comenzi plumbing face „în spate” un simplu `git add` + `git commit`. Corectează-mă cu indicii.

Lucrez la exercițiul „Referințe, HEAD simbolic și obiecte tag” din capitolul „10. Git Internals”, la Pro Git. Enunțul: În depozitul `interne` (sau orice depozit cu cel puțin două commituri): ```bash ls .git/refs .git/refs/heads git update-ref refs/heads/test HEAD~1 git branch git symbolic-ref HEAD git symbolic-ref HEAD refs/heads/test git status | head -1 git symbolic-ref HEAD refs/heads/main git tag usor HEAD~1 git tag -a v1 -m "Prima versiune" HEAD~1 cat .git/refs/tags/usor cat .git/refs/tags/v1 git cat-file -t v1 git cat-file -p v1 ``` Apoi, într-o clonă a unui depozit (de ex. `echipa/ana` din capitolul 3), rulează `git config --get remote.origin.fetch` și `ls .git/refs/remotes/origin`. Răspunde: ce diferență vezi între `refs/tags/usor` și `refs/tags/v1`? Ce face o ramură, la nivel de fișiere? Întreabă-mă ce am găsit în `.git/refs/heads` și ce cred că face Git când creez o ramură sau fac un commit pe ea. Lasă-mă să explic și corectează-mă cu indicii.

Lucrez la exercițiul „Referințe, HEAD simbolic și obiecte tag” din capitolul „10. Git Internals”, la Pro Git. Enunțul: În depozitul `interne` (sau orice depozit cu cel puțin două commituri): ```bash ls .git/refs .git/refs/heads git update-ref refs/heads/test HEAD~1 git branch git symbolic-ref HEAD git symbolic-ref HEAD refs/heads/test git status | head -1 git symbolic-ref HEAD refs/heads/main git tag usor HEAD~1 git tag -a v1 -m "Prima versiune" HEAD~1 cat .git/refs/tags/usor cat .git/refs/tags/v1 git cat-file -t v1 git cat-file -p v1 ``` Apoi, într-o clonă a unui depozit (de ex. `echipa/ana` din capitolul 3), rulează `git config --get remote.origin.fetch` și `ls .git/refs/remotes/origin`. Răspunde: ce diferență vezi între `refs/tags/usor` și `refs/tags/v1`? Ce face o ramură, la nivel de fișiere? Pune-mi întrebări despre conținutul lui `.git/HEAD` în mod normal și după `git switch --detach HEAD~1`, ca să ajung singur la diferență. Verifică-mi explicația.

Lucrez la exercițiul „Obiecte libere, packfile și delte” din capitolul „10. Git Internals”, la Pro Git. Enunțul: ```bash git init pachete && cd pachete seq 1 20000 > mare.txt git add .; git commit -m "Fișier mare" echo "linie nouă" >> mare.txt; git commit -am "O linie în plus" git count-objects -v du -h .git/objects/?? | sort -h | tail -3 git gc git count-objects -v ls .git/objects/pack git verify-pack -v .git/objects/pack/*.idx | grep blob ``` Răspunde: câte obiecte sunt libere înainte și după `gc`? Care dintre cele două versiuni ale lui `mare.txt` e păstrată întreagă și care ca deltă? De ce așa? Îți lipesc liniile `blob` din `git verify-pack -v`. Întreabă-mă ce cred că înseamnă fiecare coloană (dimensiune, dimensiune în pachet, offset, adâncime, bază) și corectează-mă cu indicii.

Lucrez la exercițiul „Obiecte libere, packfile și delte” din capitolul „10. Git Internals”, la Pro Git. Enunțul: ```bash git init pachete && cd pachete seq 1 20000 > mare.txt git add .; git commit -m "Fișier mare" echo "linie nouă" >> mare.txt; git commit -am "O linie în plus" git count-objects -v du -h .git/objects/?? | sort -h | tail -3 git gc git count-objects -v ls .git/objects/pack git verify-pack -v .git/objects/pack/*.idx | grep blob ``` Răspunde: câte obiecte sunt libere înainte și după `gc`? Care dintre cele două versiuni ale lui `mare.txt` e păstrată întreagă și care ca deltă? De ce așa? În capitolul 1 scria că Git salvează instantanee, nu diferențe, dar aici văd delte. Pune-mi întrebări care să mă ajute să împac cele două idei singur; nu-mi da explicația direct.

Lucrez la exercițiul „Recuperează commituri pierdute cu reflog și fsck” din capitolul „10. Git Internals”, la Pro Git. Enunțul: În depozitul `pachete` (sau orice depozit de test): ```bash for i in 1 2 3; do echo $i > r$i; git add .; git commit -m "R$i"; done git log --oneline | head -3 git reset --hard HEAD~3 # „pierzi” cele trei commituri git log --oneline git reflog | head -2 ``` 1. Recuperează-le într-o ramură nouă, `recuperat`, folosind reflogul. Verifică cu `git log --oneline recuperat`. 2. Caz mai greu — fără reflog: șterge ramura (`git branch -D recuperat`) și reflogul (`rm -rf .git/logs`). Găsește din nou commitul cu `git fsck --full` și creează din el ramura `recuperat2`. 3. Verifică că `r1`, `r2`, `r3` există în `recuperat2` (`git ls-tree --name-only recuperat2`). Am pierdut commituri după un reset. Întreabă-mă ce am făcut și ghidează-mă cu întrebări să aleg între reflog și fsck; nu-mi scrie comenzile direct.

Lucrez la exercițiul „Recuperează commituri pierdute cu reflog și fsck” din capitolul „10. Git Internals”, la Pro Git. Enunțul: În depozitul `pachete` (sau orice depozit de test): ```bash for i in 1 2 3; do echo $i > r$i; git add .; git commit -m "R$i"; done git log --oneline | head -3 git reset --hard HEAD~3 # „pierzi” cele trei commituri git log --oneline git reflog | head -2 ``` 1. Recuperează-le într-o ramură nouă, `recuperat`, folosind reflogul. Verifică cu `git log --oneline recuperat`. 2. Caz mai greu — fără reflog: șterge ramura (`git branch -D recuperat`) și reflogul (`rm -rf .git/logs`). Găsește din nou commitul cu `git fsck --full` și creează din el ramura `recuperat2`. 3. Verifică că `r1`, `r2`, `r3` există în `recuperat2` (`git ls-tree --name-only recuperat2`). `git fsck` mi-a arătat un singur „dangling commit”, deși am pierdut trei. Pune-mi întrebări despre legăturile dintre commituri până îmi dau seama singur de ce. Verifică-mi apoi explicația.

Lucrez la exercițiul „Afișează ramura curentă în promptul terminalului” din capitolul „A. Appendix A: Git in Other Environments”, la Pro Git. Enunțul: Alege varianta potrivită shell-ului tău (`echo $SHELL`). **Zsh** (implicit pe macOS) — adaugă în `~/.zshrc`, ca în carte: ```bash autoload -Uz vcs_info precmd_vcs_info() { vcs_info } precmd_functions+=( precmd_vcs_info ) setopt prompt_subst RPROMPT='${vcs_info_msg_0_}' zstyle ':vcs_info:git:*' formats '%b' ``` **Bash** — găsește scriptul `git-prompt.sh` care vine cu Git (de ex. `find / -name git-prompt.sh 2>/dev/null`; pe Windows e inclus în Git Bash) și adaugă în `~/.bashrc`: ```bash . /calea/catre/git-prompt.sh export GIT_PS1_SHOWDIRTYSTATE=1 export PS1='\w$(__git_ps1 " (%s)")\$ ' ``` Deschide un terminal nou și intră într-un depozit de test: modifică un fișier, schimbă ramura, apoi fă… Promptul meu nu arată ramura. Îți lipesc ce am adăugat în fișierul de configurare și ce shell folosesc. Pune-mi întrebări de verificare (fișierul corect? terminal nou? calea scriptului?) și dă-mi indicii, nu soluția.

Lucrez la exercițiul „Afișează ramura curentă în promptul terminalului” din capitolul „A. Appendix A: Git in Other Environments”, la Pro Git. Enunțul: Alege varianta potrivită shell-ului tău (`echo $SHELL`). **Zsh** (implicit pe macOS) — adaugă în `~/.zshrc`, ca în carte: ```bash autoload -Uz vcs_info precmd_vcs_info() { vcs_info } precmd_functions+=( precmd_vcs_info ) setopt prompt_subst RPROMPT='${vcs_info_msg_0_}' zstyle ':vcs_info:git:*' formats '%b' ``` **Bash** — găsește scriptul `git-prompt.sh` care vine cu Git (de ex. `find / -name git-prompt.sh 2>/dev/null`; pe Windows e inclus în Git Bash) și adaugă în `~/.bashrc`: ```bash . /calea/catre/git-prompt.sh export GIT_PS1_SHOWDIRTYSTATE=1 export PS1='\w$(__git_ps1 " (%s)")\$ ' ``` Deschide un terminal nou și intră într-un depozit de test: modifică un fișier, schimbă ramura, apoi fă… Vreau ca promptul să arate și dacă am fișiere în staging sau neurmărite. Lasă-mă să caut singur opțiunile potrivite (în comentariile din git-prompt.sh sau în documentația vcs_info) și verifică-mi alegerea.

Lucrez la exercițiul „Același istoric în linia de comandă și într-o interfață grafică” din capitolul „A. Appendix A: Git in Other Environments”, la Pro Git. Enunțul: Folosește un depozit cu ramuri și merge-uri (de ex. `ramuri` sau `onto` din capitolul 3). 1. În terminal: `git log --oneline --graph --all --decorate`. 2. Deschide același depozit într-o interfață grafică pe care o ai: `gitk --all` și `git gui` (dacă sunt instalate; vin cu Git pe Windows și cu multe distribuții Linux), GitHub Desktop, VS Code (panoul Source Control) sau alt client. 3. Găsește în interfață: commitul de merge și cei doi părinți ai lui, diferențele unui commit, ramura curentă. 4. Fă din interfață o operație simplă (un commit sau crearea unei ramuri), apoi verifică în terminal cu `git log --oneline -3` și `git status`. Răspunde: ce ți-a fost mai ușor în interfața grafică și ce… Întreabă-mă ce am făcut ușor și ce greu în fiecare mod și ajută-mă cu întrebări să ajung la o regulă personală despre când folosesc interfața și când terminalul. Nu-mi spune tu regula.

Lucrez la exercițiul „Același istoric în linia de comandă și într-o interfață grafică” din capitolul „A. Appendix A: Git in Other Environments”, la Pro Git. Enunțul: Folosește un depozit cu ramuri și merge-uri (de ex. `ramuri` sau `onto` din capitolul 3). 1. În terminal: `git log --oneline --graph --all --decorate`. 2. Deschide același depozit într-o interfață grafică pe care o ai: `gitk --all` și `git gui` (dacă sunt instalate; vin cu Git pe Windows și cu multe distribuții Linux), GitHub Desktop, VS Code (panoul Source Control) sau alt client. 3. Găsește în interfață: commitul de merge și cei doi părinți ai lui, diferențele unui commit, ramura curentă. 4. Fă din interfață o operație simplă (un commit sau crearea unei ramuri), apoi verifică în terminal cu `git log --oneline -3` și `git status`. Răspunde: ce ți-a fost mai ușor în interfața grafică și ce… Îți descriu operația făcută în interfață și ce văd după aceea în terminal. Pune-mi întrebări ca să ghicesc singur comenzile Git echivalente și verifică-mi răspunsul.

Lucrez la exercițiul „Staging pe bucăți și conflicte în VS Code (și cu git add -p)” din capitolul „A. Appendix A: Git in Other Environments”, la Pro Git. Enunțul: Ai nevoie de VS Code (sau alt editor cu integrare Git) și un depozit de test. 1. Creează un fișier cu 10 linii, fă commit, apoi modifică linia 1 și linia 10 (două modificări separate). 2. În terminal: `git add -p` — pune în staging doar prima modificare (`y` pentru prima bucată, `n` pentru a doua). Verifică: `git diff --staged` și `git diff`. Anulează cu `git restore --staged .`. 3. În VS Code, panoul Source Control: deschide fișierul modificat, selectează doar linia 10 și alege „Stage Selected Ranges”. Verifică din nou în terminal cu `git diff --staged`. 4. Provoacă un conflict (ca în exercițiul de merge din capitolul 3) și deschide fișierul în VS Code: folosește butoanele *Accept Current… Întreabă-mă ce s-ar fi întâmplat dacă puneam ambele modificări în același commit și când ar conta asta pentru un coleg care citește istoria. Lasă-mă să găsesc singur avantajele staging-ului parțial.

Lucrez la exercițiul „Staging pe bucăți și conflicte în VS Code (și cu git add -p)” din capitolul „A. Appendix A: Git in Other Environments”, la Pro Git. Enunțul: Ai nevoie de VS Code (sau alt editor cu integrare Git) și un depozit de test. 1. Creează un fișier cu 10 linii, fă commit, apoi modifică linia 1 și linia 10 (două modificări separate). 2. În terminal: `git add -p` — pune în staging doar prima modificare (`y` pentru prima bucată, `n` pentru a doua). Verifică: `git diff --staged` și `git diff`. Anulează cu `git restore --staged .`. 3. În VS Code, panoul Source Control: deschide fișierul modificat, selectează doar linia 10 și alege „Stage Selected Ranges”. Verifică din nou în terminal cu `git diff --staged`. 4. Provoacă un conflict (ca în exercițiul de merge din capitolul 3) și deschide fișierul în VS Code: folosește butoanele *Accept Current… Pune-mi întrebări ca să ghicesc ce comenzi Git (sau ce modificări în fișier) corespund butoanelor din VS Code pentru staging și conflicte. Verifică-mi presupunerile cu `git status` și `git diff`.

Lucrez la exercițiul „Ce unealtă Git pentru ce situație?” din capitolul „A. Appendix A: Git in Other Environments”, la Pro Git. Enunțul: Pe baza anexei A, răspunde: 1. De ce cartea predă Git în linia de comandă, deși există multe interfețe grafice? 2. Un coleg nou se teme de terminal. Ce i-ai recomanda pentru primele săptămâni și ce ar trebui totuși să învețe în linia de comandă (gândește-te la rebase interactiv, reflog, bisect)? 3. Ce avantaje are integrarea Git în editor (VS Code, IntelliJ) față de un client separat? 4. Ce îți aduc în terminal completarea automată și un prompt cu starea depozitului? Ce greșeli concrete previn? 5. Alege un instrument concret pe care îl folosești sau l-ai putea folosi și descrie 3 operații pe care le faci mai repede în el decât în terminal. Îți scriu răspunsurile mele. Verifică-le cu anexa A și, unde sunt superficiale, pune-mi o întrebare suplimentară care să mă facă să le aprofundez singur. Nu-mi da răspunsuri model.

Lucrez la exercițiul „Ce unealtă Git pentru ce situație?” din capitolul „A. Appendix A: Git in Other Environments”, la Pro Git. Enunțul: Pe baza anexei A, răspunde: 1. De ce cartea predă Git în linia de comandă, deși există multe interfețe grafice? 2. Un coleg nou se teme de terminal. Ce i-ai recomanda pentru primele săptămâni și ce ar trebui totuși să învețe în linia de comandă (gândește-te la rebase interactiv, reflog, bisect)? 3. Ce avantaje are integrarea Git în editor (VS Code, IntelliJ) față de un client separat? 4. Ce îți aduc în terminal completarea automată și un prompt cu starea depozitului? Ce greșeli concrete previn? 5. Alege un instrument concret pe care îl folosești sau l-ai putea folosi și descrie 3 operații pe care le faci mai repede în el decât în terminal. Joacă rolul unui coleg începător care vrea să folosească doar o interfață grafică. Pune-mi obiecții realiste și lasă-mă să-l conving cu argumente; verifică-mi apoi argumentele.

Lucrez la exercițiul „Un script Python care citește starea depozitului” din capitolul „B. Appendix B: Embedding Git in your Applications”, la Pro Git. Enunțul: Cea mai simplă integrare (B.1) e să apelezi comanda `git` și să-i citești ieșirea. Scrie `stare.py` care afișează, pentru depozitul din directorul curent: 1. ramura curentă (`git rev-parse --abbrev-ref HEAD`); 2. fiecare fișier modificat sau neurmărit, cu codul lui din două litere (`git status --porcelain=v1`); 3. ultimele 3 commituri ca `hash | autor | subiect`, folosind un format ușor de despărțit (`git log -3 --format=%h%x09%an%x09%s`, unde `%x09` e un TAB). Schelet: ```python import subprocess def git(*args): return subprocess.run(["git", *args], capture_output=True, text=True, check=True).stdout # TODO: ramura, starea, ultimele commituri ``` Rulează-l într-un depozit de test cu un… Îți lipesc scriptul meu `stare.py` și ce afișează. Verifică dacă tratez corect fișierele cu spații în nume și depozitele fără commituri; dacă găsești probleme, dă-mi indicii, nu codul corectat.

Lucrez la exercițiul „Un script Python care citește starea depozitului” din capitolul „B. Appendix B: Embedding Git in your Applications”, la Pro Git. Enunțul: Cea mai simplă integrare (B.1) e să apelezi comanda `git` și să-i citești ieșirea. Scrie `stare.py` care afișează, pentru depozitul din directorul curent: 1. ramura curentă (`git rev-parse --abbrev-ref HEAD`); 2. fiecare fișier modificat sau neurmărit, cu codul lui din două litere (`git status --porcelain=v1`); 3. ultimele 3 commituri ca `hash | autor | subiect`, folosind un format ușor de despărțit (`git log -3 --format=%h%x09%an%x09%s`, unde `%x09` e un TAB). Schelet: ```python import subprocess def git(*args): return subprocess.run(["git", *args], capture_output=True, text=True, check=True).stdout # TODO: ramura, starea, ultimele commituri ``` Rulează-l într-un depozit de test cu un… Ce se întâmplă cu scriptul meu dacă îl rulez în afara unui depozit? Întreabă-mă ce cred că face `check=True` și ajută-mă cu indicii să tratez eroarea frumos, fără să-mi scrii tu tratarea.

Lucrez la exercițiul „Citește un depozit din Python cu Dulwich” din capitolul „B. Appendix B: Embedding Git in your Applications”, la Pro Git. Enunțul: Dulwich (B.5) e o implementare Git în Python pur. Într-un mediu virtual: ```bash python3 -m venv venv && . venv/bin/activate pip install dulwich ``` Scrie un script care, pentru un depozit de test cu câteva commituri și ramuri: 1. deschide depozitul (`from dulwich.repo import Repo; r = Repo('.')`); 2. afișează hash-ul lui HEAD (`r.head()`), mesajul, autorul și numărul de părinți ai commitului (`c = r[r.head()]`; atributele `message`, `author`, `parents` sunt de tip `bytes` / listă); 3. listează referințele (`r.refs.keys()`); 4. afișează ultimele 2 commituri cu nivelul „porcelain” (`from dulwich import porcelain; porcelain.log('.', max_entries=2)`). Compară rezultatele cu `git log -2` și… Întreabă-mă ce obiecte Git (commit, tree, blob) cred că pot accesa prin `r[...]` și cum aș ajunge de la un commit la conținutul unui fișier. Lasă-mă să încerc în cod și dă-mi indicii când mă blochez.

Lucrez la exercițiul „Citește un depozit din Python cu Dulwich” din capitolul „B. Appendix B: Embedding Git in your Applications”, la Pro Git. Enunțul: Dulwich (B.5) e o implementare Git în Python pur. Într-un mediu virtual: ```bash python3 -m venv venv && . venv/bin/activate pip install dulwich ``` Scrie un script care, pentru un depozit de test cu câteva commituri și ramuri: 1. deschide depozitul (`from dulwich.repo import Repo; r = Repo('.')`); 2. afișează hash-ul lui HEAD (`r.head()`), mesajul, autorul și numărul de părinți ai commitului (`c = r[r.head()]`; atributele `message`, `author`, `parents` sunt de tip `bytes` / listă); 3. listează referințele (`r.refs.keys()`); 4. afișează ultimele 2 commituri cu nivelul „porcelain” (`from dulwich import porcelain; porcelain.log('.', max_entries=2)`). Compară rezultatele cu `git log -2` și… Îți lipesc scriptul meu cu Dulwich și ce afișează. Verifică dacă tratez corect `bytes` față de `str` și ce se întâmplă într-un depozit gol; spune-mi unde greșesc, fără să-mi rescrii codul.

Lucrez la exercițiul „Comenzi plumbing bune pentru scripturi” din capitolul „B. Appendix B: Embedding Git in your Applications”, la Pro Git. Enunțul: Într-un depozit de test cu câteva ramuri și taguri, rulează și explică fiecare comandă: ```bash git rev-parse HEAD git rev-parse --short HEAD~1 git rev-parse --abbrev-ref HEAD git rev-parse --show-toplevel git rev-list --count HEAD git for-each-ref --format='%(refname:short) %(objectname:short) %(committerdate:short)' refs/heads git ls-files -s git ls-tree -r --name-only HEAD git cat-file -t HEAD^{tree} ``` Apoi scrie un one-liner (bash) care afișează ramurile ordonate după data ultimului commit, cele mai recente primele (indiciu: `--sort` la `for-each-ref`). Răspunde: de ce în scripturi sunt preferate aceste comenzi în locul lui `git branch` sau `git log` cu formatul implicit? Îți scriu ce cred că face fiecare dintre cele nouă comenzi. Verifică-mi explicațiile și, unde greșesc, pune-mi o întrebare care să mă îndrume spre răspuns.

Lucrez la exercițiul „Comenzi plumbing bune pentru scripturi” din capitolul „B. Appendix B: Embedding Git in your Applications”, la Pro Git. Enunțul: Într-un depozit de test cu câteva ramuri și taguri, rulează și explică fiecare comandă: ```bash git rev-parse HEAD git rev-parse --short HEAD~1 git rev-parse --abbrev-ref HEAD git rev-parse --show-toplevel git rev-list --count HEAD git for-each-ref --format='%(refname:short) %(objectname:short) %(committerdate:short)' refs/heads git ls-files -s git ls-tree -r --name-only HEAD git cat-file -t HEAD^{tree} ``` Apoi scrie un one-liner (bash) care afișează ramurile ordonate după data ultimului commit, cele mai recente primele (indiciu: `--sort` la `for-each-ref`). Răspunde: de ce în scripturi sunt preferate aceste comenzi în locul lui `git branch` sau `git log` cu formatul implicit? Vreau un script care listează ramurile locale deja integrate în main și cât de vechi sunt. Lasă-mă să-l scriu cu comenzi plumbing, apoi verifică-l și dă-mi indicii unde nu e robust.

Lucrez la exercițiul „Libgit2, JGit, go-git sau comanda git?” din capitolul „B. Appendix B: Embedding Git in your Applications”, la Pro Git. Enunțul: Pe baza anexei B, alege soluția potrivită și argumentează: 1. Un mic script de administrare care rulează pe un server unde Git e deja instalat. 2. O aplicație Android care trebuie să cloneze depozite (fără să depindă de un `git` instalat). 3. Un serviciu în Go care analizează mii de depozite în paralel, în memorie. 4. O aplicație desktop în C# sau Python care vrea performanță bună și acces la obiecte (bindings pentru libgit2, de ex. LibGit2Sharp sau pygit2). 5. Un instrument Python care trebuie să ruleze oriunde, fără biblioteci native de compilat. Pentru fiecare, notează un dezavantaj al alegerii tale. Îți scriu alegerile mele pentru cele 5 situații. Pentru fiecare, pune-mi o obiecție (performanță, portabilitate, licență, dependențe) și lasă-mă să-mi apăr alegerea înainte să-mi spui părerea ta.

Lucrez la exercițiul „Libgit2, JGit, go-git sau comanda git?” din capitolul „B. Appendix B: Embedding Git in your Applications”, la Pro Git. Enunțul: Pe baza anexei B, alege soluția potrivită și argumentează: 1. Un mic script de administrare care rulează pe un server unde Git e deja instalat. 2. O aplicație Android care trebuie să cloneze depozite (fără să depindă de un `git` instalat). 3. Un serviciu în Go care analizează mii de depozite în paralel, în memorie. 4. O aplicație desktop în C# sau Python care vrea performanță bună și acces la obiecte (bindings pentru libgit2, de ex. LibGit2Sharp sau pygit2). 5. Un instrument Python care trebuie să ruleze oriunde, fără biblioteci native de compilat. Pentru fiecare, notează un dezavantaj al alegerii tale. Nu sunt sigur ce înseamnă că libgit2 e „reentrant” și de ce contează pentru o aplicație. Pune-mi întrebări și dă-mi indicii până pot explica singur, cu un exemplu.

Lucrez la exercițiul „Ce comandă folosești? 12 situații” din capitolul „C. Appendix C: Git Commands”, la Pro Git. Enunțul: Pentru fiecare situație scrie comanda (sau comenzile) din anexa C, fără să te uiți în carte; apoi verifică-te cu `git help ` sau `git -h`. 1. Vrei să vezi ce opțiuni are `git log`, rapid, în terminal. 2. Vrei să aduci modificările de pe server fără să-ți atingi ramurile locale. 3. Ai pus în staging un fișier din greșeală. 4. Vrei să anulezi efectul unui commit deja publicat, fără să rescrii istoria. 5. Vrei să știi cine a modificat ultima dată linia 42 dintr-un fișier. 6. Cauți un text în toate fișierele urmărite. 7. Vrei să trimiți cuiva commiturile pe e-mail, ca fișiere. 8. Vrei să aplici un fișier `.patch` produs cu `git diff`. 9. Vrei să muți proiectul pe un stick, cu toată istoria,… Îți lipesc comenzile alese pentru cele 12 situații. Verifică-le și, pentru cele greșite, dă-mi un indiciu despre categoria din anexa C în care să caut, nu comanda corectă.

Lucrez la exercițiul „Ce comandă folosești? 12 situații” din capitolul „C. Appendix C: Git Commands”, la Pro Git. Enunțul: Pentru fiecare situație scrie comanda (sau comenzile) din anexa C, fără să te uiți în carte; apoi verifică-te cu `git help ` sau `git -h`. 1. Vrei să vezi ce opțiuni are `git log`, rapid, în terminal. 2. Vrei să aduci modificările de pe server fără să-ți atingi ramurile locale. 3. Ai pus în staging un fișier din greșeală. 4. Vrei să anulezi efectul unui commit deja publicat, fără să rescrii istoria. 5. Vrei să știi cine a modificat ultima dată linia 42 dintr-un fișier. 6. Cauți un text în toate fișierele urmărite. 7. Vrei să trimiți cuiva commiturile pe e-mail, ca fișiere. 8. Vrei să aplici un fișier `.patch` produs cu `git diff`. 9. Vrei să muți proiectul pe un stick, cu toată istoria,… Pune-mi încă 8 situații noi, una câte una, și lasă-mă să răspund cu comanda. După fiecare răspuns verifică-l și spune-mi pe scurt de ce e corect sau ce opțiune îmi lipsește.

Lucrez la exercițiul „Mută un depozit fără rețea cu git bundle” din capitolul „C. Appendix C: Git Commands”, la Pro Git. Enunțul: ```bash git init sursa && cd sursa echo 1 > f; git add .; git commit -m c1 echo 2 >> f; git commit -am c2 git bundle create ../repo.bundle HEAD main git bundle verify ../repo.bundle cd .. git clone repo.bundle -b main destinatie cd destinatie && git log --oneline && cd .. ``` Acum trimite doar ce e nou: ```bash cd sursa echo 3 >> f; git commit -am c3 git bundle create ../nou.bundle main~1..main cd ../destinatie git bundle list-heads ../nou.bundle git pull ../nou.bundle main git log --oneline ``` Răspunde: când ar fi util un bundle (gândește-te la rețele izolate, e-mail, stick USB)? De ce bundle-ul incremental nu poate fi clonat singur? Întreabă-mă ce cred că se află într-un fișier bundle (referințe, obiecte, un packfile?) și de ce `verify` spune că bundle-ul complet „records a complete history”. Lasă-mă să deduc și verifică-mi explicația.

Lucrez la exercițiul „Mută un depozit fără rețea cu git bundle” din capitolul „C. Appendix C: Git Commands”, la Pro Git. Enunțul: ```bash git init sursa && cd sursa echo 1 > f; git add .; git commit -m c1 echo 2 >> f; git commit -am c2 git bundle create ../repo.bundle HEAD main git bundle verify ../repo.bundle cd .. git clone repo.bundle -b main destinatie cd destinatie && git log --oneline && cd .. ``` Acum trimite doar ce e nou: ```bash cd sursa echo 3 >> f; git commit -am c3 git bundle create ../nou.bundle main~1..main cd ../destinatie git bundle list-heads ../nou.bundle git pull ../nou.bundle main git log --oneline ``` Răspunde: când ar fi util un bundle (gândește-te la rețele izolate, e-mail, stick USB)? De ce bundle-ul incremental nu poate fi clonat singur? Vreau să sincronizez săptămânal un proiect între un calculator fără internet și laptopul meu. Lasă-mă să propun pașii cu bundle-uri incrementale și verifică-i; dă-mi indicii dacă intervalul ales nu e bun.

Lucrez la exercițiul „git apply față de git am” din capitolul „C. Appendix C: Git Commands”, la Pro Git. Enunțul: Într-un depozit de test cu un fișier urmărit `f`: ```bash echo "linie nouă" >> f git diff > ../p.patch git restore f git apply --stat ../p.patch git apply --check ../p.patch && echo "se aplică curat" git apply ../p.patch git status -s git restore f ``` Apoi fă un commit cu aceeași modificare, exportă-l cu `git format-patch -1 -o ../mail`, revino cu `git reset --hard HEAD~1` și aplică-l cu `git am ../mail/*.patch`. Compară `git log -1` după fiecare metodă. Răspunde: ce lipsește dintr-un patch făcut cu `git diff` ca să poată deveni direct un commit? Ce face `git apply` dacă patch-ul nu se aplică (față de comanda clasică `patch`)? Pune-mi câteva situații (patch primit pe e-mail cu format-patch, diff lipit într-un chat, un patch vechi care poate nu se mai aplică) și lasă-mă să aleg comanda și opțiunile. Verifică-mi alegerea.

Lucrez la exercițiul „git apply față de git am” din capitolul „C. Appendix C: Git Commands”, la Pro Git. Enunțul: Într-un depozit de test cu un fișier urmărit `f`: ```bash echo "linie nouă" >> f git diff > ../p.patch git restore f git apply --stat ../p.patch git apply --check ../p.patch && echo "se aplică curat" git apply ../p.patch git status -s git restore f ``` Apoi fă un commit cu aceeași modificare, exportă-l cu `git format-patch -1 -o ../mail`, revino cu `git reset --hard HEAD~1` și aplică-l cu `git am ../mail/*.patch`. Compară `git log -1` după fiecare metodă. Răspunde: ce lipsește dintr-un patch făcut cu `git diff` ca să poată deveni direct un commit? Ce face `git apply` dacă patch-ul nu se aplică (față de comanda clasică `patch`)? `git apply --check` mi-a raportat o eroare. Îți lipesc mesajul. Pune-mi întrebări despre ce s-a schimbat în fișier între timp și dă-mi indicii despre opțiuni utile (de ex. pentru three-way), fără să-mi dai comanda directă.

Lucrez la exercițiul „Anulează un commit publicat - revert, nu reset” din capitolul „C. Appendix C: Git Commands”, la Pro Git. Enunțul: Folosește setup-ul cu doi colegi din capitolul 3 (`echipa/server.git`, clonele `ana` și `bogdan`) sau refă-l. 1. Ana publică un commit greșit: ```bash cd ana echo "configurare greșită" > config.txt; git add .; git commit -m "Configurare nouă" git push cd ../bogdan && git pull && cd ../ana ``` 2. **Varianta corectă:** `git revert HEAD` (acceptă mesajul), `git push`. La Bogdan: `git pull` și `git log --oneline -3`. 3. **Varianta greșită (doar ca să vezi efectul):** Ana face un commit greșit nou și îl publică; Bogdan face pull. Ana face `git reset --hard HEAD~1` și încearcă `git push`, apoi `git push --force`. Bogdan face un commit nou, `git pull`, `git status -sb` și `git push`. Ce a ajuns… Înainte de varianta greșită, întreabă-mă ce cred că va vedea Bogdan după `git push --force` al Anei și pull-ul lui. Nu-mi spune; după ce rulez, ajută-mă să explic diferența dintre revert și reset pe istorie publicată.

Lucrez la exercițiul „Anulează un commit publicat - revert, nu reset” din capitolul „C. Appendix C: Git Commands”, la Pro Git. Enunțul: Folosește setup-ul cu doi colegi din capitolul 3 (`echipa/server.git`, clonele `ana` și `bogdan`) sau refă-l. 1. Ana publică un commit greșit: ```bash cd ana echo "configurare greșită" > config.txt; git add .; git commit -m "Configurare nouă" git push cd ../bogdan && git pull && cd ../ana ``` 2. **Varianta corectă:** `git revert HEAD` (acceptă mesajul), `git push`. La Bogdan: `git pull` și `git log --oneline -3`. 3. **Varianta greșită (doar ca să vezi efectul):** Ana face un commit greșit nou și îl publică; Bogdan face pull. Ana face `git reset --hard HEAD~1` și încearcă `git push`, apoi `git push --force`. Bogdan face un commit nou, `git pull`, `git status -sb` și `git push`. Ce a ajuns… Ajută-mă să-mi formulez o regulă clară: când folosesc reset, când revert și când amend. Pune-mi întrebări despre dacă un commit e publicat sau nu, și verifică-mi regula finală.