Kiedy uczyłem się programować, git był jedną z tych rzeczy, które odkładałem “na później”. Pisałem kod, zapisywałem pliki, robiłem kopie folderów nazwane “projekt_v2_final_FINAL”. Brzmi znajomo?

Potem straciłem dwa dni pracy, bo nadpisałem plik. I wtedy nauczyłem się gita. W jeden wieczór. I żałowałem, że nie zrobiłem tego wcześniej.

Git to nie jest trudne narzędzie. Jest źle tłumaczone. Większość tutoriali zaczyna od teorii grafów i DAG-ów. Ty potrzebujesz wiedzieć 5 komend i jeden workflow. Reszta przyjdzie z czasem.

Co to jest git

Git to system kontroli wersji. Zapisuje historię zmian w Twoim kodzie. Każda zmiana (commit) to migawka stanu projektu w danym momencie.

Pomyśl o tym jak o “ctrl+z na sterydach”. Ale zamiast cofać się o jedną zmianę, możesz cofnąć się do dowolnego momentu w historii projektu. Do stanu sprzed minuty, dnia, miesiąca.

Git działa lokalnie (na Twoim komputerze). GitHub, GitLab, Bitbucket to platformy, które hostują Twoje repozytoria w chmurze, żebyś mógł współpracować z innymi i mieć backup.

Git vs GitHub

To nie to samo. Ludzie mylą to cały czas.

Git to narzędzie. Instalujesz je na komputerze, używasz w terminalu. Działa offline.

GitHub to platforma. Hostuje repozytoria git w internecie. Dodaje interfejs webowy, pull requesty, issues, actions. To jak Dropbox dla kodu, ale z supermocami.

Możesz używać gita bez GitHuba. Nie możesz używać GitHuba bez gita.

Instalacja

Mac: brew install git (albo zainstaluj Xcode Command Line Tools)

Linux: sudo apt install git

Windows: pobierz z git-scm.com. Zainstaluj z domyślnymi ustawieniami.

Sprawdź, czy działa: git --version. Jeśli widzisz numer wersji, git jest gotowy.

Skonfiguruj swoje dane (git dopisuje je do każdego commita):

bash

git config --global user.name "Twoje Imię"
git config --global user.email "[email protected]"

5 komend, które musisz znać

Serio, na start potrzebujesz tylko tych pięciu:

git init

Tworzy nowe repozytorium git w aktualnym folderze.

bash

cd moj-projekt
git init

Od tego momentu git śledzi zmiany w tym folderze. Robi to, tworząc ukryty folder .git z całą historią.

git add

Mówi gitowi, które pliki chcesz zapisać w następnym commicie.

bash

git add index.html          # dodaj konkretny plik
git add src/                # dodaj cały folder
git add .                   # dodaj wszystko (uwaga: to dodaje WSZYSTKO)

To jest “staging area”. Wybierasz, co wchodzi do commita, a co nie.

git commit

Zapisuje migawkę projektu z opisem, co zmieniłeś.

bash

git commit -m "dodaj stronę główną"

Każdy commit ma unikalny identyfikator (hash), datę, autora i wiadomość. To jest Twoja historia.

Zasada: commituj często, z krótkimi, opisowymi wiadomościami. Nie “fix” albo “changes”. Raczej “napraw walidację formularza kontaktowego” albo “dodaj dark mode do nawigacji”.

git push

Wysyła Twoje commity na zdalny serwer (np. GitHub).

bash

git push origin main

Od teraz Twój kod jest w chmurze. Masz backup i inni mogą go zobaczyć.

git pull

Pobiera najnowsze zmiany ze zdalnego serwera.

bash

git pull origin main

Używasz tego, kiedy ktoś inny (albo Ty z innego komputera) dodał zmiany do repozytorium.

Podstawowy workflow

Oto cały workflow, którego używam na co dzień:

bash

# 1. Sprawdź status (co się zmieniło?)
git status

# 2. Dodaj zmienione pliki
git add .

# 3. Zapisz zmiany z opisem
git commit -m "dodaj sekcję kontakt do strony głównej"

# 4. Wyślij na GitHub
git push

To tyle. 4 komendy. Powtarzasz ten cykl kilka razy dziennie.

Branche (gałęzie)

Kiedy poczujesz się pewnie z podstawami, następny krok to branche.

Branch to kopia Twojego kodu, na której możesz pracować bez wpływania na główną wersję (main). Chcesz dodać nowy feature? Tworzysz branch, pracujesz, testujesz, a kiedy wszystko działa, łączysz (merge) z main.

bash

# Stwórz nowy branch i przejdź na niego
git checkout -b nowy-feature

# Pracuj, commituj...
git add .
git commit -m "dodaj filtr produktów"

# Wróć na main i połącz
git checkout main
git merge nowy-feature

Dlaczego to ważne? Bo w zespole kilka osób pracuje jednocześnie. Branche pozwalają każdemu pracować niezależnie i łączyć zmiany bez konfliktów (no, prawie bez konfliktów).

W mojej agencji każdy feature to osobny branch. Code review na GitHubie. Merge po akceptacji. Żadne “wrzucam prosto na main”.

GitHub: pierwsza publikacja

Chcesz wrzucić projekt na GitHub? Oto jak:

1. Utwórz konto na github.com
2. Kliknij “New repository”, nazwij je, kliknij “Create”
3. W terminalu, w folderze projektu:

bash

git remote add origin https://github.com/twoj-user/twoj-projekt.git
git push -u origin main

Gotowe. Twój kod jest na GitHubie. Każdy może go zobaczyć (jeśli repo jest publiczne) i masz backup na wypadek awarii dysku.

Dobry profil GitHub to element portfolio programisty. Regularne commity, czyste README, sensowne projekty. To mówi pracodawcy więcej niż lista technologii w CV.

.gitignore

Plik .gitignore mówi gitowi, które pliki ignorować. Nie chcesz commitować plików tymczasowych, zależności (node_modules) ani plików z hasłami (.env).

Przykład .gitignore dla projektu Node.js:

node_modules/
.env
.DS_Store
dist/

Zasada: nigdy nie commituj plików z hasłami, kluczami API i tokenami. Nigdy. Nawet do prywatnego repozytorium. Jak raz coś wrzucisz do gita, to jest tam na zawsze (w historii).

Najczęstsze błędy początkujących

“Commitnąłem coś, czego nie chciałem”. Spokojnie. git reset HEAD~1 cofnie ostatni commit (zmiany zostaną, ale commit zniknie).

“Mam konflikty przy merge”. To normalne. Git oznacza pliki z konfliktami. Otwierasz je, widzisz obie wersje, wybierasz właściwą (lub łączysz ręcznie), commitasz.

“Zapomniałem o .gitignore i wrzuciłem node_modules”. Dodaj .gitignore, potem: git rm -r --cached node_modules i commitnij. Folder zostanie na dysku, ale git przestanie go śledzić.

“Nie wiem, co napisać w commit message”. Opisz CO zrobiłeś i DLACZEGO. Nie jak. “Napraw bug z logowaniem przez Google SSO” jest lepsze niż “fix bug” i lepsze niż “zmień linię 47 w auth.ts”.

Co dalej po podstawach

Kiedy ogarniesz podstawy, warto poznać:

• git stash (schowaj tymczasowe zmiany)
• git rebase (alternatywa dla merge, czystsza historia)
• git log –oneline (przeglądaj historię)
• Pull requesty na GitHubie (code review w zespole)
• GitHub Actions (automatyzacja CI/CD)

Ale to na później. Na teraz: add, commit, push, pull, status. Tych pięć komend wystarczy, żebyś zaczął. Reszty nauczysz się w praktyce.

Git to jedno z tych narzędzi, które raz opanowane, używasz każdego dnia do końca kariery. Warto zainwestować ten jeden wieczór.