Primul repository

Lectură estimată: 4 minute

Estimare pentru text, la un ritm de 180 de cuvinte pe minut. Timpul pentru analizarea codului, exerciții și proiecte se adaugă separat și depinde de ritmul tău.

În lecția asta faci ciclul complet: creezi un repository, faci primele commit-uri, citești istoricul și trimiți totul pe GitHub. Deschide un terminal și lucrează efectiv, nu doar citi — Git se învață cu mâinile.

Creezi repository-ul

mkdir proiect-test
cd proiect-test
git init

Git îți răspunde ceva de genul Initialized empty Git repository in .../proiect-test/.git/. Acel folder .git este tot repository-ul: istoric, configurări, referințe. Dacă îl ștergi, rămâi cu fișierele, dar pierzi istoricul.

Creezi un fișier și vezi ce spune Git:

echo "# Proiect test" > README.md
git status

On branch main

No commits yet

Untracked files:
  (use "git add <file>..." to include in what will be committed)
        README.md

Untracked înseamnă că Git vede fișierul, dar nu îl urmărește încă. Ia-ți obiceiul să rulezi git status des; e comanda care îți spune mereu unde te afli.

add și commit

git add README.md
git status

Acum fișierul apare sub Changes to be committed. E în staging area. Îl salvezi în istoric:

git commit -m "Adaugă README cu descrierea proiectului"

[main (root-commit) 8f3a1c2] Adaugă README cu descrierea proiectului
 1 file changed, 1 insertion(+)
 create mode 100644 README.md

8f3a1c2 este începutul hash-ului commit-ului — identificatorul lui unic. Îl vei folosi când vrei să te referi la o stare anume.

Al doilea commit și diferențele

Modifică fișierul și adaugă altul:

echo "Proiect de test pentru cursul de Git." >> README.md
echo "console.log('salut');" > index.js
git status

Acum ai două situații diferite: README.md e modified (Git îl urmărea deja), iar index.js e untracked. Înainte să dai add, vezi exact ce s-a schimbat:

git diff

diff --git a/README.md b/README.md
index 9f2a0e1..3c1b7d4 100644
--- a/README.md
+++ b/README.md
@@ -1 +1,2 @@
 # Proiect test
+Proiect de test pentru cursul de Git.

Liniile cu + sunt adăugate, cele cu - sunt șterse. git diff arată ce e modificat dar nestaged. Dacă vrei să vezi ce e deja în staging, folosești git diff --staged. Confuzia dintre cele două e clasică.

Adaugi tot și commiți:

git add .
git commit -m "Adaugă scriptul de intrare și detaliază README"

Atenție la git add .: adaugă tot ce e în folderul curent, inclusiv lucruri pe care nu vrei să le urci. De aceea avem .gitignore.

.gitignore — ce nu urci niciodată

Unele fișiere nu au ce căuta în istoric: dependențe instalate, fișiere de configurare cu parole, fișiere generate, gunoi de la sistemul de operare.

Creezi un fișier .gitignore în rădăcina proiectului:

/node_modules
/vendor
/.env
/storage/*.key
/public/build
.DS_Store
Thumbs.db
*.log

Regula de aur: fișierele cu secrete (.env, chei API, parole) nu ajung niciodată în Git. Odată ce ai commis un secret și ai dat push, consideră-l compromis — istoricul rămâne accesibil chiar dacă ștergi fișierul într-un commit ulterior. Singura reacție corectă e să schimbi cheia.

Important: .gitignore funcționează doar pentru fișiere pe care Git nu le urmărește deja. Dacă ai commis din greșeală .env, trebuie mai întâi să-l scoți din urmărire:

git rm --cached .env
git commit -m "Elimină .env din versionare"

Citirea istoricului

git log

E stufos. Varianta pe care o vei folosi zilnic:

git log --oneline --graph --decorate -10

* 4b7e9a1 (HEAD -> main) Adaugă scriptul de intrare și detaliază README
* 8f3a1c2 Adaugă README cu descrierea proiectului

Merită să îți faci un alias, ca să nu scrii toate opțiunile de fiecare dată:

git config --global alias.lg "log --oneline --graph --decorate -20"
# de acum: git lg

Ca să vezi ce s-a schimbat exact într-un commit:

git show 8f3a1c2

Trimiterea pe GitHub

Creezi pe GitHub un repository gol (fără README, fără .gitignore — le ai deja local, iar altfel vei avea de rezolvat un conflict inutil din prima). Apoi legi repository-ul local de cel remote:

git remote add origin https://github.com/utilizator/proiect-test.git
git branch -M main
git push -u origin main

origin e doar un nume, convenția pentru „remote-ul principal".
-u leagă branch-ul local de cel remote, ca pe viitor să poți scrie doar git push.

Verifici ce remote-uri ai:

git remote -v

Autentificare: parola nu mai merge

GitHub nu mai acceptă parola contului la push. Ai două variante:

Personal Access Token — îl generezi din Settings → Developer settings → Personal access tokens și îl folosești în loc de parolă. Git Credential Manager îl reține.
Cheie SSH — varianta comodă pe termen lung:

ssh-keygen -t ed25519 -C "adresa@exemplu.ro"
cat ~/.ssh/id_ed25519.pub
# copiezi rezultatul în GitHub → Settings → SSH and GPG keys
ssh -T git@github.com

Cu SSH, URL-ul remote arată așa: git@github.com:utilizator/proiect-test.git.

Clonarea unui proiect existent

Când pornești de la un proiect care există deja, nu faci git init, ci:

git clone https://github.com/utilizator/proiect.git
cd proiect

Clonarea aduce tot istoricul și configurează automat origin.

Exercițiu

Creează un repository local nou și fă trei commit-uri cu mesaje corecte.
Adaugă un .gitignore care ignoră node_modules și .env. Creează cele două și verifică cu git status că nu apar.
Publică repository-ul pe GitHub și confirmă că vezi cele trei commit-uri în interfața web.
Rulează git log --oneline --graph și compară cu ce vezi pe GitHub.

Aplicație practică

Sarcina

Inițializează un repository cu README și .gitignore.

Rezolvare orientativă și verificare

Verifică git status înainte de primul commit. Fișierul .env trebuie ignorat, iar .env.example să conțină doar valori demonstrative.

Greșeală de evitat

Adăugarea ulterioară în .gitignore nu șterge un secret din istoric.

Documentație și surse

Pro Git — Git