Słowniczek
Git (System kontroli wersji)
Git to rozproszony system kontroli wersji (VCS — Version Control System), stworzony w 2005 roku przez Linusa Torvaldsa (twórcę Linuxa). Git śledzi każdą zmianę w plikach projektu, umożliwia cofanie się do dowolnego momentu w historii, pracę równoległą wielu programistów nad tym samym kodem i bezpieczne łączenie ich zmian. Jest absolutnym fundamentem współczesnego tworzenia oprogramowania — używa go ponad 95% profesjonalnych programistów na świecie.
Wyobraź sobie pisanie książki bez „Cofnij” (Ctrl+Z), bez kopii zapasowych, bez możliwości zobaczenia, co zmieniłeś tydzień temu. Wyobraź sobie, że dwóch autorów pisze jednocześnie ten sam rozdział, a potem musisz ręcznie scalić ich wersje. Brzmi jak koszmar? Tak wyglądało programowanie przed systemami kontroli wersji. Git rozwiązuje wszystkie te problemy elegancko i wydajnie.
Geneza Gita — narodziny z frustracji
W 2005 roku Linus Torvalds zarządzał jądrem Linuxa — projektem z tysiącami kontrybutorów i milionami linii kodu. Dotychczas używali BitKeepera (komercyjne narzędzie), ale relacja się zepsuła. Linus, sfrustrowany brakiem odpowiedniego darmowego narzędzia, napisał Gita w ciągu dwóch tygodni. Główne wymagania: szybkość, rozproszony model (bez centralnego serwera), ochrona przed uszkodzeniem danych. 20 lat później Git jest de facto standardem branży, a każdy inny system kontroli wersji jest niszowy.
Kluczowe koncepcje Gita
Repozytorium (repo):
Repozytorium to katalog projektu śledzony przez Gita. Zawiera cały kod źródłowy i pełną historię zmian. Repozytorium lokalne żyje na Twoim komputerze. Repozytorium zdalne (remote) żyje na serwerze (GitHub, GitLab, Bitbucket). Możesz mieć wiele zdalnych repozytoriów — jedno na GitHubie, jedno na firmowym serwerze, jedno jako backup.
Commit:
Commit to „migawka” stanu projektu w danym momencie. Każdy commit zawiera: zestaw zmian (diff), autora, datę, wiadomość opisującą zmianę i unikalny identyfikator (hash SHA-1). To jak punkt zapisu w grze — możesz zawsze wrócić do tego momentu. Dobre commity mają opisowe wiadomości: „Dodaj walidację formularza kontaktowego”, nie „fix” czy „asdf”.
Branch (gałąź):
Branch to niezależna linia rozwoju. Główna gałąź (main/master) to stabilna wersja kodu. Tworzysz branch do nowej funkcjonalności (feature/newsletter), pracujesz na nim bez wpływu na resztę zespołu, a po zakończeniu łączysz (merge) z główną gałęzią. Analogia: branch to brudnopis — piszesz, poprawiasz, a dopiero czystopis (merge) trafia do głównego dokumentu. Możesz mieć 10 branchów jednocześnie — każdy programista pracuje na swoim.
Merge i konflikty:
Merge łączy zmiany z jednego brancha do drugiego. Gdy dwóch programistów zmieni tę samą linię w tym samym pliku — powstaje konflikt. Git nie wie, czyja wersja jest poprawna, więc prosi o ręczne rozstrzygnięcie. Konflikty są normalne, nie katastrofalne — Git jasno pokazuje, co jest sporne, i czeka na Twoją decyzję.
Git vs GitHub — to NIE to samo
Najczęstsze nieporozumienie: Git to narzędzie (program do kontroli wersji, działa lokalnie). GitHub to platforma (hostuje zdalne repozytoria Git w chmurze, dodaje interfejs webowy, pull requesty, issues, CI/CD, społeczność). Git bez GitHuba działa. GitHub bez Gita nie ma sensu. Alternatywy GitHuba: GitLab (self-hosted lub cloud), Bitbucket (Atlassian), Gitea (lekki, self-hosted). Wszystkie używają Gita pod spodem.
Podstawowy workflow Gita
Codzienna praca z Gitem wygląda tak:
git pull— pobierz najnowsze zmiany z serwera (żeby mieć aktualny kod)git checkout -b feature/nowa-funkcja— utwórz nowy branch na swoją pracę- Pisz kod, testuj, poprawiaj
git add .— dodaj zmienione pliki do „poczekalni” (staging area)git commit -m „Dodaj formularz kontaktowy z walidacją”— zapisz migawkęgit push— wyślij zmiany na serwer (GitHub/GitLab)- Otwórz Pull Request (GitHub) lub Merge Request (GitLab) — poproś zespół o code review
- Po zatwierdzeniu: merge do main
Pull Request — serce pracy zespołowej
Pull Request (PR) to prośba o włączenie Twoich zmian do głównej gałęzi. Zawiera: listę commitów, diff (dokładnie, co się zmieniło), opis zmian. Inni programiści przeglądają kod (code review), komentują, sugerują poprawki. Po aprowacie — merge. PR to najskuteczniejszy mechanizm kontroli jakości kodu w zespole. Łapie błędy, dzieli wiedzę i utrzymuje standard kodowania.
Git w kontekście CI/CD
Git jest wyzwalaczem procesów automatycznych. Push na brancha main → automatyczne testy → automatyczny Deployment na produkcję. To CI/CD (Continuous Integration / Continuous Deployment). GitHub Actions, GitLab CI, Jenkins — narzędzia, które reagują na zdarzenia Git (push, merge, tag) i uruchamiają pipeline. Dzięki temu deploy nie jest ręczną operacją, ale automatycznym procesem wyzwalanym przez commit. To fundamentalna zmiana w sposobie tworzenia oprogramowania.
Typowe błędy i pułapki Gita
- Commity typu „fix” — bezwartościowe wiadomości commitów. Za miesiąc nie wiesz, co naprawiono. Pisz opisowo: „Napraw walidację numeru telefonu w formularzu rejestracji”.
- Praca bezpośrednio na main — bez branchów każdy commit ląduje w produkcji. Jeden błąd = awaria dla wszystkich. Zawsze pracuj na branchu, łącz przez PR z code review.
- Force push bez zastanowienia —
git push --forcenadpisuje historię zdalnego repozytorium. Może skasować czyjąś pracę. Używaj--force-with-lease(bezpieczniejsze) i tylko na swoich branchach. - Sekrety w repozytorium — hasła, klucze API, tokeny commitowane do Gita. Nawet po usunięciu pliku, historia Git go pamięta. Używaj
.gitignorei zmiennych środowiskowych (.env) od pierwszego commita. - Gigantyczne commity — commit z 50 zmienionymi plikami i 2000 liniami kodu jest niemożliwy do code review. Rób małe, atomowe commity — jedna zmiana logiczna = jeden commit.
Git to rozproszony system kontroli wersji — narzędzie, które śledzi każdą zmianę w plikach projektu, umożliwia cofanie się do dowolnego momentu w historii, pracę równoległą wielu programistów i bezpieczne łączenie ich zmian. Stworzony w 2005 roku przez Linusa Torvaldsa (twórcę Linuxa), jest używany przez ponad 95% profesjonalnych programistów. Analogia: Git to jak „Track Changes” w Wordzie, ale dla całego projektu — każda zmiana jest zapisana z datą, autorem i opisem. Możesz cofnąć się do stanu sprzed tygodnia lub roku. To fundament współpracy zespołowej w tworzeniu oprogramowania.
Git to narzędzie (program do kontroli wersji) — działa lokalnie na Twoim komputerze, śledzi zmiany, zarządza branchami. GitHub to platforma hostingowa w chmurze, która przechowuje zdalne repozytoria Git i dodaje interfejs webowy, pull requesty (code review), issues (śledzenie zadań), CI/CD (automatyczne testy i deploy), profil programisty i społeczność open-source. Git bez GitHuba działa doskonale. GitHub bez Gita nie ma sensu. Alternatywy GitHuba: GitLab (popularne self-hosted), Bitbucket (Atlassian, integracja z Jira), Gitea (lekki, darmowy). Wszystkie używają Gita pod spodem — różnią się platformą i funkcjami dodatkowymi.
Branch (gałąź) to niezależna linia rozwoju kodu. Tworzysz branch do nowej funkcjonalności (np. feature/newsletter), pracujesz na nim bez wpływu na resztę zespołu, a po zakończeniu łączysz z główną gałęzią. To jak brudnopis — piszesz, poprawiasz, dopiero czystopis trafia do głównego dokumentu. Pull Request (PR) to prośba o włączenie zmian z Twojego brancha do głównej gałęzi. Zawiera listę commitów, diff (co się zmieniło) i opis. Inni programiści przeglądają kod (code review), komentują, sugerują poprawki. Po aprowacie — merge do main. PR to najskuteczniejszy mechanizm kontroli jakości kodu w zespole.
Krok po kroku: (1) Zainstaluj Git (git-scm.com, na Macu jest wbudowany). (2) Skonfiguruj: git config --global user.name „Twoje imię” i git config --global user.email „email”. (3) W katalogu projektu: git init (tworzy repozytorium). (4) Dodaj pliki: git add . (5) Pierwszy commit: git commit -m „Initial commit”. (6) Załóż konto na GitHub, utwórz repozytorium, połącz: git remote add origin URL. (7) Wyślij: git push -u origin main. Od tego momentu masz pełną historię zmian i backup w chmurze. Naucz się jeszcze: branching, merge, pull request — to codzienny workflow.
Konflikt powstaje, gdy dwóch programistów zmieni tę samą linię w tym samym pliku i próbujesz je scalić (merge). Git nie wie, czyja wersja jest poprawna — oznacza sporne sekcje znacznikami (<<<<<<<, =======, >>>>>>>). Rozwiązanie: (1) otwórz plik z konfliktem, (2) znajdź oznaczone sekcje, (3) zdecyduj, która wersja jest poprawna (albo połącz obie), (4) usuń znaczniki, (5) zapisz, git add, git commit. Konflikty są normalne i nie są katastrofą — to naturalny efekt pracy zespołowej. Nowoczesne edytory (VS Code, Cursor) mają wbudowane narzędzia do wizualnego rozwiązywania konfliktów, co znacząco upraszcza proces.