Git to fundament nowoczesnego tworzenia oprogramowania. System kontroli wersji pozwala śledzić każdą zmianę w kodzie źródłowym, co jest niezbędne przy pracy zespołowej. Rozproszona architektura oznacza, że każde repozytorium jest pełną kopią całości historii – nie ma jednego centralnego punktu awarii. Dzięki Gitowi możesz eksperymentować na osobnych gałęziach bez ryzyka popsucia stabilnej wersji projektu. W przeciwieństwie do starszych systemów jak SVN czy CVS, Git działa w większości lokalnie, co czyni go błyskawicznym. Linus Torvalds stworzył Gita w 2005 roku po tym, jak społeczność jądra Linuxa straciła dostęp do darmowego systemu BitKeeper. Od tego czasu Git stał się standardem branżowym – używają go giganci jak Google, Microsoft, Facebook czy Netflix. Nawet projekty jednoosobowe korzystają z Gita, ponieważ daje możliwość błyskawicznego powrotu do dowolnego momentu w historii. Zrozumienie Gita to inwestycja, która zwraca się wielokrotnie w trakcie całej kariery programisty. Ta prezentacja przeprowadzi Cię krok po kroku przez wszystkie kluczowe komendy i scenariusze użycia.

Instalacja Gita jest pierwszym krokiem do kontroli wersji. Na systemie Windows najlepiej pobrać instalator z oficjalnej strony git-scm.com – zawiera on zarówno Git Bash (emulator terminala Unix), jak i integrację z PowerShell. Podczas instalacji warto zaznaczyć opcję dodania Gita do zmiennej PATH, aby móc go wywoływać z dowolnego terminala. Na dystrybucjach Linuxa Git jest dostępny w domyślnych repozytoriach – wystarczy polecenie apt install git (Debian/Ubuntu) lub dnf install git (Fedora). Użytkownicy macOS mogą skorzystać z Homebrew (brew install git) lub dołączonego Xcode Command Line Tools, który zawiera Gita. Po instalacji zawsze warto sprawdzić wersję poleceniem git --version, aby upewnić się, że instalacja przebiegła poprawnie. Git aktualizuje się stosunkowo często, więc warto od czasu do czasu sprawdzać, czy używamy najnowszej stabilnej wersji. W systemie Linux git --version może pokazać starszą wersję z repozytoriów – wtedy można dodać oficjalne PPA lub skompilować ze źródeł. Dla początkujących polecam Git Bash na Windows lub terminal z kolorowaniem składni na Linux/macOS. Po udanej instalacji możesz przejść do konfiguracji swojej tożsamości, co jest niezbędne przed pierwszym commitem.

Konfiguracja tożsamości jest obowiązkowa – Git podpisuje każdy commit Twoim imieniem i adresem email. Bez tych ustawień Git odmówi wykonania commita, wyświetlając komunikat z prośbą o konfigurację. Polecenie git config pozwala ustawić nazwę użytkownika (user.name) i adres email (user.email), które będą widoczne w historii projektu. Dane te są zapisywane w pliku ~/.gitconfig (globalnie) lub .git/config (lokalnie dla repozytorium). Flaga --global oznacza, że ustawienia dotyczą wszystkich repozytoriów na Twoim komputerze, co jest zalecane dla jednolitości. W każdej chwili możesz sprawdzić aktualną konfigurację komendą git config --list, która pokazuje wszystkie ustawienia. Możesz też edytować plik konfiguracyjny bezpośrednio poleceniem git config --global --edit, które otwiera go w domyślnym edytorze. W repozytoriach firmowych często używa się lokalnej konfiguracji (bez --global), aby oddzielić pracę zawodową od prywatnej. Git obsługuje także wiele innych ustawień, jak edytor domyślny (core.editor) czy narzędzie do rozwiązywania konfliktów (merge.tool). Prawidłowa konfiguracja na starcie oszczędza późniejszych problemów z przypisaniem autorstwa commitów.

Zrozumienie trzech obszarów Gita to klucz do sprawnego posługiwania się tym narzędziem. Obszar roboczy (Working Directory) to zwykłe pliki na dysku, które edytujesz w swoim IDE lub edytorze tekstu. Staging Area (inaczej indeks lub poczekalnia) to pośrednia strefa, w której przygotowujesz zmiany przed zatwierdzeniem. Repozytorium (.git) to miejsce, gdzie Git przechowuje całą historię projektu – wszystkie commity, gałęzie i tagi. Proces pracy wygląda następująco: edytujesz pliki w WD, dodajesz wybrane zmiany do stagingu (git add), a następnie zatwierdzasz staging (git commit). Staging area to unikalna cecha Gita – pozwala wybrać tylko część zmodyfikowanych plików do następnego commita. Dzięki temu możesz podzielić większą pracę na logiczne, czytelne commity. Nawet jeśli zmieniłeś pięć plików, możesz dodać tylko trzy z nich do pierwszego commita. Trzy obszary to koncepcja, która na początku bywa myląca, ale po kilku commitach staje się naturalna. W praktyce najczęściej używasz git add, potem git status, aby zobaczyć co czeka w stagingu, a na końcu git commit. Zapamiętaj: WD → staging → repozytorium – ten przepływ to esencja Gita.

Polecenie git init to pierwsza komenda w każdym nowym projekcie – tworzy puste repozytorium Gita w bieżącym katalogu. Po wydaniu tego polecenia Git tworzy ukryty katalog .git, który zawiera wszystkie struktury niezbędne do kontroli wersji. Wewnątrz .git znajdują się kluczowe podkatalogi: objects/ (przechowuje wszystkie dane – commity, drzewa, pliki), refs/ (gałęzie, tagi) oraz plik HEAD (wskaźnik na aktywną gałąź). Do poprawnego działania Gita nie trzeba zaglądać do .git – wszystkie interakcje odbywają się przez komendy. Jeśli kiedykolwiek chcesz usunąć repozytorium (utracić historię), wystarczy skasować folder .git – reszta plików pozostanie nienaruszona. W istniejącym projekcie możesz w dowolnym momencie zainicjalizować Gita – git init nie kasuje żadnych plików. Po inicjalizacji wszystkie pliki są śledzone jako untracked – musisz je dodać i zatwierdzić. Częstym błędem jest inicjalizacja Gita w katalogu domowym lub na pulpicie – zawsze twórz osobny folder dla projektu. git init to odpowiednik założenia nowego notesu – na razie pustego, gotowego do zapisywania historii. Od tego momentu każdą zmianę możesz rejestrować w formie commitów.

Cykl życia plików w Git opisuje cztery stany, przez które przechodzi każdy plik w projekcie. Untracked (nieśledzony) to plik, który istnieje na dysku, ale Git go nie monitoruje – pojawia się w git status jako nowy plik. Tracked (śledzony) oznacza, że Git już widzi ten plik i będzie śledził jego zmiany – plik trafia do tego stanu po git add. Modified (zmodyfikowany) to plik śledzony, który został zmieniony, ale zmiany nie zostały jeszcze dodane do stagingu. Staged (przygotowany) to plik, którego zmiany czekają w poczekalni na zatwierdzenie. Cykl wygląda tak: tworzysz plik (untracked) → dodajesz go (git add) → plik staje się staged → zatwierdzasz (git commit) → plik jest czysty (unmodified) → edytujesz go (modified) → dodajesz zmiany (staged) → zatwierdzasz... i tak dalej. git status to narzędzie, które w każdej chwili pokaże Ci, w jakim stanie są Twoje pliki. Zrozumienie tego cyklu pozwala uniknąć sytuacji, w której nie możesz znaleźć swoich zmian. Na przykład git diff pokazuje tylko zmiany w plikach modified (przed dodaniem), a git diff --cached pokazuje zmiany w stagingu. Zapamiętaj: untracked → staged → committed – to trzy kluczowe stany typowe dla nowego pliku.

git status to najczęściej używane polecenie w Git – pokazuje aktualny stan repozytorium w czytelnej formie. Gdy nie ma żadnych zmian, status informuje, że drzewo robocze jest czyste (nothing to commit, working tree clean). Jeśli są zmiany, status dzieli je zazwyczaj na trzy kategorie: zmiany staged (zielone), zmiany unstaged (czerwone, ale śledzone) oraz nowe pliki (untracked). Kolorowanie pomaga szybko zrozumieć, co się dzieje – zielone czeka w kolejce do commita, czerwone jeszcze nie zostało dodane. git status wyświetla także przydatne podpowiedzi, jak np. użycie git restore --staged do cofnięcia dodania pliku. W nowszych wersjach Gita komenda status jest zoptymalizowana tak, by działać błyskawicznie nawet w ogromnych repozytoriach. W codziennej pracy wpisuj git status przed każdym add (aby sprawdzić co zmieniłeś) i przed każdym commit (aby potwierdzić co zatwierdzasz). Istnieje skrócona wersja git status -s (short), która pokazuje te same informacje w bardziej zwięzłej formie, przydatnej w skryptach. Dla początkujących standardowe git status z pełnymi opisami jest znacznie czytelniejsze. Wpisz git status dziesiątki razy dziennie – to normalne i świadczy o dobrej praktyce.

git add to komenda, która przenosi zmiany z obszaru roboczego do staging area (poczekalni). Pozwala ona precyzyjnie wybrać, które pliki (a nawet które fragmenty plików) mają trafić do następnego commita. Najprostsza forma git add nazwa_pliku dodaje cały wskazany plik, jeśli był zmodyfikowany. git add . dodaje wszystkie zmiany w bieżącym katalogu i podkatalogach, w tym modyfikacje, nowe pliki i usunięcia. git add -A (--all) robi to samo, ale w całym repozytorium, niezależnie od bieżącego katalogu. Zaawansowana opcja git add -p (--patch) pozwala interaktywnie wybrać pojedyncze fragmenty (hunk) w pliku do dodania. Jest to niezwykle przydatne, gdy masz w jednym pliku dwie niezależne zmiany i chcesz je zatwierdzić osobno. git add -i (--interactive) uruchamia interaktywny tryb z menu wyboru. Pamiętaj, że git add nie zatwierdza zmian – to tylko przygotowanie. Jeśli zapomnisz dodać jakiś plik przed commitem, użyj git commit --amend, aby dołączyć go do poprzedniego commita (ale tylko lokalnie). git add to jeden z najważniejszych nawyków – dodawaj zmiany małymi partiami, a commit będziesz robić z czystym sumieniem.

git commit tworzy trwały punkt w historii projektu – migawkę wszystkich plików znajdujących się w staging area. Każdy commit ma unikalny identyfikator SHA-1 (40-znakowy hash) wyliczany kryptograficznie z zawartości, metadata i rodzica. Flaga -m pozwala dodać wiadomość commita bezpośrednio w linii polecenia: git commit -m "wiadomość". Dobra wiadomość commita powinna być zwięzła, ale opisowa – pierwsza linia do 50 znaków, potem pusta linia i szczegóły. git commit -a (lub --all) pomija staging i zatwierdza wszystkie zmiany w śledzonych plikach – ale nowe pliki (untracked) nie zostaną uwzględnione. git commit --amend modyfikuje ostatni commit – możesz dodać zapomniane zmiany lub poprawić wiadomość, ale zmienia to hash commita. Commity powinny być małe i logicznie spójne – jedna zmiana = jeden commit, a nie jeden commit = tydzień pracy. Częste commity ułatwiają późniejsze znajdowanie błędów (git bisect) i czytanie historii. W zespole warto ustalić konwencję nazewnictwa commitów, np. Conventional Commits (feat:, fix:, chore:). Każdy commit to krok w ewolucji projektu – im kroki mniejsze i czytelniejsze, tym łatwiej się pracuje.

git log to narzędzie do przeglądania historii commitów w repozytorium. Bez opcji pokazuje wszystkie commity od najnowszego do najstarszego – każdy z SHA, autorem, datą i wiadomością. git log --oneline skraca każdy wpis do pierwszych 7 znaków hasha i wiadomości – idealne do szybkiego przeglądu. git log --graph wyświetla historię w formie grafu ASCII, pokazując gałęzie i ich scalenia. git log --decorate dołącza informacje o gałęziach i tagach wskazujących na dane commity. git log --all pokazuje historię wszystkich gałęzi, nie tylko aktualnej. Połączenie tych opcji: git log --oneline --graph --decorate --all to ulubiona komenda wielu programistów – daje pełny obraz repozytorium w jednym widoku. git log --author="nazwa" filtruje commity autora, a git log --since="2024-01-01" pokazuje tylko commity od określonej daty. git log --grep="wyrażenie" szuka commitów po treści wiadomości. git log może też pokazać zmiany w poszczególnych commitach (git log -p) lub statystyki (git log --stat). Znajomość git log jest niezbędna do efektywnego poruszania się po historii projektu i znajdowania konkretnych zmian.

git diff to komenda służąca do porównywania zmian między różnymi stanami repozytorium. Bez argumentów pokazuje niezatwierdzone zmiany – różnicę między obszarem roboczym (WD) a staging area. git diff --cached (lub --staged) pokazuje zmiany, które już są w stagingu, ale jeszcze nie zostały skomitowane. git diff HEAD pokazuje wszystkie zmiany od ostatniego commita – zarówno staged, jak i unstaged. Możesz porównywać konkretne commity: git diff abc123..def456 pokazuje różnice między dwoma commitami. git diff --color-words pokazuje zmiany na poziomie słów, nie linii – znacznie czytelniejsze przy zmianach w tekście. git diff --stat wyświetla tylko statystyki (które pliki i ile linii zmieniono). Warto używać git diff przed każdym commit, aby przejrzeć zmiany i upewnić się, że nie zostawiasz przypadkowego kodu. W połączeniu z git add -p możesz przeglądać i zatwierdzać zmiany partiami. Istnieją zewnętrzne narzędzia diff (jak meld, kdiff3), które można zintegrować z Gitem. git diff jest nieocenione przy code review – pozwala szybko zrozumieć, co dokładnie zmienił współpracownik w swoim branchu.

Slajd praktyczny – pierwsze kroki z rzeczywistym projektem. Zaczynamy od inicjalizacji repozytorium komendą git init i sprawdzenia stanu przez git status. Tworzymy pierwszy plik (np. index.html) – Git widzi go jako untracked. Dodajemy plik do stagingu przez git add, a następnie zatwierdzamy pierwszym commitem. Po commicie warto od razu otagować wersję – git tag v0.1, aby móc do niej wrócić. Tagi są lekkimi wskaźnikami i nie obciążają repozytorium. Zawsze sprawdzaj git status przed i po każdej operacji – to buduje nawyk świadomego korzystania z Gita. git log teraz pokaże jeden commit, który jest początkiem Twojej historii. Ten proces zakładania projektu jest uniwersalny: init → add → commit → tag. Bez względu na to, czy piszesz stronę, aplikację mobilną czy skrypt, schemat jest identyczny. Pierwsze kroki są najważniejsze – gdy już wykonasz je kilka razy, staną się automatyczne. Cały dalszy ciąg pracy z Gitem opiera się na tej podstawowej pętli: edytuj → add → commit.

Wersja v0.2 rozszerza projekt o plik CSS, co wymusza użycie git diff w praktyce. Przed dodaniem pliku warto sprawdzić, co się zmieniło od ostatniego commita – git diff bez argumentów pokaże różnice w plikach śledzonych. Nowy plik (style.css) jest początkowo untracked – git diff go nie pokaże, dopiero git add --dry-run może zasymulować dodanie. Po dodaniu do stagingu używamy git diff --cached, aby podejrzeć zmiany czekające na commit. W tej wersji ćwiczymy też tworzenie tagów adnotowanych (git tag -a v0.2 -m "opis") z pełną wiadomością. Tagi adnotowane przechowują informacje o autorze, dacie i opisie – w przeciwieństwie do lekkich, które są tylko wskaźnikami. git diff między wersją v0.1 a v0.2 pokaże dokładnie, co dodaliśmy: nowy plik CSS i link do niego w HTML. Systematyczne tagowanie wersji to dobry nawyk – ułatwia późniejsze wydawanie kolejnych wersji. W repozytorium możesz w każdej chwili porównać dowolne dwie wersje: git diff v0.1 v0.2. To pokazuje, jak Git chroni każdy krok ewolucji Twojego projektu.

Wersja v0.3 pokazuje rozwijanie projektu i użycie git add -A do dodania wszystkich zmian. Kiedy pracujesz nad wieloma plikami, git add -A (--all) jest wygodne – dodaje modyfikacje, nowe pliki i usunięcia z całego repozytorium. git status przed add i po add to standardowa procedura – warto ją wykonywać, aby nie dać się zaskoczyć. git diff przed commitem pozwala zobaczyć wszystkie zmiany, które zaraz zostaną zatwierdzone. Wprowadzamy teraz istotne zmiany – np. dodajemy treść strony, nawigację, stopkę. W prawdziwym projekcie commity powinny być małe i tematyczne – osobno dodanie treści, osobno zmiana stylów. Po tagowaniu v0.3 mamy już trzy wyraźne kamienie milowe w historii: v0.1 (szkielet), v0.2 (styl), v0.3 (treść). git log --oneline --graph --decorate --all pokaże wszystkie tagi i commity w czytelnej formie. System tagowania pozwala w każdej chwili wrócić do dowolnej wersji – git checkout v0.1 przywróci projekt do pierwotnego stanu. Praktyka z wersjami uczy, jak ważne jest regularne zatwierdzanie i oznaczanie postępów w projekcie.

Wersja v0.4 finalizuje czteroczęściowy cykl rozwojowy projektu. Mamy teraz cztery otagowane wersje, co stanowi pełną historię ewolucji. Dzięki tagom możesz skoczyć do dowolnej wersji komendą git checkout v0.1, v0.2 itd. git log z tagami i grafem daje pełny obraz rozwoju projektu od inicjalizacji po wersję finalną. W prawdziwym projekcie między v0.1 a v0.4 mogą być dziesiątki lub setki commitów. To pokazuje, jak Git radzi sobie nawet z ogromną historią bez spadku wydajności. W każdej chwili możesz dodać kolejną wersję – v0.5, v1.0 itd. – i kontynuować rozwój. Tagi można wypchnąć na GitHub (git push --tags), aby były dostępne dla całego zespołu. W repozytoriach open source tagi odpowiadają oficjalnym wydaniom (release). System wersjonowania jest elastyczny – możesz używać SemVer (v1.0.0, v1.1.0) lub własnej konwencji. Ten prosty czterokrokowy przykład pokazuje, jak Git organizuje pracę nad projektem w uporządkowany, przewidywalny sposób. Historia Twojego projektu staje się czytelna dla Ciebie i każdego, kto dołączy do zespołu.

Usuwanie plików w Git wymaga zrozumienia różnicy między rm a git rm. Zwykłe rm (lub usunięcie przez system plików) po prostu kasuje plik z dysku – Git widzi to jako modyfikację (usunięcie) w obszarze roboczym. Następnie trzeba ręcznie wykonać git add, aby zatwierdzić to usunięcie w stagingu. git rm robi to samo w jednym kroku – usuwa plik z dysku i od razu dodaje usunięcie do stagingu. Opcja git rm --cached usuwa plik tylko ze stagingu, ale pozostawia go na dysku – przydatne, gdy dodałeś plik przez przypadek. git rm -r (rekurencyjnie) usuwa cały katalog i jego zawartość. W codziennej pracy wybór między rm + git add a git rm to kwestia wygody – obie metody prowadzą do tego samego rezultatu. Ważne: jeśli plik został już skomitowany, samo git rm nie usunie go z historii – Git przechowuje go na zawsze (chyba że przepiszesz historię). Aby całkowicie usunąć plik z repozytorium, potrzebne są zaawansowane narzędzia jak git filter-branch lub BFG Repo-Cleaner. Usunięcie pliku to też zmiana, więc pojawi się w git log i będzie widoczne w historii. Świadomość, że Git pamięta wszystko, pomaga podejmować lepsze decyzje o tym, co commitować.

Czasami zdarza się, że dodasz plik do stagingu przez przypadek – na przykład plik konfiguracyjny z hasłami. git restore --staged usuwa plik ze staging area, ale zostawia zmiany w obszarze roboczym – czyli cofa efekt git add. W starszych wersjach Gita używano do tego git reset HEAD nazwa_pliku, ale git restore jest nowszym, bardziej intuicyjnym poleceniem. Po wykonaniu git restore --staged plik wraca do stanu modified (jeśli był już śledzony) lub untracked (jeśli był nowy). git restore --staged --worktree (lub --source=HEAD --staged --worktree) usuwa plik ze stagingu i przywraca wersję z ostatniego commita – tracisz lokalne zmiany, więc używaj ostrożnie. Zanim wykonasz git restore, możesz sprawdzić git diff --cached, aby zobaczyć, co dokładnie znajduje się w stagingu. Operacja cofnięcia dodania jest bezpieczna, ponieważ zmiany w pliku nie są tracone – pozostają w obszarze roboczym. Jeśli potrzebujesz całkowicie odrzucić zmiany i przywrócić plik do stanu z ostatniego commita, użyj git restore bez --staged (ale to nieodwracalne bez kopii zapasowej). git status zawsze podpowiada właściwe polecenie do cofnięcia operacji. Znajomość tych mechanizmów buduje pewność siebie – nawet jeśli popełnisz błąd, Git daje narzędzia do jego naprawy.

Jeśli po commicie zorientujesz się, że czegoś brakuje lub wiadomość jest błędna, git commit --amend przychodzi z pomocą. --amend modyfikuje ostatni commit – możesz dodać zapomniane pliki (git add + git commit --amend) lub poprawić wiadomość (git commit --amend -m "nowa"). Ważne: --amend tworzy nowy commit z nowym hash SHA-1, zastępując poprzedni. Oznacza to przepisywanie historii – jest bezpieczne tylko lokalnie, przed wypchnięciem na zdalne repozytorium. Jeśli już wykonałeś git push, nie używaj --amend – zmusiłoby to do git push --force, co może zdezorganizować pracę zespołu. Innym przypadkiem jest commit, w którym przypadkowo znalazł się plik z sekretami (hasła, klucze API). Sam --amend nie usunie go całkowicie – stary commit nadal istnieje w lokalnym repozytorium i zostanie wypchnięty przy pushu. Aby całkowicie usunąć wrażliwy plik z historii, potrzebne są narzędzia jak git filter-branch. W codziennej pracy --amend jest bezpieczny, jeśli używasz go z rozwagą i tylko lokalnie. To doskonałe narzędzie do korekty ostatniego commita bez zaśmiecania historii drobnymi poprawkami. Pamiętaj: im szybciej po commicie użyjesz --amend, tym lepiej – zmniejszasz ryzyko, że ktoś zdąży zrobić git pull.

git restore to nowoczesne polecenie (od Gita 2.23) do przywracania plików do wcześniejszego stanu. Bez opcji git restore nazwa_pliku przywraca plik z ostatniego commita, nadpisując lokalne zmiany – operacja potencjalnie niebezpieczna, bo tracisz niezapisane modyfikacje. git restore --staged nazwa_pliku usuwa plik ze stagingu (odpowiednik starego git reset HEAD). git restore --source=v0.1 nazwa_pliku przywraca plik z konkretnego commita lub taga. Możesz też przywrócić konkretny katalog: git restore --source=v0.2 src/. git restore --worktree (domyślne) przywraca pliki w obszarze roboczym, a --staged – w stagingu. Przed git restore warto wykonać git diff, aby zobaczyć, co stracisz. Jeśli nie jesteś pewien zmian, skopiuj plik ręcznie lub użyj git stash. git restore jest bezpieczniejsze od starego git checkout do plików, bo ma oddzielną składnię od przełączania gałęzi. W nowych wersjach Gita git restore i git switch zastępują wiele zastosowań git checkout, co zmniejsza ryzyko pomyłki. git restore daje precyzyjną kontrolę nad tym, który obszar (staging, worktree) i z jakiego źródła (commita, gałęzi, taga) chcesz przywrócić. Dzięki niemu możesz w każdej chwili wycofać niechciane zmiany bez paniki.

git checkout to starsze, wielozadaniowe polecenie, które służyło zarówno do przywracania plików, jak i przełączania gałęzi. git checkout nazwa_pliku przywraca plik z ostatniego commita – to samo co git restore nazwa_pliku. git checkout v0.1 przełącza repozytorium w stan detached HEAD – wskaźnik HEAD nie jest już na gałęzi, ale bezpośrednio na commicie. Detached HEAD oznacza, że commity wykonane w tym stanie nie są przypisane do żadnej gałęzi – jeśli przełączysz się na inną gałąź, te commity staną się trudno dostępne. Aby je zachować, musisz utworzyć nową gałąź: git checkout -b nowa_gałąź. W praktyce detached HEAD jest przydatne do testowania starszej wersji projektu bez tworzenia dodatkowej gałęzi. git checkout -b nowa_gałąź tworzy nową gałąź i od razu na nią przełącza – to skrót dla git branch + git checkout. Od wersji Git 2.23 zaleca się używanie git switch do przełączania gałęzi i git restore do plików, ale git checkout wciąż działa. Wiele starszych tutoriali i skryptów używa git checkout, więc znajomość tego polecenia jest niezbędna. git checkout -- . (z kropką) przywraca wszystkie pliki w bieżącym katalogu – bardzo niebezpieczne, jeśli nie chcesz stracić zmian. Zawsze wykonaj git diff przed git checkout, aby upewnić się, co nadpisujesz.

git revert to najbezpieczniejszy sposób cofania zmian – tworzy nowy commit, który jest przeciwieństwem wskazanego commita. Na przykład git revert abc123 tworzy nowy commit, który cofa wszystkie zmiany wprowadzone w commicie abc123. Zaleta: nie zmienia istniejącej historii – stare commity pozostają nienaruszone, a nowy commit dokumentuje fakt cofnięcia. To kluczowe w repozytoriach zespołowych, gdzie historia powinna być niezmienialna. git revert działa na poziomie pojedynczego commita – możesz cofnąć jeden commit, nie naruszając pozostałych. Jeśli potrzebujesz cofnąć zakres commitów: git revert OLD..NEW (starszy..nowszy). W przypadku konfliktu git revert zatrzyma się i poprosi o rozwiązanie – po rozwiązaniu użyj git revert --continue. Możesz też przerwać: git revert --abort. git revert --no-commit (lub -n) wprowadza zmiany, ale nie tworzy commita – przydatne, gdy chcesz cofnąć wiele commitów i zatwierdzić wszystko razem. W przeciwieństwie do git reset, revert jest bezpieczny po git push – nie wymaga --force. To idealne narzędzie do produkcji: znalazłeś błąd w commicie z zeszłego tygodnia? Zrób git revert i gotowe. git reset jest jak wehikuł czasu zmieniający przeszłość, a git revert to anulowanie zamówienia z zachowaniem paragonu – oba skuteczne, ale revert jest bezpieczniejszy.

git reset to potężne, ale potencjalnie niebezpieczne polecenie do cofania zmian – przesuwa wskaźnik gałęzi i opcjonalnie modyfikuje staging i obszar roboczy. Działa na trzech poziomach: --soft (miękki), --mixed (domyślny) i --hard (twardy). git reset --soft HEAD~1 cofa ostatniego commita, ale pozostawia zmiany w stagingu – jakbyś nigdy nie zrobił commita. git reset --mixed HEAD~1 (domyślny) cofa commita i usuwa zmiany ze stagingu, ale pozostawia je w obszarze roboczym. git reset --hard HEAD~1 cofa commita i całkowicie usuwa zmiany – zarówno ze stagingu, jak i z dysku. To nieodwracalne bez kopii zapasowej! git reset może też cofnąć do konkretnego commita: git reset --hard abc123. --hard jest przydatne, gdy chcesz całkowicie porzucić lokalne zmiany i wrócić do znanego stanu. Po git reset --hard możesz odzyskać commity tylko przez git reflog, który przechowuje historię ruchów HEAD. git reset jest bezpieczne tylko lokalnie – nigdy nie resetuj commitów, które zostały już wypchnięte na GitHub. W przypadku zdalnego repozytorium użyj git revert zamiast reset. W praktyce git reset --mixed HEAD~1 (lub bez --mixed) jest codziennym narzędziem do "rozcommitowania" ostatniej zmiany. git reset --hard wymaga absolutnej pewności – gdy mówi się "Git nie może niczego odzyskać po --hard", to tylko reflog Cię ratuje.

GitHub to najpopularniejsza platforma hostingowa dla repozytoriów Git, przejęta przez Microsoft w 2018 roku. Oferuje zdalne przechowywanie kopii repozytorium oraz szereg narzędzi społecznościowych. Pull requesty (PR) to mechanizm proponowania zmian – tworzysz gałąź, robisz zmiany i zgłaszasz PR do dyskusji. GitHub Actions umożliwia automatyzację: testowanie, budowanie i wdrażanie kodu po każdym pushu. Issues to system zgłaszania błędów i śledzenia postępu prac – każdy issue można przypisać, otagować i połączyć z PR. GitHub Pages pozwala hostować statyczne strony internetowe bezpośrednio z repozytorium. Wiki, projekty (Kantban), GitHub Discussions i Code Review to kolejne funkcje wspierające rozwój oprogramowania. Dla studentów i projektów open source GitHub oferuje darmowe plany z bogatym zestawem funkcji. Bez GitHub współpraca zdalna byłaby znacznie trudniejsza – to centralne miejsce, gdzie kod jest przechowywany, recenzowany i rozwijany. W praktyce GitHub to znacznie więcej niż tylko hosting – to cały ekosystem wokół kontroli wersji. Umiejętność korzystania z GitHub jest dziś jedną z podstawowych kompetencji każdego programisty.

Tworzenie repozytorium na GitHubie to pierwszy krok do zdalnej współpracy. Na stronie github.com klikasz przycisk "New" i podajesz nazwę repozytorium. Możesz dodać opis i wybrać, czy ma być publiczne (widoczne dla wszystkich) czy prywatne. Ważne: gdy masz już lokalne repozytorium, nie zaznaczaj "Initialize this repository with a README" – to by utworzyło osobny commit i skomplikowało łączenie. Po utworzeniu GitHub pokazuje instrukcje: git remote add origin i git push -u origin main. Jeśli przypadkowo utworzysz repozytorium z README, użyj git pull --rebase origin main, aby scalić bez zbędnego commita merge. Nazwa gałęzi domyślnej to od 2021 roku "main" (wcześniej "master"). Możesz zmienić domyślną nazwę w ustawieniach GitHub. W repozytorium prywatnym tylko zaproszeni współpracownicy widzą kod – idealne dla projektów komercyjnych. Publiczne repozytoria są widoczne dla wszystkich – świetne do portfolio i open source. Po utworzeniu repozytorium możesz zarządzać nim przez interfejs webowy, API lub GitHub CLI (gh). W każdej chwili możesz usunąć repozytorium w ustawieniach (Settings → Danger Zone → Delete this repository).

Personal Access Token to obecnie standardowa metoda autentykacji do GitHub, zastępująca hasła i klucze SSH. Hasła nie są już akceptowane przy pushu – GitHub wymaga tokena lub klucza SSH. Token generujesz w GitHub: Settings → Developer settings → Personal access tokens → Tokens (classic). Wybierasz zakres uprawnień (scope): repo (dostęp do repozytoriów), workflow (do Actions) itp. Token jest wyświetlany tylko raz przy generowaniu – skopiuj go i przechowuj bezpiecznie. Możesz go użyć jako hasła przy git push – Git zapamięta je w cache: git config --global credential.helper cache. Tokeny mają datę ważności – po wygaśnięciu musisz wygenerować nowy. Możesz tworzyć wiele tokenów z różnymi uprawnieniami np. osobny do CI/CD, osobny do skryptów. W razie wycieku tokena możesz go natychmiast unieważnić na GitHubie. Alternatywą są klucze SSH (git@github.com:user/repo.git), które są bezpieczniejsze dla stałych połączeń, ale tokeny są wygodniejsze w zarządzaniu. Dla GitHub CLI (gh auth login) token jest konfigurowany automatycznie. W środowisku korporacyjnym często używa się GitHub App lub OAuth Apps zamiast osobistych tokenów. Token to dziś standard – bez niego nie wypchniesz kodu na GitHub.

git remote add origin URL łączy lokalne repozytorium z repozytorium na GitHubie. "origin" to domyślna nazwa zdalnego repozytorium (możesz użyć dowolnej, ale origin to konwencja). git remote -v pokazuje wszystkie zdalne repozytoria i ich URL-e dla push i fetch. Możesz mieć wiele remote'y: origin (twój fork), upstream (oryginalne repo w open source). git remote add upstream URL dodaje drugie zdalne repozytorium – przydatne, gdy chcesz synchronizować fork z oryginałem. git remote remove nazwa usuwa zdalne połączenie. git remote set-url origin NOWY_URL zmienia URL istniejącego remote'a – przydatne po zmianie nazwy repozytorium. URL może być HTTPS (https://github.com/user/repo.git) lub SSH (git@github.com:user/repo.git). HTTPS wymaga tokena, SSH – klucza. Bez remote nie możesz wysłać ani pobrać zmian z GitHub – to łącze między Twoim lokalnym repozytorium a chmurą. W zespole każdy programista ma swoje lokalne repozytorium i jednego wspólnego remote'a (origin) na GitHubie. Zarządzanie remote'ami to podstawowa umiejętność przy pracy z centralnym repozytorium.

git push wysyła lokalne commity na zdalne repozytorium (GitHub). git push -u origin main to pierwsze push – -u (--set-upstream) ustawia śledzenie gałęzi lokalnej (main) do zdalnej (origin/main). Dzięki --set-upstream kolejne pushy wystarczy robić jako git push bez argumentów. git push wysyła tylko zatwierdzone commity, nie niezatwierdzone zmiany – zmiany w stagingu lub obszarze roboczym zostają lokalnie. git push --all wysyła wszystkie gałęzie. git push origin nazwa_gałęzi wysyła konkretną gałąź. Jeśli remote ma nowsze commity, push zostanie odrzucony (non-fast-forward) – musisz najpierw zrobić git pull. git push --force (lub --force-with-lease) nadpisuje zdalną historię – używaj tylko w ostateczności. --force-with-lease jest bezpieczniejszy – sprawdza, czy zdalna gałąź nie została zaktualizowana od ostatniego fetcha. git push --delete origin nazwa_gałęzi usuwa gałąź na zdalnym repozytorium. Po pierwszym pushu możesz zobaczyć swój kod na GitHubie i udostępnić link zespołowi. Push to moment, w którym Twoja lokalna praca staje się widoczna dla innych – warto wcześniej sprawdzić git status i git log.

Tagi nie są domyślnie wysyłane przez git push – musisz użyć git push --tags, aby wypchnąć je na GitHub. git push --tags wysyła wszystkie tagi, których nie ma na zdalnym repozytorium. Możesz też wysłać konkretny tag: git push origin v0.1. Po pushnięciu tagi są widoczne w zakładce "Releases" na GitHubie. GitHub pozwala dodać do taga opis, załączniki (np. pliki binarne) i nazwać release. git push --follow-tags wysyła tylko tagi adnotowane (z wiadomością), pomijając lekkie – przydatne, gdy tagujesz selektywnie. Tagi w przeciwieństwie do gałęzi są niemutowalne – wskazują na ten sam commit na zawsze. Jeśli musisz zmienić tag, usuń go lokalnie (git tag -d v0.1) i zdalnie (git push --delete origin v0.1), a potem utwórz nowy. System wersjonowania semantycznego (SemVer: vMAJOR.MINOR.PATCH) jest standardem w tagowaniu. Release z tagiem na GitHubie często wyzwala automatyczne buildy (CI/CD). Tagi to kamienie milowe – używaj ich do oznaczania wydań, ważnych milestone'ów i wersji produkcyjnych. Bez git push --tags Twoje tagi zostaną tylko lokalnie, co mija się z celem przy pracy zespołowej.

git pull pobiera zmiany ze zdalnego repozytorium i scala je z lokalną gałęzią. Wewnętrznie git pull to git fetch (pobranie zmian) + git merge (scalenie z lokalną gałęzią). git pull origin main pobiera zmiany z gałęzi main na originie i scala je z lokalną gałęzią. Jeśli nie ma konfliktów, Git tworzy commit merge lub wykonuje fast-forward. Fast-forward ma miejsce, gdy lokalna gałąź nie ma nowych commitów – Git po prostu przesuwa wskaźnik do przodu. git pull --rebase zamiast merge używa rebase – lokalne commity są nakładane na pobrane zmiany, co daje liniową historię. Dla początkujących domyślny git pull jest bezpieczniejszy, ale dla zaawansowanych --rebase daje czystszą historię. Zawsze wykonuj git pull przed git push – zmniejsza ryzyko konfliktów i odrzucenia pusha. git pull --verbose pokazuje szczegóły pobranych zmian. Jeśli są niezcommitowane zmiany lokalne, git pull może je zablokować – wtedy git stash przed pullem pomaga. git pull to rytuał otwierający sesję pracy: "zanim zacznę, sprawdzę co nowego u innych". Regularne pullowanie utrzymuje repozytorium zsynchronizowane z resztą zespołu i minimalizuje konflikty.

GitHub pozwala edytować pliki bezpośrednio przez interfejs webowy – bez terminala i IDE. Wchodzisz do repozytorium, znajdujesz plik, klikasz ikonę ołówka (Edit this file). Po wprowadzeniu zmian piszesz wiadomość commita (pole Commit changes) i zatwierdzasz. GitHub automatycznie tworzy commit na aktualnej gałęzi lub proponuje nową gałąź z PR. Możesz też dodawać nowe pliki (Add file → Create new file lub Upload files). To wygodne do szybkich poprawek – literówek, drobnych błędów – ale nie do poważnych zmian. Przed rozpoczęciem pracy lokalnej zawsze wykonaj git pull, aby pobrać zmiany z GitHub. Jeśli zapomnisz, a GitHub ma nowsze commity, push zostanie odrzucony. Po edycji przez stronę i lokalnych zmianach może dojść do konfliktu – trzeba go rozwiązać przed dalszą pracą. GitHub webowy jest też przydatny dla osób nietechnicznych, które mogą edytować pliki dokumentacji. Jednak do poważnej pracy programistycznej zaleca się edycję lokalną w IDE. W repozytoriach open source często spotyka się commity typu "Fix typo" stworzone przez webowy interfejs GitHub. Edycja online jest szybka i wygodna, ale wymaga potem synchronizacji z lokalnym repozytorium.

Po edycji pliku na GitHubie Twoje lokalne repozytorium jest przestarzałe – git pull przywraca synchronizację. Gdy wykonasz git pull, Git znajduje nowy commit na zdalnej gałęzi i próbuje go scalić. W prostym przypadku (brak lokalnych zmian) Git wykonuje fast-forward – przesuwa lokalną gałąź do przodu. git log --oneline --graph pokaże teraz nowy commit "Update plik.html" z Twojego webowego commita. Jeśli miałeś lokalne zmiany, Git je scala – może powstać commit merge lub konflikt. git diff HEAD~1 HEAD pokaże, co dokładnie zmienił commit z GitHub. Ten mechanizm jest identyczny niezależnie od tego, czy zmiana pochodzi od Ciebie (przez www) czy od kolegi z zespołu. git pull jest bezpieczne – nie nadpisuje Twoich zmian, tylko je scala. Po pullu możesz kontynuować pracę, mając pełną historię zarówno lokalną, jak i zdalną. To codzienny cykl pracy w zespole: pull → praca → push, i od nowa. Synchronizacja przez pull przed rozpoczęciem pracy to jeden z najważniejszych nawyków w Git. Bez tego Twoja gałąź rozjeżdża się z originem i push jest odrzucany. git pull to pomost między Twoim lokalnym światem a tym, co dzieje się w chmurze.

git stash to idealne narzędzie, gdy musisz przerwać pracę w połowie i zająć się czymś innym. Odkłada wszystkie niezatwierdzone zmiany (zarówno staged, jak i unstaged) na stos i przywraca obszar roboczy do ostatniego commita. git stash save "opis" dodaje opis, ułatwiający identyfikację schowanych zmian. git stash list pokazuje wszystkie schowane zmiany na stosie. git stash apply (bez pop) przywraca ostatnie schowane zmiany, ale zachowuje je na stosie. git stash pop przywraca i usuwa ze stosu – jedno i drugie. git stash drop usuwa schowaną zmianę bez przywracania. git stash branch nowa_gałąź tworzy nową gałąź z ostatniego stashu – przydatne, gdy stash narzuca konflikt z bieżącą gałęzią. git stash --include-untracked (lub -u) chowa również nowe, nieśledzone pliki. Możesz mieć wiele stashy – zarządzaj nimi jak stosem (LIFO). Częsty scenariusz: pracujesz nad funkcją, nagle musisz naprawić pilny błąd – git stash, przełącz gałąź, napraw, commit, wróć, git stash pop. git stash to nieoceniona komenda w dynamicznym środowisku, gdzie priorytety zmieniają się z godziny na godzinę. Bez stash musiałbyś commitować niedokończoną pracę, co zaśmieca historię.

Gałęzie (branches) to jedna z najpotężniejszych funkcji Gita – pozwalają rozwijać projekt w wielu kierunkach jednocześnie. Gałąź w Git to lekki wskaźnik (plik z hashem) – utworzenie gałęzi to operacja błyskawiczna, w przeciwieństwie do innych systemów kontroli wersji. git branch wyświetla listę gałęzi – gwiazdka (*) oznacza aktywną gałąź. git branch nazwa_gałęzi tworzy nową gałąź (ale nie przełącza na nią). git switch nazwa_gałęzi (od Git 2.23) przełącza na istniejącą gałąź. git switch -c nowa_gałąź tworzy i od razu przełącza – skrót dla git branch + git switch. W starszych wersjach używa się git checkout -b nowa_gałąź. git branch -d nazwa_gałęzi usuwa gałąź (tylko po scaleniu). git branch -D nazwa_gałęzi wymusza usunięcie nawet bez scalenia – ostrożnie, stracisz commity. Gałęzie są podstawą workflow w Git – każda funkcja, bugfix czy eksperyment powinny mieć własną gałąź. Popularne modele: GitHub Flow (gałęzie feature, PR do main) i Git Flow (develop, feature, release, hotfix). Dzięki gałęziom możesz pracować nad nową funkcją przez tydzień, nie blokując reszty zespołu. git branch to mapa Twojego projektu – im lepiej zarządzasz gałęziami, tym płynniejsza jest praca zespołu.

git merge scala zmiany z jednej gałęzi do drugiej – łączy historie dwóch linii rozwoju. Przed scaleniem upewnij się, że jesteś na gałęzi docelowej (np. git switch main, potem git merge feature). Fast-forward ma miejsce, gdy gałąź źródłowa jest bezpośrednim następcą docelowej – Git po prostu przesuwa wskaźnik. Jeśli gałęzie się rozeszły (oba dodały commity), Git tworzy commit merge z dwoma rodzicami. git merge --no-ff wymusza commit merge nawet przy fast-forward – zachowuje informację, że istniała osobna gałąź. git merge --squash scala wszystkie commity z gałęzi źródłowej w jeden – przydatne, gdy gałąź miała wiele brudnych commitów. Podczas scalenia mogą wystąpić konflikty – Git oznacza pliki jako conflicted i przerywa scalenie. Po rozwiązaniu konfliktu: git add i git commit (lub git merge --continue). git merge --abort przerywa scalenie i wraca do stanu sprzed. git merge --no-commit scala, ale nie tworzy commita – możesz wprowadzić dodatkowe zmiany przed zatwierdzeniem. W codziennej pracy scalasz gałąź funkcji do main po zakończeniu i testach. git merge to moment prawdy – tu spotykają się dwie linie kodu i trzeba je pogodzić. Regularne scalanie (merge często) zmniejsza ryzyko dużych, bolesnych konfliktów.

git clone kopiuje zdalne repozytorium na lokalny komputer – to najszybszy sposób rozpoczęcia pracy z istniejącym projektem. git clone tworzy katalog o nazwie repozytorium i pobiera całą historię (wszystkie commity, gałęzie, tagi). Wewnętrznie clone wykonuje: git init (tworzy .git), git remote add origin URL (dodaje remote), git fetch (pobiera całą historię), git checkout (przełącza na domyślną gałąź). git clone --depth 1 tworzy płytkie klonowanie tylko ostatniego commita – oszczędza czas i miejsce, ale nie ma historii. git clone --branch v0.1 klonuje konkretną gałąź lub tag. git clone --recursive klonuje również submoduły (zależności). Możesz sklonować przez HTTPS (wymaga tokena) lub SSH (wymaga klucza). git clone . nazwa_katalogu klonuje lokalne repozytorium – przydatne do testów i eksperymentów. Po sklonowaniu masz pełną kopię projektu – wszystko co potrzebne do pracy. git remote -v po clone pokaże origin ustawiony na źródłowe repozytorium. To najczęstszy sposób dołączenia do istniejącego projektu – zamiast zakładać od zera, pobierasz gotową historię. git clone jest bramą wejściową do każdego projektu open source i komercyjnego.

.gitignore to plik konfiguracyjny, który mówi Gitowi, które pliki i katalogi mają być ignorowane. Ignorowane pliki nie pojawiają się w git status, nie są dodawane przez git add . ani commitowane. Typowe ignorowane rzeczy: node_modules/, .env, __pycache__/, *.log, .DS_Store, katalog build/. Wzorce: * (dowolny ciąg), ? (jeden znak), ! (negacja – nie ignoruj), / (katalog). Przykład: node_modules/ ignoruje cały katalog, *.log ignoruje wszystkie pliki .log, !ważny.log NIE ignoruje ważny.log (mimo *.log). .gitignore może być w różnych katalogach – obowiązuje od swojego katalogu w dół. Wzorce z / na końcu dotyczą katalogów: build/ ignoruje katalog build, ale nie plik o nazwie build. Możesz ignorować pliki, które już są śledzone – ale .gitignore nie działa na śledzone pliki, trzeba je usunąć przez git rm --cached. GitHub udostępnia gotowe szablony .gitignore dla różnych języków na github.com/github/gitignore. Dobrze napisany .gitignore zapobiega przypadkowemu commitowaniu sekretów, zależności i plików tymczasowych. W każdym projekcie .gitignore powinien być pierwszym plikiem po inicjalizacji repozytorium. Nie ignoruj .gitignore – commit go, aby cały zespół miał te same reguły.

Aliasy w Git to własne skrócone komendy, które znacząco przyspieszają codzienną pracę. git config --global alias.lg "log --oneline --graph --decorate --all" tworzy alias git lg wykonujący długą komendę log. Potem zamiast pamiętać i pisać długie polecenie, wystarczy git lg. Popularne aliasy: git co (checkout), git br (branch), git ci (commit -m), git st (status), git df (diff). git config --global alias.undo "reset --soft HEAD~1" – alias do cofnięcia ostatniego commita. Aliasy można definiować z parametrami – ale to już bardziej zaawansowane. git config --global alias.visual "!gitk" – wykrzyknik oznacza komendę zewnętrzną (nie git). Wszystkie aliasy są przechowywane w pliku ~/.gitconfig w sekcji [alias]. Możesz edytować bezpośrednio: git config --global --edit. Wiele zespołów udostępnia wspólne aliasy w dokumentacji projektu. Aliasy to inwestycja czasu, która zwraca się przy każdym wpisanym poleceniu. git config umożliwia też ustawienie domyślnego edytora (core.editor) i narzędzia diff (diff.tool). Im częściej używasz Gita, tym bardziej aliasy stają się niezbędne – zaoszczędzisz tysiące uderzeń klawiszy. Wymyśl własne aliasy dopasowane do Twojego stylu pracy – to Twoja osobista optymalizacja.

git shortlog i git blame to narzędzia do analizy historii i autorstwa kodu. git shortlog grupuje commity według autora, pokazując kto ile commitów wykonał. git shortlog -sn wyświetla tylko liczbę commitów i nazwę autora – statystyki wkładu w projekt. git shortlog -e dołącza adresy email. git shortlog --since="2024-01-01" ogranicza do okresu. git shortlog --no-merges pomija commity scalania – skupia się na rzeczywistych zmianach. git blame nazwa_pliku pokazuje każdą linię pliku z informacją: commit, autor, data. git blame -L 10,20 plik.py ogranicza do konkretnych linii. git blame --show-email pokazuje email zamiast nazwy. git blame --since="2024-01-01" pokazuje tylko zmiany od określonej daty. git blame jest niezastąpione przy code review – gdy widzisz podejrzany kod, git blame znajdzie autora i commit. git blame nie obwinia – to narzędzie śledcze: "kto zmienił tę linię i dlaczego". shortlog świetnie nadaje się do raportów i podsumowań sprintów. W dużych projektach git blame pomaga znaleźć autora konkretnego kawałka kodu do zapytania o kontekst. Oba narzędzia są nieocenione w utrzymaniu i analizie istniejącego kodu.

git grep i git bisect to zaawansowane narzędzia do wyszukiwania i debugowania. git grep to przeszukiwanie plików w repozytorium – szybsze niż zwykłe grep, bo korzysta z indeksu Gita. git grep "funkcja" znajduje wszystkie wystąpienia słowa w plikach śledzonych. git grep --cached szuka w stagingu, git grep v0.1 szuka w konkretnej wersji. git grep -n pokazuje numery linii, -i ignoruje wielkość liter. git grep -L "TODO" znajduje pliki bez wzorca. git bisect to binarne wyszukiwanie błędu w historii – dzieli zakres commitów na pół, aż znajdzie winowajcę. git bisect start oznacza początek poszukiwań. git bisect bad – obecny commit jest zły. git bisect good v0.1 – stara wersja była dobra. Git przełącza się na commit w połowie zakresu – testujesz i oznaczasz git bisect good lub git bisect bad. Po kilku krokach Git wskazuje pierwszy zły commit. git bisect reset kończy sesję i wraca do gałęzi. git bisect run skrypt.sh automatyzuje testowanie – Git sam uruchamia skrypt na każdym kandydacie. git bisect to must-have przy ściganiu błędów, które pojawiły się między wydaniami. Zamiast ręcznie przeglądać 100 commitów, bisect znajdzie winowajcę w 7 krokach.

git fetch pobiera zmiany ze zdalnego repozytorium, ale nie scala ich z lokalną gałęzią. To kluczowa różnica względem git pull – fetch daje Ci podgląd, co się zmieniło na zdalnym repozytorium, bez ryzyka konfliktów. Po fetchu możesz przeglądać pobrane zmiany: git log origin/main, git diff main origin/main. git fetch origin pobiera zmiany z wszystkich gałęzi originu. git fetch --prune (lub -p) usuwa lokalne ślady gałęzi, które zostały usunięte na zdalnym repozytorium. git fetch --all pobiera zmiany ze wszystkich zdalnych repozytoriów (origin, upstream itp.). Po fetchu możesz scalić, kiedy uznasz to za stosowne: git merge origin/main. git fetch to bezpieczniejsza alternatywa dla git pull – daje kontrolę nad tym, co i kiedy scalać. W środowisku korporacyjnym często używa się fetch + code review przed mergem. git fetch jest też używane w skryptach CI/CD do sprawdzenia nowych commitów na gałęzi. Regularne fetche utrzymują lokalną wiedzę o zdalnym repozytorium bez ingerencji w Twoją pracę. git fetch to "podejrzyj, nie dotykaj" – idealne, gdy chcesz sprawdzić co nowego, nie przerywając bieżącej pracy. Dla zaawansowanych: git ls-remote to jeszcze lżejsza wersja – pokazuje referencje bez pobierania danych.

git archive i git clean to komendy do dystrybucji i porządkowania. git archive tworzy archiwum (tar lub zip) z plikami w wskazanej wersji – idealne do dystrybucji kodu źródłowego. git archive --format=zip --output=projekt.zip v0.1 tworzy zip z zawartością wersji v0.1. git archive --format=tar --prefix=projekt-v0.1/ v0.1 | gzip > projekt-v0.1.tar.gz – archiwum z prefiksem katalogu. git archive pomija pliki nieśledzone i .gitignore – tylko to, co jest w commitach. Dla repozytorium open source to sposób na dostarczenie kodu bez całej historii .git. git clean usuwa nieśledzone pliki z obszaru roboczego – przydatne po buildzie lub testach. git clean -n (dry-run) pokazuje, co zostanie usunięte, bez faktycznego usuwania. git clean -f usuwa nieśledzone pliki (force). git clean -fd usuwa również nieśledzone katalogi. git clean -fx usuwa również pliki ignorowane przez .gitignore. Używaj git clean -n zawsze przed -f – sprawdź co usuniesz. git archive to pakowanie, git clean to sprzątanie – obie komendy pomagają utrzymać porządek. git archive jest często używane w pipeline'ach CI/CD do przygotowania artefaktów wdrożeniowych. W połączeniu z tagami daje idealny mechanizm wydawania wersji.

Konflikty scalania (merge conflicts) pojawiają się, gdy Git nie może automatycznie scalić zmian z dwóch gałęzi. Dzieje się tak, gdy dwie gałęzie modyfikują te same linie w tym samym pliku w różny sposób. Git oznacza pliki jako conflicted i wstawia znaczniki: <<<<<<< (nasze zmiany), ======= (separator), >>>>>>> (ich zmiany). Aby rozwiązać konflikt, edytujesz plik – wybierasz jedną wersję, łączysz obie lub piszesz nową treść. Po edycji: git add plik (oznacza jako rozwiązany) i git commit (git merge --continue). git merge --abort przerywa całe scalenie i wraca do stanu sprzed. git mergetool uruchamia zewnętrzne narzędzie (kdiff3, meld, vimdiff) do wizualnego rozwiązywania konfliktów. Konflikt może dotyczyć plików binarnych – tu musisz wybrać jedną wersję (git checkout --ours lub --theirs). Najlepszym sposobem unikania konfliktów jest częste pullowanie i małe, częste scalenia. W zespole warto komunikować się, kto nad czym pracuje, aby nie modyfikować tych samych plików. Konflikty nie są błędem – to naturalna część pracy zespołowej. Git daje wszystkie narzędzia do ich rozwiązania – strach przed konfliktami mija z praktyką. Pamiętaj: konflikt to nie katastrofa, tylko moment, w którym musisz podjąć decyzję ostatecznej wersji kodu.

Tabela najważniejszych komend stanowi ściągawkę na co dzień. git init – zakłada nowe repozytorium. git status – sprawdza stan plików w obszarze roboczym i stagingu. git add – dodaje zmiany do stagingu. git commit – zatwierdza zmiany z stagingu. git log – przegląda historię commitów. git diff – porównuje zmiany między stanami. git branch – zarządza gałęziami. git switch – przełącza gałęzie. git merge – scala zmiany z gałęzi. git remote – zarządza zdalnymi repozytoriami. git push – wysyła commity na GitHub. git pull – pobiera zmiany z GitHub. git stash – chowa tymczasowo zmiany. git restore – przywraca pliki. git tag – oznacza wersje. Te komendy pokrywają 90% codziennej pracy z Gitem. Opanowanie ich na pamięć pozwala skupić się na kodzie, nie na narzędziu. Każda z tych komend ma dodatkowe opcje, które poznaje się stopniowo w miarę potrzeb. Regularne używanie tych podstawowych operacji buduje nawyk sprawnego zarządzania wersjami. Wydrukuj tę tabelę lub zapisz jako notatkę – pierwsze tygodnie z Gitem to ciągłe sprawdzanie składni. Z czasem komendy wejdą w krew i przestaniesz myśleć o narzędziu, skupiając się na tworzeniu kodu. Ta tabela to Twój kompas na początku przygody z Gitem – zawsze możesz do niej wrócić.

Podsumowanie to moment, aby spojrzeć na całość zdobytej wiedzy o Git. Nauczyłeś się zakładać repozytorium, dodawać pliki, commitować i tagować wersje. Poznałeś cykl życia plików: untracked → staged → committed – i wiesz, jak sprawdzić stan każdego pliku. Zrozumiałeś różnicę między restore, checkout, revert i reset – każde narzędzie do cofania zmian ma swoje zastosowanie. Wiesz, jak połączyć lokalne repozytorium z GitHub, wypchnąć zmiany (push) i pobrać je (pull). Tagi, gałęzie i scalanie to już nie magia – wiesz, jak działają i jak rozwiązywać konflikty. Zaawansowane komendy jak stash, bisect, blame, grep, fetch, archive są teraz w Twoim arsenale. Najważniejsza zasada: commituj często, małymi partiami, z opisowymi wiadomościami. Nie bój się eksperymentować – Git daje bezpieczeństwo, bo zawsze możesz wrócić do poprzedniej wersji. Praktyka czyni mistrza – im więcej commitów, tym bardziej naturalne stają się komendy. Pamiętaj o .gitignore, aliasach i regularnym pullowaniu przed pracą. Git to nie tylko narzędzie – to sposób myślenia o rozwoju oprogramowania. Każdy commit to krok naprzód, a cała historia to mapa podróży Twojego projektu.