Git to system nerwowy nowoczesnego IT — kod, infrastruktura, dokumentacja, konfiguracja. Jako lider DevOps nie musisz byc guru, ale MUSISZ rozumiec model: co to commit, branch, merge i dlaczego PR to serce jakosci.
Trzy obszary Git
- **Working directory** — Twoje pliki na dysku, biezaca praca.
- **Staging area (index)** — poczekalnia: co WEJDZIE do nastepnego commita (`git add`).
- **Repozytorium (.git)** — historia commitow (`git commit`).
- **Remote** — kopia na serwerze (GitHub/GitLab), synchro przez `push`/`pull`.
Podstawowy przeplyw
git clone <url> # sklonuj repo
git checkout -b feature # nowa galaz
# ... edytujesz pliki ...
git add plik.py # do staging
git commit -m "opis" # zapis w historii
git push origin feature # wyslij na remote
# -> otwierasz Pull RequestGalezie i merge
**Branch (galaz)** to niezalezna linia pracy. Tworzysz galaz na zadanie, robisz commity, potem scalasz (**merge**) do glownej (main). Dzieki temu praca rownolegla nie psuje stabilnej wersji. **Konflikt** powstaje, gdy dwie galezie zmienily te sama linie — Git prosi Cie o reczne rozstrzygniecie.
| Operacja | Co robi | Kiedy |
|---|---|---|
| merge | Laczy galezie, tworzac commit scalajacy | Zachowanie pelnej historii |
| rebase | Przenosi commity na nowa baze (liniowo) | Czysta, prosta historia |
| pull | fetch + merge z remote | Aktualizacja lokalnej galezi |
| revert | Nowy commit cofajacy zmiany | Bezpieczne cofniecie na wspolnej galezi |
Na wspolnych galeziach uzywaj `revert` (bezpieczne, tworzy nowy commit), a NIE `reset --hard`/force push, ktore przepisuja historie innym. Zlota zasada: nie przepisuj historii, ktora ktos juz pobral.
.gitignore i higiena repo
`.gitignore` mowi Gitowi, czego NIE wersjonowac: sekrety (.env), pliki tymczasowe, artefakty buildu, foldery zaleznosci. **Sekretow nigdy nie commituj** — raz wyslane do remote zyja w historii, nawet po usunieciu.