Acest articol reunește trei subiecte care apar după ce stăpâniți ciclul de bază din Git: cum creați un repository (cu git init sau din IDE), prin ce se deosebește rebase de merge și cum eliminați corect un secret ajuns accidental în istoric. Toate cele trei vă vor fi utile și când lucrați cu Claude Code: acesta execută operațiile prin comenzi, iar dumneavoastră trebuie să înțelegeți ce se află în spatele lor.

Exemplele și capturile de ecran sunt din IDE-urile JetBrains; denumirile și locul acțiunilor pot diferi în versiunea dumneavoastră. Pentru exerciții, folosiți un repository separat de antrenament. În proiectul de lucru, urmați regulile acestuia privind branch-urile, commit-urile și trimiterea modificărilor.

Crearea unui repository - git init și din IDE

Dacă proiectul se află deja pe GitHub, îl puteți clona. În altă situație, aveți un folder local cu cod. git init creează în el datele interne Git, dar nu și primul commit. Exemplul de mai jos presupune că README.md și .gitignore au fost deja create și verificate; celelalte fișiere necesare se adaugă separat.

git init
git status
# după verificarea README și a regulilor de ignorare
git add README.md .gitignore
git diff --cached
git commit -m "Initial commit"

Pentru un repository local în IDE, folosiți acțiunea de creare a unui repository Git sau de activare a controlului versiunilor. Share Project on GitHub este un scenariu separat: creează și un repository la distanță și vă oferă opțiunea de a trimite modificările. Înainte de asta, verificați fișierele selectate, istoricul și vizibilitatea.

Public sau private

Când creați un repository, îi alegeți vizibilitatea:

  • public - repository-ul este vizibil tuturor pe internet, iar oricine îi poate vedea codul. Potrivit pentru portofoliu și open source;
  • private - accesul îl aveți doar dumneavoastră și persoanele invitate. Este alegerea implicită pentru cod de lucru sau de antrenament care nu trebuie făcut public.

Vizibilitatea nu e bătută în cuie: o puteți schimba mai târziu din setările repository-ului pe GitHub.

Cum se leagă de Claude Code

Claude Code poate rula git init și poate pregăti primul commit în locul dumneavoastră. Dacă nu aveți încă un repository pe GitHub, îl poate crea prin GitHub CLI (gh repo create) - iar atunci decideți dacă va fi public sau private.

rebase vs merge - care este diferența

Atât merge, cât și rebase rezolvă aceeași problemă: transferă lucrul dintr-un branch în altul. Însă o fac diferit, iar de asta depinde cum va arăta istoricul proiectului.

merge unește istoricul branch-urilor. Dacă acestea au evoluat separat, de regulă se creează un commit de merge cu doi părinți. Dacă branch-ul curent este strămoșul celuilalt, Git poate face un fast-forward fără un commit nou. Diagrama de mai jos arată cazul branch-urilor separate.

Linia de sus este main, cea de jos este feature. După merge, main indică spre M, care are doi părinți: E și D.ABEMCD
Linia de sus este main, cea de jos este feature. După merge, main indică spre M, care are doi părinți: E și D.

merge păstrează ambele linii și adaugă un commit de merge - istoricul arată clar că a existat un branch separat feature.

rebase mută commit-urile dumneavoastră ca și cum ați fi început lucrul de la vârful actual al branch-ului țintă. Istoricul devine liniar, ca un singur lanț. Există însă un cost: rebase rescrie commit-urile - cele vechi sunt înlocuite cu altele noi, cu hash-uri diferite.

Branch-ul main indică spre E, iar branch-ul feature după rebase - spre noul D2. Istoricul comun până la B nu este afișat.BEC2D2
Branch-ul main indică spre E, iar branch-ul feature după rebase - spre noul D2. Istoricul comun până la B nu este afișat.

După rebase, commit-urile C și D par create peste E: istoricul este liniar, dar acestea sunt commit-uri noi (C2, D2), cu hash-uri diferite.

Ce alegeți?

  • merge - când contează să păstrați istoricul real și când branch-ul este partajat. Este alegerea sigură implicită;
  • rebase - pentru a face ordine în propriul branch înainte de un pull request: istoricul liniar se citește mai ușor.
De reținut

Cât timp vă familiarizați cu rebase, folosiți-l pe propriul branch nepublicat. Rescrierea unui branch folosit deja de alte persoane se face doar după o procedură agreată: altfel, colegii vor rămâne cu istoricul vechi. Dacă nu sunteți sigur de consecințe, opriți-vă și verificați regulile proiectului.

De reținut

Modul de integrare este stabilit de sarcină și de regulile proiectului. Nu vă bazați pe ce ar alege agentul, după cum presupuneți, în mod implicit: înainte de execuție, cereți-i să numească branch-ul țintă, operația și consecințele asupra istoricului.

Eliminarea secretelor dintr-un repository

Ștergerea unui fișier într-un commit nou nu elimină secretul din commit-urile anterioare. Dacă o parolă sau un token a devenit accesibil altor persoane, revocați-l sau înlocuiți-l mai întâi în serviciul care l-a emis. Curățarea istoricului nu anulează copiile deja făcute.

De reținut

Nu tratați curățarea istoricului partajat ca pe o simplă corectare a unui fișier. Operația schimbă identificatorii commit-urilor și necesită coordonare: opriți trimiterea branch-urilor vechi, identificați toate căile afectate, verificați rezultatul într-o copie separată și conveniți cum își actualizează colegii copiile.

Pentru curățare, GitHub descrie o procedură cu git-filter-repo. Comenzile concrete depind de câteva lucruri: dacă ștergeți fișierul în întregime sau doar înlocuiți un șir secret, unde a apărut acesta și unde a ajuns istoricul. Urmați instrucțiunile oficiale pentru eliminarea datelor sensibile, inclusiv realizarea unei clone proaspete, verificarea rezultatului, actualizarea referințelor la distanță și acțiunile colegilor.

Curățarea copiei locale nu modifică de la sine serverul. Trimiterea forțată a istoricului rescris este o acțiune separată, care trebuie convenită: aici nu este cazul să rulați o comandă universală pentru toate branch-urile. Copiile din clonele și fork-urile altor persoane nu sunt sub controlul dumneavoastră; pentru referințele și cache-urile GitHub încă accesibile se aplică condițiile pentru a contacta Support din aceleași instrucțiuni.

Pentru a reduce riscul ca situația să se repete:

  • păstrați valorile secretelor în afara codului, de exemplu în variabile de mediu;
  • adăugați fișiere locale precum .env în .gitignore înainte să fie urmărite;
  • verificați fișierele selectate și git diff --cached înainte de commit;
  • dacă repository-ul oferă secret scanning și push protection, activați-le ca verificare suplimentară: nu detectează toate secretele posibile.
De reținut

Agentul vă poate ajuta să găsiți căile afectate și să pregătiți un plan de curățare. Nu trimiteți un secret activ în chat ca să îl caute. Revocați mai întâi accesul, apoi conveniți cum abordați istoricul.

Cum funcționează împreună cu Claude Code

Toate cele trei subiecte apar când Claude Code lucrează cu repository-ul dumneavoastră. Iată la ce să fiți atenți:

  • poate inițializa un repository (git init) și pregăti primul commit - dumneavoastră alegeți public sau private când îl creați pe GitHub;
  • propune o metodă de integrare conform regulilor proiectului; verificați consecințele unui merge sau rebase înainte de execuție;
  • vede fișierele incluse în commit, însă dumneavoastră rămâneți responsabil să vă asigurați că niciun secret nu ajunge acolo.
De reținut

Înainte de commit, verificați atât lista fișierelor, cât și conținutul lor în diff. Un secret se poate afla într-un fișier obișnuit cu cod sursă, nu doar în .env. Dacă a ajuns deja în istoric, înlocuiți mai întâi secretul afectat, apoi stabiliți dacă istoricul trebuie curățat.

Articolul anterior: Anularea și recuperarea modificărilor în Git