Podstawy Git i GitHub: jak nie pogubić się w wersjach kodu

Po co w ogóle Git? Problem „ostatnia_ostateczna_wersja_KOPIA_FINALNA”

Typowy chaos bez systemu kontroli wersji

Bez Gita praca nad kodem zwykle kończy się folderem w stylu: projekt_v1, projekt_v2_poprawki, projekt_ostateczna, projekt_ostateczna_2, projekt_ostateczna_KOPIA_FINALNA. Do tego pendrive, kilka ZIP-ów na dysku i wersja wysłana mailem do kogoś z zespołu. Brzmi znajomo? W takiej sytuacji każda zmiana to ryzyko, że nadpiszesz coś, czego nie da się łatwo cofnąć.

Największy problem takiego podejścia to brak historii. Nie wiesz, co dokładnie zmieniło się między „v2” a „v3”. Musisz ręcznie porównywać pliki, czasem linijka po linijce. Gdy coś przestaje działać, cofnięcie się do stabilnej wersji jest kosztowne czasowo: szukanie po starych kopiach, sprawdzanie, czy to na pewno właściwy plik, odtwarzanie brakujących fragmentów.

Dochodzi do tego chaos przy współpracy. Dwie osoby edytują ten sam plik i przesyłają go sobie nawzajem. Kto ma „tę właściwą” wersję? Ktoś dodał funkcję, ktoś inny poprawił błąd w innym miejscu, a potem wszystko wylądowało w jednym pliku, nadpisując część czyjejś pracy. Taki styl pracy jest tani sprzętowo, ale drogi czasowo – traci się godziny na ręczne łączenie zmian.

Git jako tani i szybki „time machine” do kodu

Git rozwiązuje ten bałagan jednym prostym pomysłem: wszystkie zmiany zapisujesz w jednym miejscu, z dokładną historią. Każdy commit to foto-migawka projektu w danym momencie. Możesz wrócić do dowolnej wersji, porównać je, sprawdzić, kto i kiedy coś zmodyfikował. Nie trzeba kopiować całych folderów – Git przechowuje różnice w sprytny sposób, więc nie zapycha dysku setkami duplikatów.

Największy zysk to spokój przy eksperymentach. Chcesz spróbować nowej funkcji, ale boisz się, że popsujesz działający kod? Tworzysz gałąź, eksperymentujesz, a jeśli coś się posypie – wracasz do poprzedniego commitu, jakby nic się nie stało. To jak „cofnij” dla całego projektu, a nie tylko dla pojedynczego pliku.

Git jest darmowy, działa lokalnie (bez internetu), nie wymaga mocnego sprzętu i działa na dowolnym systemie. Na starcie to bardzo tani sposób na ograniczenie kosztownego chaosu. Jeden dobrze opisany commit potrafi zaoszczędzić godziny grzebania w starych plikach.

Git vs GitHub – co jest czym i po co początkującemu

Częste nieporozumienie: Git to narzędzie działające na twoim komputerze, a GitHub to serwis internetowy, który przechowuje repozytoria w chmurze i ułatwia współpracę. Można używać Gita bez GitHuba (np. tylko lokalnie), ale nie da się sensownie korzystać z GitHuba bez znajomości podstaw Gita.

Git dba o historię zmian i operacje na wersjach. GitHub dorzuca do tego:

• zdalne repozytorium – kopia projektu na serwerze, dostępna z wielu komputerów,
• pull requesty – wygodne miejsce do przeglądania i omawiania zmian przed ich połączeniem,
• podgląd commitów, branchy, historii – wszystko przez przeglądarkę,
• uprawnienia – kto może wprowadzać zmiany, zatwierdzać pull requesty, wypychać na main.

Dla początkującego programisty GitHub to głównie backup i portfolio. Projekt nie ginie z dysku wraz z awarią laptopa, a repozytoria można podlinkować w CV. W pierwszym miesiącu używania Gita i GitHuba zyskujesz przede wszystkim: pewność, że zmiany są zapisane, prosty sposób cofania się w czasie i wygodny kanał współpracy nawet przy małych projektach.

Kluczowe pojęcia bez których trudno ruszyć: repozytorium, commit, branch

Repozytorium – folder z pamięcią długotrwałą

Repozytorium Git to po prostu folder twojego projektu, w którym Git śledzi historię. Po uruchomieniu git init w katalogu projektu pojawia się ukryty katalog .git – tam trzymane są wszystkie informacje o commitach, gałęziach i zmianach.

Masz dwa podstawowe rodzaje repozytoriów:

• Lokalne repozytorium – na twoim komputerze; tu commitujesz, tworzysz branche, cofasz się, robisz wszystko, nawet bez internetu.
• Zdalne repozytorium – np. na GitHubie; tam wysyłasz commity (git push) i pobierasz zmiany od innych (git pull).

Technicznie rzecz biorąc, każde lokalne repozytorium jest pełnoprawne – nie jest „klientem” serwera w klasycznym sensie. To znaczy, że nawet jeśli GitHub padnie, twoje lokalne repo jest nadal kompletne. To spora przewaga nad rozwiązaniami opartymi wyłącznie o chmurę.

Commit – najmniejsza jednostka historii

Commit to zarejestrowany zestaw zmian w projekcie wraz z opisem, kto i kiedy je zrobił. Przykład komunikatu: git commit -m "Dodaj walidację formularza logowania". Ten jeden komunikat może uratować dzień, gdy po miesiącu szukasz, gdzie dokładnie pojawiła się walidacja.

Kluczowe cechy commita:

• Jest niezmienny – po stworzeniu nie powinno się go edytować (są wyjątki, ale dla początkujących najlepiej traktować commit jako stały punkt w historii).
• Ma unikalny identyfikator (hash), np. 3a5b2c7, który pozwala go wskazać w komendach.
• Zawiera różnicę względem poprzedniego commita i pełny stan projektu w danym momencie.

Dobrze rozbity projekt ma małe, logiczne commity: jeden commit = jedna w miarę spójna zmiana. Zamiast:

git commit -m "update"

lepiej zrobić kilka commitów typu:

• "Dodaj obsługę błędnego hasła"
• "Popraw błąd w wyświetlaniu komunikatu błędu"
• "Uprość funkcję logowania (refactoring)"

Przy cofnięciu zmian lub analizie historii to ogromna oszczędność czasu.

Branch – osobna linia rozwoju kodu

Branch (gałąź) to równoległa linia historii w repozytorium. Najczęściej masz gałąź main (lub master) – tam jest stabilna wersja projektu. Na potrzeby konkretnej funkcji czy poprawki błędu tworzysz nową gałąź, np. feature/login, i tam wprowadzasz zmiany, nie dotykając głównej.

Najprostszy i wystarczający na start model to:

• main – stabilna wersja, która wyląduje na produkcji,
• krótkie gałęzie funkcjonalne – tworzone na kilka–kilkanaście commitów, łączone z main po zakończeniu pracy.

Takie podejście pozwala eksperymentować bez strachu, że popsujesz to, co już działa. Nawet w jednoosobowym projekcie branch jest przydatny, bo oddzielasz pomysły i „duże zmiany” od wersji, która ma działać tu i teraz (np. na prezentacji u klienta).

HEAD, working directory, staging area – trzy poziomy zmian

W Gicie działa prosty mechanizm trzech „warstw”:

• Working directory – bieżący folder z plikami, które edytujesz w edytorze. Tu robisz zmiany.
• Staging area (index) – „półka do zatwierdzenia”. Pliki, które dodałeś komendą git add, ale jeszcze ich nie commitowałeś.
• HEAD – wskaźnik na ostatni commit w aktualnej gałęzi.

Prosta analogia:

• Working directory – brudnopis, gdzie wszystko miesza się naraz.
• Staging area – mała półka, gdzie odkładasz rzeczy, które mają trafić na zdjęcie.
• Commit (HEAD) – zdjęcie, które już wisi w archiwum i nie zmienia się.

Typowy przepływ wygląda tak: edytujesz kod (working directory), wybierasz pliki do commita (git add – staging), a następnie tworzysz commit (git commit – aktualizacja HEAD). Świadomość, na którym poziomie coś jest, pozwala unikać wielu nieporozumień typu „przecież to zmieniłem, czemu tego nie ma na GitHubie?”.

Szybki start: konfiguracja Gita i pierwsze lokalne repozytorium

Instalacja na Windows, macOS i Linux – najkrótszą drogą

Git jest darmowy i dostępny na wszystkie popularne systemy. Najprostsze ścieżki:

• Windows: pobierz instalator z git-scm.com, klikaj „Next” zostawiając domyślne ustawienia. Zainstaluje się też Git Bash – prosty terminal z Gitem.
• macOS: najprościej zainstalować git przez Xcode Command Line Tools (po wpisaniu git w terminalu system sam zaproponuje instalację), albo przez Homebrew: brew install git.
• Linux: w zależności od dystrybucji: np. Ubuntu/Debian – sudo apt install git, Fedora – sudo dnf install git.

To jednorazowa operacja. Po zainstalowaniu możesz sprawdzić wersję komendą git --version. Jeśli terminal zwróci numer, narzędzie jest gotowe.

Minimalna konfiguracja: nazwa i e‑mail

Git musi wiedzieć, jak podpisywać commity. Bez tego przy próbie commita zobaczysz komunikat o braku ustawionego użytkownika. Konfigurację ustawiasz raz dla całego systemu:

git config --global user.name "Imię Nazwisko"
git config --global user.email "twojemail@example.com"

Zamiast pełnego imienia i nazwiska możesz użyć nicku, ale przy pracy zespołowej czy otwartym repozytorium sensowny podpis ułatwia identyfikację autora zmian. Ten sam e‑mail warto potem powiązać z kontem na GitHubie, żeby commity ładnie przypinały się do profilu.

Konfigurację możesz podejrzeć przez:

git config --global --list

Tworzenie repozytorium: `git init` w istniejącym projekcie

Jeśli masz już folder z projektem (np. moj-projekt), wejdź do niego w terminalu i uruchom:

cd moj-projekt
git init

Git utworzy ukryty folder .git. Od tego momentu wszystkie operacje w tym katalogu będą śledzone przez Gita. Na razie repozytorium nie ma żadnego commita – Git ma tylko informację, że ma się przyglądać plikom w tym katalogu.

Ten krok jest bardzo tani czasowo, a pozwala od razu zacząć historię. Nawet jeśli projekt jest mały i „na próbę”, historia commitów może się przydać, gdy nagle stwierdzisz, że chcesz go pokazać innym lub rozwinąć.

Dodanie pierwszych plików i pierwszy commit

Załóżmy, że w folderze są pliki index.html i style.css. Najpierw sprawdź status:

git status

Zobaczysz coś w stylu:

Untracked files:
  (use "git add <file>..." to include in what will be committed)
    index.html
    style.css

To oznacza, że Git widzi te pliki, ale ich nie śledzi. Dodaj je do staging area:

git add index.html style.css

Lub, jeśli chcesz dodać wszystkie nowe pliki:

git add .

Następnie stwórz pierwszy commit:

git commit -m "Inicjalna struktura projektu: index i style"

Od tej chwili masz punkt odniesienia. Możesz zrobić kolejne zmiany i w razie problemów wrócić do tego pierwszego commita. To niewielki wysiłek, który zabezpiecza przed nadpisaniem pierwszej działającej wersji.

`git status` jako podstawowe „lustro” sytuacji

Komenda git status powinna stać się odruchem. Pokazuje, które pliki:

• są nowe (untracked),
• zmienione, ale nie dodane do staging area,
• są już dodane i czekają na commit.

Przykładowa sekwencja po edycji:

git status
git add zmieniony_plik.py
git status
git commit -m "Popraw obsługę błędów w zmieniony_plik.py"

Za każdym razem, gdy nie wiesz „co się dzieje” w repozytorium, odpal git status. To szybka diagnoza przed bardziej skomplikowanymi operacjami.

Podstawowy zestaw komend: od `status` do `log` w codziennej pracy

Minimum, które pokrywa 80% potrzeb na start

Do komfortowej pracy nie trzeba znać kilkudziesięciu komend. Na początek wystarczy kilka:

• git status – pokazuje aktualny stan plików względem ostatniego commita,
• git add – dodaje zmiany do staging area,

Dodawanie zmian „kawałkami”: `git add -p` i świadome commity

Przy codziennej pracy łatwo zmienić kilka rzeczy naraz w jednym pliku: poprawka błędu, mały refactoring, do tego jeszcze log do debugowania. Jeśli zrobisz z tego jeden commit, później trudniej go odkręcić. Ekonomiczniej czasowo jest podzielić zmiany, nawet jeśli siedzą w jednym pliku.

Do tego służy tryb interaktywny:

git add -p

Git pokaże zmiany podzielone na „hunki” (fragmenty) i zapyta, co z nimi zrobić:

Stage this hunk [y,n,q,a,d,s,e,?]? 

• y – dodaj ten fragment do commita,
• n – pomiń, zostanie na później,
• q – wyjdź,
• s – podziel fragment na mniejsze, jeśli to możliwe.

W praktyce: w jednym pliku robisz kilka logicznych poprawek, ale chcesz z nich dwa commity – jeden z bugfixem, drugi z kosmetyką. Najpierw git add -p i wybierasz tylko część zmian, commit z komunikatem typu „Napraw błędne wyliczanie sumy”. Potem znów git add -p, tym razem bierzesz resztę i commit „Uczyść styl formatowania kodu”. Dwie osobne historie, a pracy więcej o kilkadziesiąt sekund.

Podgląd zmian: `git diff` przed i po stagingu

Żeby nie commitować „w ciemno”, dobrze jest spojrzeć na różnice. Do tego służy:

git diff

Ta wersja pokazuje różnice między working directory a staging area – czyli wszystko, co zmieniłeś, a jeszcze nie dodałeś. Jeśli chcesz zobaczyć, co już jest w staging area (co trafi do najbliższego commita), użyj:

git diff --cached

Typowy, szybki rytuał przed commitem:

git status
git diff
git add -p
git diff --cached
git commit -m "Krótki, konkretny opis zmiany"

Minuta na podgląd zmian potrafi oszczędzić godzinę debugowania „dlaczego commit z poprawką formularza skasował mi połowę CSS-a”.

Cofanie i poprawianie ostatniego commita: `git commit –amend` i `git restore`

Czasem commit jest „prawie idealny”: brakuje jednego pliku albo literówka w komunikacie. Nie trzeba od razu robić nowego commita – wystarczy poprawka:

# dodaj zapomniany plik
git add zapomniany_plik.js

# popraw ostatni commit (łącznie z komunikatem, jeśli chcesz)
git commit --amend

Otworzy się edytor tekstu z komunikatem commita – możesz zmienić treść albo zostawić jak jest. Git połączy starego i nowego commita w jeden (z nowym hashem). Tego lepiej używać tylko na commitach, których jeszcze nie wysłałeś na GitHuba, żeby nie komplikować historii innym.

Jeśli zmieniłeś plik i chcesz wyrzucić te zmiany, wracając do wersji z ostatniego commita:

git restore nazwa_pliku

Dla plików, które już dodałeś do staging area, ale jednak nie chcesz ich commitować:

git restore --staged nazwa_pliku

To prostsze i szybsze niż ręczne cofanie zmian w edytorze, zwłaszcza gdy zdarzy się przypadkowe Ctrl+A > Delete albo nadpisanie całej funkcji.

Historia projektu: `git log` w wersji „dla ludzi”

Surowe git log jest poprawne, ale mało wygodne. Da się z niego zrobić prostą, czytelną listę zmian. Przykład:

git log --oneline --graph --decorate --all

Co to daje:

• --oneline – skrócony hash + temat commita w jednym wierszu,
• --graph – prosty rysunek ASCII pokazujący rozgałęzienia,
• --decorate – wyświetlenie nazw gałęzi i tagów,
• --all – historia ze wszystkich gałęzi, nie tylko z bieżącej.

W praktyce dostajesz czytelny widok: jaka gałąź skąd się wzięła, gdzie się połączyła i które commity coś namieszały. Przy prostych projektach wystarczy git log --oneline, które pozwala szybko zidentyfikować commit, do którego chcesz wrócić lub od którego zacząć nową gałąź.

Szybkie przywracanie plików z historii: `git checkout` pojedynczych plików

Jeżeli wiesz, że w konkretnym commicie plik wyglądał dobrze, nie musisz cofać całego repozytorium. Możesz wziąć tylko ten jeden plik:

# znajdź hash commita
git log --oneline

# przywróć konkretny plik ze wskazanego commita
git checkout <hash-commita> -- sciezka/do/pliku

To przydaje się, gdy np. refactoring CSS-a poszedł za daleko, ale JavaScript z nowszego commita jest w porządku. Zamiast walczyć z diffami w edytorze, po prostu przeciągasz „starą, dobrą” wersję samego CSS-a.

Współpraca z GitHub: klonowanie, zdalne repozytoria i pierwsze `push`

Dlaczego GitHub w ogóle się opłaca

Lokalne repozytorium wystarcza, jeśli pracujesz sam, na jednym komputerze, bez backupu. W praktyce to dość ryzykowny scenariusz – awaria dysku i po historii. GitHub (i podobne serwisy jak GitLab czy Bitbucket) rozwiązuje kilka problemów „za darmo”:

• trzyma kopię repozytorium w chmurze,
• ułatwia współpracę (pull requesty, code review),
• daje portfolio – link do projektu w CV kosztuje cię kilka minut roboty.

Na początek wystarczy darmowe konto GitHub. Wersje płatne mają dodatki, ale do nauki i małych projektów są zbędne.

Tworzenie zdalnego repozytorium na GitHubie

Po zalogowaniu na GitHubie użyj przycisku New w zakładce Repositories. Minimalna konfiguracja:

• Repository name – np. moj-projekt,
• Public lub Private – publiczne do portfolio, prywatne do eksperymentów,
• pozostałe opcje (README, .gitignore) na start możesz wyłączyć, jeśli repo już istnieje lokalnie.

Po utworzeniu zobaczysz stronę z instrukcją. Interesuje cię część typu …or push an existing repository from the command line – to gotowe komendy do podpięcia lokalnego repozytorium.

Podpinanie istniejącego lokalnego repozytorium: `git remote add origin`

Załóżmy, że masz już lokalne repo z commitami. Na stronie GitHuba pojawi się sekcja z czymś takim:

git remote add origin https://github.com/uzytkownik/moj-projekt.git
git branch -M main
git push -u origin main

Co to robi krok po kroku:

1. git remote add origin <url> – dodaje zdalne repozytorium o nazwie origin (to tylko etykieta),
2. git branch -M main – zmienia nazwę bieżącej gałęzi na main (jeśli np. była master),
3. git push -u origin main – wysyła gałąź main na GitHuba i ustawia ją jako domyślne powiązanie (upstream).

Po tej operacji kolejne wysyłki sprowadzają się do:

git push

bez podawania za każdym razem nazwy zdalnego repo i gałęzi.

Klonowanie istniejącego projektu: `git clone`

Gdy projekt już jest na GitHubie (twój albo cudzy), na innym komputerze najszybciej zacząć od klonowania:

git clone https://github.com/uzytkownik/moj-projekt.git

Git utworzy folder moj-projekt, ściągnie całą historię, ustawi origin na repozytorium z GitHuba i od razu przełączy cię na główną gałąź (najczęściej main). Nie trzeba już robić git init ani ręcznie dodawać zdalnego repo.

Codzienny rytm: `pull` przed pracą, `push` po pracy

Przy pracy w zespole albo na dwóch komputerach (np. laptop + PC) prosty, tani w utrzymaniu nawyk to:

• przed rozpoczęciem pracy – zsynchronizuj projekt:

git pull

• po zakończeniu pracy – wyślij swoje zmiany:

git push

git pull ściąga nowe commity z GitHuba i łączy je z twoją lokalną gałęzią. Dzięki temu zmniejszasz szansę na duże konflikty. git push wrzuca twoje commity na serwer, więc jeśli jutro padnie dysk, najwyżej stracisz kilka minut, a nie cały tydzień pracy.

Konflikty przy `pull` i `push`: minimalny zestaw reakcji

Przy pierwszych projektach konflikty brzmią groźnie, ale najczęściej chodzi o prostą sytuację: dwie osoby zmieniły ten sam fragment pliku. Git nie zgaduje, która wersja jest lepsza, więc zaznacza problematyczne miejsce:

<<<<<<< HEAD
twoja wersja
=======
wersja zdalna
>>>>>>> 3a5b2c7

Twoje zadanie:

1. Otworzyć plik w edytorze,
2. ręcznie wybrać właściwą wersję (albo połączyć obie),
3. usunąć znaczniki konfliktu <<<<<<<, =======, >>>>>>>,
4. dodać plik do staging area i zrobić nowy commit z opisem np. „Rozwiąż konflikt w pliku X”.

Większość popularnych edytorów (VS Code, JetBrains) ma graficzne narzędzia do rozwiązywania konfliktów. Warto się ich trzymać, bo skracają czas i ryzyko pomyłki.

Gałęzie w praktyce: prosty workflow bez korporacyjnej komplikacji

Tworzenie i przełączanie się między gałęziami: `git branch`, `git switch`

Najtańsza mentalnie strategia to: jedna stabilna gałąź (main) + krótkie gałęzie funkcjonalne. Tworzenie gałęzi na bazie aktualnego stanu:

git switch -c feature/login

To skrót od „stwórz nową gałąź feature/login i przełącz się na nią”. Starsza składnia robi to samo w dwóch krokach:

git branch feature/login
git switch feature/login

Żeby wrócić do głównej gałęzi:

git switch main

Lista wszystkich lokalnych gałęzi:

git branch

Prosty schemat „jedna funkcja = jedna gałąź”

Przy małych projektach nie ma sensu wchodzić w rozbudowane schematy typu Git Flow. W zupełności wystarczy luźna zasada:

• main – tylko to, co działa i nadaje się do pokazania (produkcyjnie lub w portfolio),
• do każdej większej zmiany tworzysz osobną gałąź, np. feature/rejestracja, bugfix/blad-logowania,
• po zakończeniu pracy na gałęzi – łączysz ją z main.

Taki model wymaga dosłownie kilku komend, a oszczędza nerwy, gdy np. musisz nagle „na już” przygotować hotfixa – po prostu odkładasz eksperymentalną gałąź, przełączasz się na main i robisz szybki branch na poprawkę.

Łączenie gałęzi: `merge` w wersji bez bólu

Załóżmy, że dokończyłeś pracę na gałęzi feature/login i chcesz wprowadzić ją do main. Kroki:

# przełącz się na main
git switch main

# upewnij się, że main jest aktualny (przy pracy z GitHubem)
git pull

# połącz zmiany z gałęzi feature/login
git merge feature/login

Jeśli zmiany się nie nachodzą, Git utworzy automatyczny merge commit. Jeśli pojawią się konflikty, rozwiążesz je tak samo, jak przy pull. Po udanym merge warto usunąć zbędną gałąź funkcjonalną:

git branch -d feature/login

Gałąź zniknie z listy, ale commity wciąż zostają w historii main, więc nic nie tracisz.

Praca na branchach przy współpracy z GitHubem

Gdy gałąź funkcjonalna ma trafić również na GitHuba, wysyłasz ją dokładnie tak samo jak main:

Wysyłanie gałęzi na GitHuba i pierwsze pull requesty

Gdy gałąź jest gotowa lokalnie, wystarczy jeden push z podaniem nazwy:

git push -u origin feature/login

Przełącznik -u sprawia, że następne wysyłki z tej gałęzi będą już krótsze:

git push

Na GitHubie pojawi się przycisk typu Compare & pull request. Pull request (PR) to po prostu prośba: „połączcie moją gałąź z main”. Do solo-projektów też się przydaje – zamiast łączyć wszystko z palca, masz czytelny podgląd zmian, komentarze i historię, co weszło kiedy.

Minimalny, tani czasowo schemat pracy z PR-ami:

• robisz feature na osobnej gałęzi,
• push na GitHuba,
• tworzysz pull request do main,
• rzucasz okiem na diff (często wyłapiesz literówki i drobne błędy bez odpalania projektu),
• łączysz gałąź przez przycisk Merge i usuwasz ją zdalnie.

Dla solo-developera to de facto darmowy „drugi ekran” do przeglądu zmian – z bardzo niskim narzutem.

Porządkowanie gałęzi lokalnych i zdalnych

Przy kilku sprintach z rzędu łatwo zrobić „cmentarzyska” gałęzi typu feature/stary-eksperyment. Im dłużej z tym zwlekasz, tym większy bałagan w liście branchy i w głowie. Kilka prostych porządków wystarczy:

# usunięcie lokalnej gałęzi po merge'u
git branch -d feature/login

# jeśli gałąź jest już na GitHubie, usuń także tam:
git push origin --delete feature/login

Jeżeli masz gałąź, która nie jest zmergowana, a chcesz ją na siłę wyrzucić (np. porzucony eksperyment):

git branch -D feature/prototyp-ktory-nie-wszedl

Dobry kompromis czas–porządek: raz na jakiś czas przeglądasz gałęzie i wszystko, co jest zmergowane do main i niepotrzebne, kasujesz. Zostają tylko aktywne tematy.

Aktualizowanie gałęzi z główną: `merge` lub `rebase` bez teorii na 3 godziny

Gdy pracujesz na dłuższej gałęzi, w międzyczasie main się zmienia. Dwa najprostsze sposoby na wciągnięcie świeżych zmian:

Opcja 1: merge do gałęzi roboczej

# będąc na swojej gałęzi
git switch feature/login

# pobierz aktualne zmiany z main
git switch main
git pull

# wróć na swoją gałąź
git switch feature/login

# połącz main z gałęzią roboczą
git merge main

Efekt: w historii zobaczysz dodatkowe commity merge. To całkowicie akceptowalne w małych projektach – zyskujesz prostotę, tracisz trochę „czystości wykresu” historii.

Opcja 2: szybki `rebase` dla prostych przypadków

Jeśli nie boisz się jednego dodatkowego polecenia, możesz „przepisać” swoją gałąź tak, jakby powstała na najnowszym main:

git switch feature/login
git fetch origin
git rebase origin/main

Twoje commity zostaną „przeniesione” na koniec obecnego main. Historia będzie liniowa, ale przy bardziej skomplikowanych konfliktach rebase potrafi być trudniejszy w ogarnięciu psychicznie. Dlatego na start wystarczy merge; rebase traktuj jak opcję dla świadomych eksperymentów.

Mini-workflow dla małego zespołu (2–4 osoby)

Bez wdrażania korporacyjnych procedur da się mieć porządny obieg zmian:

1. Każda osoba pracuje w swojej gałęzi: feature/xyz lub bugfix/xyz.
2. Przed rozpoczęciem pracy – git pull na main i ewentualna aktualizacja swojej gałęzi przez merge main.
3. Po skończeniu zadania – push gałęzi i pull request do main.
4. Ktoś inny z zespołu robi szybki review (nawet 5 minut): patrzy, czy nie ma oczywistych błędów, powtarzającego się kodu, wątpliwych nazw.
5. Merge PR i usunięcie gałęzi.

To nadal jest lekkie procesowo, ale eliminuje wrzucanie wszystkiego wprost do main. Koszt na osobę: kilka minut dziennie, zysk: dużo mniej „niespodzianek” na środowisku produkcyjnym i jaśniejsza historia zmian.

Praca równolegle na dwóch komputerach: minimalny zestaw nawyków

Częsty scenariusz: laptop + komputer stacjonarny. Najprostszy sposób, żeby nie mieszać sobie w commitach:

• pracujesz zawsze z tym samym zdalnym repo (GitHub),
• na każdym komputerze używasz tych samych gałęzi (nazwy identyczne),
• przed pracą – git pull, po pracy – git push.

Jeśli na komputerze A zacząłeś zmianę na feature/login, na komputerze B nie rób kolejnej gałęzi feature/login2. Zamiast tego:

1. Na A: zrób kilka commitów i git push.
2. Na B: git fetch + git switch feature/login (jeśli gałąź nowa) lub git pull (jeśli już istnieje lokalnie).

W efekcie gałąź jest jedna, czytelna, praca się nie duplikuje. Zero dodatkowych narzędzi, tylko trochę dyscypliny.

Bezpieczne „testowanie na żywym organizmie”: branch + deploy

Nawet przy tanim hostingu albo darmowym serwerze można mieć prosty system testów bez kupowania dodatkowej infrastruktury. Przykładowy wariant:

• main jest wdrażany na produkcję (np. przez ręczny deploy z GitHuba lub prosty skrypt),
• gałąź staging (lub test) ląduje na tanim środowisku testowym,
• feature gałęzie łączysz najpierw z staging, sprawdzasz w przeglądarce, a dopiero potem z main.

Jeśli nie chcesz nawet płacić za środowisko testowe, można użyć darmowych GitHub Pages albo podobnych rozwiązań CI/CD z darmowym progiem. Klucz jest taki: nie mieszasz kodu „do testów” z kodem „gotowym do wysłania klientowi”. Gałęzie dają ci izolację praktycznie za darmo – koszt to tylko parę prostych komend i odrobina konsekwencji.

Tagi wersji: prosty sposób na „stabilne checkpointy”

Gdy projekt dojrzewa, dobrze jest oznaczać stabilne punkty w historii, np. kolejne wydania. Tagi są do tego idealne – niewiele droższe w obsłudze niż commit, a znacznie ułatwiają życie:

# utworzenie taga z opisem na aktualnym commicie
git tag -a v1.0.0 -m "Pierwsza stabilna wersja"

# wypchnięcie tagów na GitHuba
git push --tags

W praktyce: coś się sypie po wdrożeniu nowej funkcji, klient dzwoni, że „wczoraj wszystko działało”. Z tagiem v1.0.0 możesz w kilka sekund wrócić do znanego, stabilnego stanu:

git checkout v1.0.0

To nie musi być oficjalne semver w wielkim projekcie. Nawet proste oznaczenia typu demo-klient-x czy wersja-na-prezentacje już robią różnicę.

Minimalne podejście do commit message: tanio, ale czytelnie

Nie trzeba od razu przyjmować korporacyjnych konwencji typu „Conventional Commits”, ale kompletny chaos też kosztuje – głównie czas przy debugowaniu. Kilka lekkich zasad, które można wdrożyć od ręki:

• jedna zmiana = jeden commit (w miarę możliwości),
• opis w trybie rozkazującym: Dodaj walidację emaila, Napraw stylowanie nagłówka,
• bez commitów typu fix, update, zmiany – po tygodniu nic z nich nie wynika.

Przykłady krótkich, a jednak użytecznych komunikatów:

• Dodaj logowanie przez Google
• Usuń zbędne console.log z modułu koszyka
• Napraw błąd walidacji hasła przy rejestracji

To wciąż szybkie w pisaniu, ale gdy patrzysz w git log po miesiącu, realnie rozumiesz, co się działo. Zaoszczędzony czas na „co ja tutaj właściwie robiłem?” szybko się zwraca.

Przywracanie zmian bez paniki: `revert` zamiast grzebania w historii

Zdarza się, że zły commit trafi do main lub wyląduje na GitHubie. Zamiast „cofać historię” i ryzykować, że ktoś już na niej pracuje, najczęściej wystarczy:

# znajdź commit do odwrócenia
git log --oneline

# utwórz nowy commit, który neguje wskazany
git revert <hash-commita>

git revert tworzy nowy commit, który odwraca zmiany starego. Historia jest liniowa, nic nikomu nie „ucieka spod nóg”. Dla pracy zespołowej to dużo bezpieczniejsze niż agresywne git reset --hard na gałęziach, które już poleciały na GitHuba.

Awaryjne „czasowe schowanie” zmian: `stash` na ratunek

Typowa sytuacja: jesteś w połowie pracy nad funkcją, ale trzeba szybko przełączyć się na main, żeby zrobić hotfixa. Zmiany są brudne, commitować nie ma sensu. Zamiast kopiować pliki ręcznie:

# schowaj aktualne, niezakomitowane zmiany
git stash

# przełącz się na inną gałąź, zrób hotfixa
git switch main

# po wszystkim wróć na swoją gałąź i przywróć stash
git switch feature/login
git stash pop

To prosty bufor na „rozgrzebane” prace. Gdy nie mieszamy stasha z zaawansowanymi operacjami na historii, jest praktycznie bezkosztowy mentalnie, a ratuje z wielu sytuacji, w których inaczej kończy się na chaotycznych commitach typu „w trakcie prac, żeby tylko nie zgubić”.

Najczęściej zadawane pytania (FAQ)

Po co mi Git, skoro mogę robić kopie projektu w folderach i ZIP-ach?

Ręczne kopiowanie folderów szybko kończy się chaosem: projekt_v1, projekt_v2_poprawki, projekt_ostateczna itd. Nie masz jasnej historii zmian, trudno porównać wersje, a cofnięcie się do stabilnej wersji zajmuje mnóstwo czasu. Do tego łatwo przypadkiem nadpisać cudzą pracę lub zgubić działającą wersję.

Git automatycznie zapisuje kolejne „migawki” projektu (commity) w jednym repozytorium. W kilka sekund możesz zobaczyć, co się zmieniło, kto to zrobił i w razie potrzeby wrócić do poprzedniej wersji. Zamiast trzymać dziesiątki kopii na dysku i pendrive, masz jedno repo z pełną historią i prostym cofnięciem zmian.

Jaka jest różnica między Git a GitHub i czy muszę używać obu?

Git to narzędzie instalowane na twoim komputerze. Śledzi historię zmian w projekcie, pozwala tworzyć commity, gałęzie i cofać się do poprzednich wersji – wszystko lokalnie, nawet bez internetu. GitHub to z kolei serwis w chmurze, który przechowuje zdalne repozytoria i ułatwia współpracę (pull requesty, podgląd historii, ustawianie uprawnień).

Na start wystarczy sam Git lokalnie. GitHub opłaca się dodać, gdy chcesz mieć darmowy backup w chmurze i proste portfolio do podlinkowania w CV. Nie jest to dodatkowy koszt sprzętowy ani czasowy – raz ustawione repo na GitHubie sprowadza się do okazjonalnych komend git push i git pull.

Co to jest repozytorium w Git i jak je stworzyć krok po kroku?

Repozytorium to folder projektu, w którym Git trzyma historię zmian. Po uruchomieniu git init w katalogu z kodem powstaje ukryty folder .git – tam lądują wszystkie informacje o commitach i gałęziach. Możesz mieć repozytorium tylko lokalne albo połączone z GitHubem (zdalne repozytorium jako kopia w chmurze).

Najprostsza ścieżka na start wygląda tak:

• wejdź do katalogu projektu: cd nazwa-projektu
• zainicjuj repozytorium: git init
• dodaj pliki: git add .
• zrób pierwszy commit: git commit -m "Pierwszy commit"

To wystarczy, żeby mieć lokalną „time machine” do kodu. Dopiero później możesz podpiąć GitHuba, gdy uznasz, że chcesz kopię w chmurze lub współpracować z innymi.

Co to jest commit i jak często powinienem commitować?

Commit to zapisany zestaw zmian z krótkim opisem – taki punkt w historii projektu, do którego możesz się zawsze cofnąć. Ma własny identyfikator (hash), autora, datę i różnice względem poprzedniego stanu. Raz zapisany commit w praktyce traktujesz jako niezmienny.

Najtaniej czasowo jest robić małe, logiczne commity: jeden commit = jedna w miarę spójna zmiana. Zamiast jednego wielkiego „update” lepiej kilka typu: „Dodaj obsługę błędnego hasła”, „Popraw wyświetlanie komunikatu błędu”. Dzięki temu łatwo znaleźć moment, w którym coś się zepsuło, i w razie potrzeby cofnąć tylko konkretną zmianę, a nie pół projektu.

Czym jest branch (gałąź) w Git i po co mi gałęzie w małym projekcie?

Branch to osobna linia rozwoju kodu w jednym repozytorium. Najczęściej masz gałąź main z działającą, „produkcyjną” wersją projektu, a dodatkowe gałęzie tworzysz na potrzeby nowych funkcji albo eksperymentów, np. feature/login.

Nawet w jednoosobowym, małym projekcie gałęzie oszczędzają czas i nerwy. Możesz spokojnie testować duże zmiany na osobnej gałęzi, bez ryzyka rozwalenia działającej prezentacji czy demo. Jeśli eksperyment nie wychodzi, po prostu wracasz do main, zamiast ręcznie odkręcać serię plików.

Co oznaczają working directory, staging area i HEAD w Git?

Te trzy pojęcia opisują, na jakim etapie są twoje zmiany. Working directory to bieżący folder z plikami, które edytujesz w edytorze. Staging area (index) to „półka do zatwierdzenia” – lądują tam pliki dodane komendą git add. HEAD wskazuje na ostatni commit w aktualnej gałęzi, czyli to, co jest już zapisane w historii.

Typowy cykl pracy wygląda tak: modyfikujesz pliki (working directory) → wybierasz, co ma trafić do commita (git add – staging area) → zapisujesz zmiany w historii (git commit – aktualizacja HEAD). Świadomość, na którym poziomie jest dana zmiana, rozwiązuje wiele zagadek typu „czemu tego nie widać na GitHubie?” – zwykle dlatego, że coś nie zostało dodane albo zacommitowane.

Czy mogę używać Git bez internetu i bez mocnego sprzętu?

Tak. Git działa w pełni lokalnie, więc do pracy z commitami, gałęziami i historią nie potrzebujesz sieci ani serwera. Każde lokalne repozytorium jest kompletne, a operacje Gita są lekkie – nie wymaga to szybkiego dysku ani mocnego procesora. Na starszym laptopie komendy Gita wciąż wykonują się w ułamku sekundy.

Internet przydaje się dopiero, gdy chcesz zsynchronizować repozytorium ze zdalnym serwerem (np. GitHubem) lub współpracować z kimś innym. Taki model „offline najpierw” dobrze się sprawdza, gdy masz ograniczony dostęp do sieci albo pracujesz w podróży.

Bibliografia i źródła

• Pro Git (2nd Edition). Apress (2014) – Kompleksowe wprowadzenie do Gita: repozytoria, commity, branche, workflow
• Git Reference Manual. Free Software Foundation – Oficjalna dokumentacja poleceń Git i modelu pracy (HEAD, index, working tree)
• GitHub Docs: About GitHub. GitHub – Opis roli GitHuba, zdalnych repozytoriów, pull requestów i współpracy zespołowej