Git od zera: commit, branch i pull request na przykładach z życia

Po co mi Git, skoro „działa mi kopiuj-wklej”?

Foldery typu „projekt_kopia_ostatnia_na_pewno” kontra Git

Klasyczny scenariusz: pracujesz nad projektem w jednym folderze. Co kilka dni robisz jego kopię, bo „na wszelki wypadek”. Powstaje więc ciąg katalogów: projekt, projekt_stary, projekt_ostatni, projekt_ostatni_na_pewno, a po dwóch tygodniach już nikt nie wie, co jest aktualne. W efekcie tracisz czas na porównywanie plików, przepisywanie zmian i ręczne łączenie wersji.

Git rozwiązuje ten chaos systemowo. Zamiast produkować nieskończoną liczbę kopii katalogu, w jednym folderze masz historię wszystkich zmian. Każdy commit w Git to „migawka” projektu, do której możesz wrócić. Wszystko siedzi w jednym repozytorium, a narzędzia Gita dbają o śledzenie, wersjonowanie i łączenie zmian. Z zewnątrz nadal widzisz normalne pliki, ale w tle działa bardzo sprytny system kontroli wersji.

Różnica w praktyce jest prosta: bez Git sam pilnujesz wersji i kopii. Z Gitem powierzysz to wyspecjalizowanemu narzędziu, które robi to szybciej, precyzyjniej i bezlitośnie konsekwentnie. Mniej ręcznego kopiuj-wklej, więcej realnej pracy nad kodem czy plikami.

Co realnie daje Git: mniej stresu, więcej kontroli

Git ma dziesiątki komend, ale dla osoby początkującej liczy się kilka głównych korzyści:

• Cofanie zmian – możesz wrócić do poprzedniego stanu pliku lub projektu, gdy „coś poszło nie tak”.
• Historia – widzisz, kto, kiedy i co zmienił. W projektach solo docenisz to po kilku miesiącach, gdy zapomnisz, po co zrobiłeś dany hack.
• Bezpieczne eksperymenty – branch pozwala testować pomysły obok stabilnej wersji, bez ryzyka rozwalenia wszystkiego.
• Współpraca – wiele osób może pracować równolegle na tych samych plikach, a Git pomaga ich zmiany łączyć.

Największy zysk to spadek stresu: przestajesz bać się zmian. Jeśli commitujesz regularnie, zawsze możesz się wycofać o krok lub dwa. Nie musisz już trzymać w pamięci, co dokładnie zmieniłeś wczoraj – historii możesz zaufać bardziej niż własnym notatkom.

Minimalny próg wejścia: kilka komend, które dają 80% efektu

Do codziennej pracy nie trzeba znać całej dokumentacji Gita. Na start wystarczy zestaw:

• git status – sprawdzasz, co się zmieniło.
• git add – oznaczasz pliki, które mają wejść do commita.
• git commit – zapisujesz zmianę w historii.
• git log – oglądasz historię commitów.
• git branch, git checkout -b – tworzysz i przełączasz gałęzie.
• git push, git pull – wysyłasz i pobierasz zmiany z serwera (GitHub itp.).

Z tym zestawem da się spokojnie obsłużyć mały projekt solo i prostą współpracę w zespole. Pozostałe polecenia dojdziesz stopniowo, gdy faktycznie staną się potrzebne. To podejście oszczędza czas – zamiast uczyć się teorii, budujesz nawyk konkretnego workflow.

Przykład z życia: szybki fix po nocy i cofnięcie popsutego pliku

Wyobraź sobie klasyczną sytuację: jest późno, ktoś zgłasza błąd na produkcji. Wchodzisz w projekt, robisz szybki fix, „bo przecież to drobiazg”. Rano okazuje się, że naprawiając jedno, popsułeś coś innego. Gdy nie masz Git, zaczyna się cofanie zmian na ślepo, porównywanie ze starymi kopiami, czasem odtwarzanie kodu z pamięci.

Z Git scenariusz jest prosty: przed nocną zmianą robisz commit aktualnego stanu. Wprowadzasz fix, testujesz, commit. Rano, jeśli wyjdą problemy, masz dwie opcje: albo poprawiasz na bazie tego commita, albo cofnięciem (np. revert) wracasz do poprzedniej wersji, która działała. Masz spokój: żadna zmiana nie ginie, każda jest opisana w historii.

Szybki start: konfiguracja Git w wersji „bez bólu”

Najprostsza instalacja Git na Windows, macOS i Linux

Zaczyna się prosto: Git trzeba zainstalować tylko raz. Najkrótsze, sprawdzone ścieżki:

• Windows – wejdź na oficjalną stronę git-scm.com, pobierz instalator i przejdź proces klikając „Next”. Domyślne ustawienia są w 99% przypadków wystarczające. Po instalacji włącz „Git Bash” lub zwykły terminal w VS Code.
• macOS – najprościej: zainstaluj Xcode Command Line Tools. W terminalu wpisz git; system zaproponuje instalację. Alternatywnie użyj Homebrew: brew install git.
• Linux – użyj menedżera pakietów, np. sudo apt install git (Debian/Ubuntu), sudo dnf install git (Fedora) lub odpowiednik w Twojej dystrybucji.

Po instalacji sprawdź wersję:

git --version

Jeśli terminal zwraca numer wersji, Git działa. Cała operacja zajmuje kilka minut, a konfigurację wykonujesz raz na danej maszynie.

Ustawienie nazwy i maila – mały krok, który ratuje historię

Git w każdym commicie zapisuje dwie ważne informacje: autora i email. Bez tego historia repozytorium robi się anonimowa albo pełna przypadkowych danych z systemu. Warto od razu ustawić globalne dane użytkownika:

git config --global user.name "Twoje Imię i Nazwisko"
git config --global user.email "twoj.mail@example.com"

Dla projektów komercyjnych użyj służbowego adresu mailowego, dla własnych – dowolnego, byle stabilnego. Sprawdzenie konfiguracji:

git config --global --list

W odpowiedzi zobaczysz m.in. user.name i user.email. Ten krok kosztuje kilkanaście sekund, a czytelna historia commitów oszczędzi nerwów, gdy zespół będzie analizował, kto wprowadził daną zmianę.

Terminal, VS Code czy GUI? Wybór narzędzia dla początkującego

Do pracy z Git możesz używać:

• czystego terminala – pełna kontrola, zero kosztów, najbardziej „uniwersalny” sposób. Dobrze uczy podstaw, ale wymaga zapamiętywania komend;
• wbudowanego Gita w VS Code – wygodna, darmowa opcja: widzisz zmiany w plikach, możesz klikać w przyciski Commit, Push, a pod spodem i tak działa Git;
• prostych GUI (np. GitHub Desktop, Sourcetree) – wszystko „na kliknięcie”, ale czasem ukrywa, co realnie dzieje się pod spodem.

Jako podejście „budżetowego pragmatyka” dobrze sprawdza się połączenie: VS Code + podstawowe komendy w terminalu. VS Code jest darmowy, działa na wszystkich platformach i ma dobry podgląd różnic oraz integrację z GitHubem. Terminal wbudowany w VS Code pozwala bez skakania między oknami wykonywać git status, git add, git commit.

Darmowe konto na GitHub, GitLab lub Bitbucket – czy i kiedy zakładać

Lokalnie Git działa bez żadnego konta. Jednak przy pierwszej współpracy zespołowej i potrzebie backupu poza swoim komputerem przyda się zdalne repozytorium:

• GitHub – najpopularniejsza platforma, świetna do projektów open source i portfolio; darmowe prywatne repozytoria.
• GitLab – dobre do projektów firmowych, oferuje własny hosting, rozbudowane CI/CD.
• Bitbucket – popularny w środowisku Atlassian (Jira, Confluence).

Na start w 90% przypadków wystarczy darmowy GitHub. Założenie konta jest jak w dowolnym serwisie: email, login, hasło. Możesz spokojnie zacząć naukę Git lokalnie, a konto założyć dopiero, gdy będziesz chciał przesłać repozytorium do internetu, pochwalić się kodem lub popracować z kimś w zespole.

Pierwsze repozytorium: od pustego folderu do śledzenia zmian

Czym jest repozytorium Git, a czym zwykły katalog

Zwykły katalog z plikami to po prostu folder na dysku. System operacyjny nie przechowuje historii zmian, nie wie, która wersja pliku była wczoraj. Git zmienia ten obraz: repozytorium to folder, w którym oprócz plików projektowych istnieje specjalny, ukryty katalog .git. W nim Git trzyma całą historię, metadane, informacje o branchach i commitach.

Z punktu widzenia użytkownika nie ma różnicy w pracy na pliku: nadal edytujesz go w ulubionym edytorze. Różnica pojawia się w możliwości zapisania stanu projektu poprzez commit, obejrzenia historii (git log) i cofnięcia się do wybranej wersji. Git działa obok ciebie, a nie zamiast ciebie.

Tworzenie repozytorium komendą git init – prosty przykład

Załóżmy, że chcesz wersjonować prosty projekt HTML. Procedura:

1. Utwórz folder moja-strona i wejdź do niego: cd moja-strona.
2. Uruchom: git init.

W odpowiedzi zobaczysz komunikat typu: Initialized empty Git repository in …. Od tego momentu:

• folder moja-strona jest repozytorium Git,
• pojawił się ukryty katalog .git,
• możesz zacząć wykonywać git status, git add, git commit.

Dodaj plik index.html, zapisz kilka linijek kodu, a potem:

git status

Git pokaże, że jest nowy, nieśledzony plik. To pierwszy sygnał, że wszystko działa. Kolejne kroki to dodanie pliku do śledzenia i wykonanie pierwszego commita – do tego wrócimy w dalszej części, gdy omówione zostaną commity.

Rola katalogu .git – dlaczego lepiej go nie ruszać

Katalog .git to „mózg” repozytorium. Zawiera:

• informacje o aktualnej gałęzi i wskaźniku HEAD,
• historię commitów,
• konfigurację repo (np. zdalne adresy),
• informacje o tagach, branchach, referencjach.

Usunięcie katalogu .git z repozytorium sprowadza je do zwykłego folderu z plikami – tracisz historię, branch, wszystko. Nie ma sensu tam ręcznie grzebać, zwłaszcza na początku. Jeśli chcesz zobaczyć, co się dzieje, lepiej używać bezpiecznych poleceń: git status, git log, git branch.

git status jako codzienne „lustro” stanu repozytorium

Najważniejsze nawyki pracy z Git zaczynają się od jednego polecenia:

git status

Git wyświetli, w jakiej gałęzi jesteś, które pliki są:

• nieśledzone (untracked) – nowe pliki, których Git jeszcze nie zna,
• zmodyfikowane (modified) – pliki, które już były w repo, ale zostały zmienione,
• dodane do stage (staged) – gotowe do zapisania w najbliższym commicie.

Najprostsza checklista pracy z Git może wyglądać tak:

• po wejściu w projekt: git status, żeby zobaczyć punkt wyjścia,
• po zrobieniu kilku zmian: git status, żeby ocenić, co zmodyfikowałeś,
• przed commitem: git status, aby upewnić się, że do stage wchodzi to, co trzeba.

Kilka szybkich wywołań git status dziennie potrafi oszczędzić wielokrotnie więcej czasu na debugowaniu błędów typu „zapomniałem dodać ten plik” lub „zacommitowałem śmieciowy log”.

Commit – zapis stanu projektu „na zawsze”

Staging, git add i commit – trzy poziomy zmian

Git rozróżnia trzy poziomy, na których dzieją się zmiany:

• katalog roboczy (working directory) – bieżące pliki na dysku, które edytujesz,
• staging area (index) – zestaw zmian przygotowanych do commita,
• repozytorium (history) – zatwierdzone commity, stała historia.

Typowy cykl wygląda tak:

1. Edytujesz pliki – zmiany trafiają do working directory.

Dodawanie zmian do stage: selektywnie czy „na pałę”?

Kiedy zmienisz pliki, Git traktuje je jako zmodyfikowane w katalogu roboczym. Żeby trafiły do commita, muszą przejść przez stage (index). Służy do tego git add:

• git add nazwa_pliku – dodaje konkretny plik do stage,
• git add . – dodaje wszystkie zmiany w bieżącym katalogu (i podkatalogach),
• git add -p – pozwala dodać zmiany kawałkami (hunkami), fragment po fragmencie.

Scenariusz z życia: poprawiasz błąd w formularzu i przy okazji lekko czyścisz CSS. Chcesz mieć osobny commit na bugfix i osobny na sprzątanie styli. Zamiast walić git add .:

1. Sprawdzasz stan: git status.
2. Dodajesz tylko pliki od błędu w formularzu: git add form.js, git add form.html.
3. Commitujesz: git commit -m "Naprawa walidacji formularza kontaktowego".
4. Później dodajesz CSS: git add style.css, osobny commit na porządki.

Dzięki temu, gdy QA zgłosi regresję w formularzu, wiesz, do którego commita się cofnąć, a nie rozgrzebujesz wszystkiego, łącznie z kosmetyką w CSS.

Pierwszy commit – prosty, ale świadomy przykład

Załóżmy, że w projekcie moja-strona masz tylko index.html z minimalnym szkieletem. Chcesz, by pierwszy commit był czystym startem projektu, bez śmieciowych plików typu .DS_Store czy tymczasowych backupów z edytora.

Sekwencja kroków:

1. git status – zobaczysz Untracked file: index.html.
2. git add index.html
3. git status – plik jest teraz w sekcji Changes to be committed.
4. git commit -m "Inicjalny szkielet strony głównej"

Po commicie stan się czyści – git status pokazuje brak zmian. Masz pierwszą wersję projektu, do której możesz wrócić w każdej chwili. Nie trzeba robić kopii folderu „moja-strona-kopia-2-bardzo-ostateczna”.

Jak pisać sensowne wiadomości commita bez marnowania czasu

Dobra wiadomość commita nie musi być literacka. Ma odpowiedzieć na pytanie: co i po co zostało zrobione. Zazwyczaj wystarcza jedna linijka w trybie rozkazującym:

• Dodaj sekcję FAQ na stronie głównej
• Napraw błędny link w stopce
• Usuń nieużywane style dla starego layoutu

Lepiej unikać opisów typu fix, zmiany, update. Po miesiącu nic to nie znaczy. Nawet jeśli commit powstał „na szybko”, dopisanie 2–3 sensownych słów kosztuje kilka sekund, a potrafi zaoszczędzić długie grzebanie w logach.

Jeśli zmiana jest bardziej złożona, możesz użyć dłuższej formy:

git commit

Dodaj paginację do listy artykułów

- dodano parametry page i limit w API
- uzupełniono testy integracyjne
- dostosowano widok listy artykułów w panelu admina

Taka wiadomość nadal powstaje w parę minut, a przy debugowaniu lub code review daje pełny obraz zmian.

Podgląd historii: git log bez przełączania się w archeologa

Historia commitów to Twoje archiwum. Najprostszy podgląd to:

git log

Domyślnie pokazuje każdy commit z:

• identyfikatorem (hash),
• autorem,
• datą,
• wiadomością.

Bardziej kompaktowa i praktyczna forma:

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

Przydaje się, kiedy pojawią się gałęzie – widać wtedy drzewko historii. Żeby nie klepać tego za każdym razem, możesz dodać alias:

git config --global alias.lg "log --oneline --graph --decorate --all"

Od teraz wystarczy git lg. Taka „optymalizacja lenistwa” szybko się zwraca, zwłaszcza gdy często sprawdzasz historię w pracy zespołowej.

Cofanie zmian zanim trafią do commita

Błąd zdarza się każdemu – czasem zapiszesz plik, który nie powinien trafić do repo, albo nadpiszesz coś przypadkiem. Zanim zaczniesz panikować, przeleć prostą checklistę:

• zmiana tylko w working directory – użyj git restore plik, by wrócić do wersji z ostatniego commita,
• plik w stage, ale jeszcze bez commita – użyj git restore --staged plik, żeby wyrzucić go ze stage (zmiana zostaje w katalogu roboczym),
• commit już zrobiony, ale jeszcze nie wypchnięty – użyj git commit --amend lub git reset --soft HEAD~1 (ostrożnie, zanim zaczniesz współdzielić historię).

Praktyczny przykład: dodałeś do stage plik .env z hasłami, ale jeszcze nie zrobiłeś commita. Szybka reakcja:

git restore --staged .env
echo ".env" >> .gitignore
git add .gitignore
git commit -m "Dodaj .env do .gitignore"

Hasła nie trafiły do historii, a na przyszłość problem załatwia .gitignore.

Gałęzie (branch): osobny tor jazdy dla zmian

Po co w ogóle branch, skoro „mogę robić wszystko na mainie”

Praca tylko na main (dawniej master) działa przy jednoosobowym hobby-projekcie, ale szybko mści się w większym zespole. Gałezie pozwalają:

• rozdzielić stabilny kod produkcyjny od eksperymentów,
• pracować nad kilkoma zadaniami równolegle, bez wchodzenia sobie w drogę,
• łatwiej robić code review i pull requesty.

W praktyce branch to po prostu „wskaźnik” na określony commit. Możesz mieć ich dziesiątki, a na dysku nadal jest jedna kopia projektu – nie duplikuje to całego katalogu, więc nie zjada miejsca jak foldery „projekt-v2”, „projekt-v3-final”.

Tworzenie nowej gałęzi: taniej niż kopia folderu

Podstawowe polecenia związane z branchami:

• git branch – lista gałęzi,
• git branch nazwa – utworzenie nowej gałęzi,
• git checkout nazwa – przejście na istniejącą gałąź,
• git switch nazwa – nowsza, czytelniejsza forma przełączenia,
• git switch -c nazwa – utworzenie i przełączenie w jednym kroku.

Przykład: chcesz dodać sekcję „O nas” do strony, bez mieszania w stabilnym main:

git switch -c feature/sekcja-o-nas

Została utworzona nowa gałąź feature/sekcja-o-nas, wskazująca dokładnie na ten sam commit co main. Od teraz każdy commit robisz już na nowym torze. Jeśli okaże się, że pomysł jest chybiony, możesz po prostu nie mergować tej gałęzi z powrotem – nie niszczy to stabilnego kodu.

Nazewnictwo branchy: mało ceremonii, dużo klarowności

Nie trzeba wprowadzać skomplikowanych konwencji, ale dobrze, gdy z samej nazwy gałęzi widać jej przeznaczenie. Prosty, sprawdzony schemat:

• feature/nazwa-funkcjonalnosci – nowe funkcje,
• bugfix/opis-problemu – poprawki błędów,
• hotfix/krytyczny-problem – szybkie poprawki na produkcji,
• chore/porzadki – sprzątanie, zmiany techniczne bez efektu dla użytkownika.

Zamiast nowa-galaz lepiej nazwać gałąź feature/paginacja-artykulow. Po kilku tygodniach nie będziesz się zastanawiać, co tam było robione.

Przełączanie się między branchami – kiedy można, a kiedy nie

Gałąź zmieniasz w prosty sposób:

git switch main

Git nie pozwoli przełączyć się, jeśli masz niezacommitowane zmiany, które mogłyby się „pogryźć” z drugim branchem. W takim razie masz kilka opcji:

• szybki commit, jeśli zmiany są sensowne i kompletne,
• git stash – tymczasowe odłożenie zmian na bok,
• ręczne wycofanie (np. git restore plik), jeśli zmiany są śmieciowe.

Prosty workflow: pracujesz nad sekcją „O nas”, ale nagle trzeba poprawić pilny błąd w stopce na produkcji. Nie chcesz mieszać tych tematów:

1. git stash – odkładasz bieżące zmiany.
2. git switch main – wracasz na stabilną gałąź.
3. Tworzysz hotfix, robisz poprawkę i wypychasz.
4. git switch feature/sekcja-o-nas, potem git stash pop – przywracasz zmiany i kontynuujesz pracę.

Bez branchy takie akcje kończą się często chaotycznym kopiowaniem plików i zgadywaniem, co było „na pewno do wyrzucenia”.

Praca na gałęzi krok po kroku – mini workflow na mały feature

Scenariusz: dodanie prostego modułu „newsletter”

Wyobraźmy sobie mały, ale typowy task: na stronie trzeba dodać formularz zapisu do newslettera. Wersja minimum – sekcja z polem email, bez backendu. Chodzi o przećwiczenie sensownego podziału pracy na gałęzi.

Punkt wyjścia: masz aktualną gałąź main z działającą stroną. Zanim zaczniesz:

1. Aktualizujesz maina ze zdalnego repo: git pull (o szczegółach później).
2. Sprawdzasz stan: git status – brak lokalnych zmian.

1. Utworzenie gałęzi i przejście na nią

Zakładasz nowy branch na feature:

git switch -c feature/newsletter

Jesteś teraz w feature/newsletter, ale pliki na dysku są identyczne jak na main. Od tego miejsca wszystkie commity będą „przyklejać się” do tej gałęzi.

2. Małe porcje pracy zamiast jednego „mega commita”

Najgorszy wariant to dzień pracy i jeden commit typu Dodano newsletter, zawierający zmiany w dziesięciu plikach. Dużo rozsądniej podzielić zadanie na mniejsze kroki, np.:

1. Dodanie HTML sekcji newsletter.
2. Style wizualne.
3. Podstawowa walidacja po stronie klienta (np. prosty check formatu emaila w JS).

Takie porcje są łatwiejsze do review, cofania i debugowania. A kosztują tylko trochę więcej uwagi przy commitowaniu.

3. Pierwsza porcja: struktura HTML

Dodajesz sekcję w index.html. Gdy jesteś zadowolony z podstawowego markup:

git status
git add index.html
git commit -m "Dodaj sekcję newsletter z formularzem email"

Jeśli przy okazji dotknąłeś innego pliku (np. dodałeś link do sekcji w nawigacji), możesz albo:

• wrzucić go do tego samego commita, jeśli to jedna logiczna zmiana,
• przy bardziej skomplikowanych różnicach użyć git add -p i rozbić je na dwa commity.

4. Druga porcja: style

Tworzysz lub uzupełniasz newsletter.css albo edytujesz główny plik CSS. Po kilku iteracjach masz wersję akceptowalną wizualnie:

git status
git add style.css
git commit -m "Ostyluj sekcję newsletter zgodnie z layoutem strony"

Znów – jeden commit, jeden temat. Ktoś chce zmienić tylko wygląd? Szuka commitów dotyczących styli.

5. Trzecia porcja: logika w JS

Dodajesz prostą walidację emaila, przekazywanie danych do backendu lub mockowego endpointu. Po przetestowaniu:

6. Ostatnie szlify: lokalne porządki przed wypchnięciem gałęzi

Po kilku commitach masz działający moduł newslettera. Zanim pokażesz go światu (czyli zespołowi), zrób mały, tani przegląd jakości:

• test ręczny – krótko „przeklikaj” formularz: poprawny email, pusty, ewidentnie zły (np. aaa),
• sprawdź konsolę przeglądarki – czy nie wyskakują błędy JS,
• uruchom testy, jeśli są (np. npm test, pytest itp.),
• git status – upewnij się, że wszystko, co ma trafić do review, jest w commitach, a katalog roboczy jest czysty.

Masz jeszcze drobną, kosmetyczną poprawkę? Czasem prościej jest zrobić osobny mały commit niż na siłę dopychać go do poprzedniego za pomocą --amend. Poprzednie commity mogły już pójść na serwer – ryzykujesz mniej zamieszania w historii.

7. Synchronizacja z mainem: rebasing albo merge „tanio i bez filozofii”

Jeśli nad projektem pracuje więcej osób, gałąź main prawdopodobnie ruszyła od chwili, gdy stworzyłeś feature/newsletter. Im dłużej czekasz, tym większa szansa na konflikty. Lepiej raz na jakiś czas „dociągnąć” zmiany:

git switch main
git pull
git switch feature/newsletter
git merge main

Jeśli nie zależy ci na super „czystej” historii, prosty merge w zupełności wystarczy. Dla początkujących to mniej pułapek niż git rebase. Konfliktów nie unikniesz całkowicie, ale mała porcja konfliktów raz na dzień jest znacznie tańsza nerwowo niż wojna z setką plików po miesiącu pracy w odcięciu.

8. Zakończenie pracy na gałęzi: merge lokalny lub pull request

Gdy feature jest gotowy, masz dwa częste scenariusze:

• projekt jednoosobowy / mały, bez code review – robisz merge lokalnie,
• projekt zespołowy – otwierasz pull request (o tym szerzej niżej).

Prosta ścieżka dla pierwszego przypadku:

git switch main
git pull              # upewnij się, że main jest aktualny
git merge feature/newsletter
git push

Opcjonalnie możesz posprzątać gałąź:

git branch -d feature/newsletter

Usunięcie lokalnego brancha nie usuwa historii zmian – wszystkie commity żyją teraz na main. Zostaje po prostu jeden wskaźnik mniej na liście branchy.

Zdalne repozytorium: push, pull i klonowanie bez nadmiarowych opcji

Po co w ogóle zdalne repo, jeśli „mam wszystko na laptopie”

Lokalne repozytorium wystarczy na mikroprojekt, ale szybko pojawiają się praktyczne problemy:

• padł dysk – bez kopii w chmurze tracisz całą historię,
• chcesz pracować z domu i z biura – kopiowanie na pendrive w 2026 roku to średni pomysł,
• dołącza nowa osoba – musi jakoś pobrać aktualny stan projektu.

Zdalne repozytorium (GitHub, GitLab, Bitbucket, serwer firmowy) rozwiązuje to jednym mechanizmem. To po prostu dodatkowa kopia historii, z którą Git umie się synchronizować. Nie musisz opłacać rozbudowanych pakietów – na start w zupełności wystarczą darmowe prywatne repozytoria.

Tworzenie zdalnego repo i połączenie z lokalnym

Zakładasz repozytorium np. na GitHubie, nazywasz je tak samo jak projekt. Widzisz adres w stylu:

git@github.com:twoj-login/moj-projekt.git
# albo
https://github.com/twoj-login/moj-projekt.git

W lokalnym katalogu:

git remote add origin git@github.com:twoj-login/moj-projekt.git

Słowo origin to domyślna nazwa „zdalnego” – możesz mieć ich kilka (np. origin i upstream), ale na start skup się na jednym.

Pierwszy push: wypchnięcie istniejącej historii

Masz już lokalne commity na main i chcesz je wysłać na serwer:

git push -u origin main

Parametr -u ustawia „śledzenie” – od tej pory na gałęzi main wystarczy zwykłe:

git push
git pull

Git zna powiązanie: lokalny main ↔ zdalny origin/main. Dzięki temu nie musisz za każdym razem podawać pełnego adresu.

Klonowanie istniejącego repozytorium

Z perspektywy nowej osoby w zespole najważniejsze polecenie to:

git clone git@github.com:twoj-login/moj-projekt.git

Git tworzy nowy katalog, pobiera całą historię i automatycznie ustawia origin. Po wejściu do katalogu domyślnie jesteś na main:

cd moj-projekt
git status

Od tego momentu pracujesz tak samo jak autor projektu: branch, commit, push, pull. Nie trzeba ściągać zipów ani ręcznie odtwarzać struktury katalogów.

Push: wysyłanie swoich commitów

Za każdym razem, gdy chcesz udostępnić innym swoje lokalne zmiany, robisz:

git push

Warunki są dwa: gałąź ma ustawione śledzenie (-u przy pierwszym pushu) i ktoś nie wypchnął w międzyczasie nowych commitów, z którymi twoje się gryzą. Jeśli druga sytuacja wystąpi, zobaczysz komunikat, że najpierw trzeba zrobić git pull.

Push jest stosunkowo tani – możesz zrobić kilka commitów lokalnie, a potem jednym push wypchnąć całą porcję. To prostsze i bezpieczniejsze niż kombinowanie z jednym wielkim commitem po kilku dniach.

Pull: pobieranie tego, co zrobili inni

git pull to skrót:

git fetch
git merge

Czyli: pobierz nowe commity ze zdalnego repo i połącz je z moją lokalną gałęzią. W prostym workflow wystarczy przed rozpoczęciem dnia pracy zrobić:

git switch main
git pull

i dopiero na aktualnym main tworzyć nowe branche na swoje feature’y. Minimalizujesz przez to konflikty i niespodzianki typu „u mnie działa, na mainie nie ma połowy zależności”.

Praca ze zdalnymi branchami: tanie zasady

Dla każdej gałęzi roboczej warto wykonać pierwszy push z parametrem -u:

git switch -c feature/newsletter
# kilka commitów...
git push -u origin feature/newsletter

Od teraz:

• git push – wysyła kolejne commity tej gałęzi,
• git pull – dociąga ewentualne zmiany, które ktoś dorzucił na ten sam branch (raczej rzadkie, jeśli każdy pracuje na swoim).

Kiedy gałąź zostanie zmergowana do main i nie jest już potrzebna, można ją usunąć także ze zdalnego repo:

git push origin --delete feature/newsletter

Utrzymywanie starych branchy latami tylko pożera uwagę przy każdym git branch -a. Kilka sekund na sprzątanie raz na jakiś czas oszczędza później dłuższe zastanawianie się, które gałęzie są jeszcze żywe.

Pull request (merge request): jak w praktyce „wnosić” zmiany do wspólnego projektu

Po co pull request, skoro mogę sam zrobić merge do maina

Bezpośredni merge do main daje szybką satysfakcję, ale ma kilka ukrytych kosztów:

• nikt nie rzuca okiem na zmiany – rośnie ryzyko bugów i dług techniczny,
• trudniej docenić i prześledzić, co kto zrobił,
• nie ma miejsca na pytania typu „czemu tak, a nie inaczej?”.

Pull request (w GitLabie: merge request) to tani proces kontroli jakości: wrzucasz swoją gałąź, zespół komentuje, ktoś inny klika „merge”. Jedno miejsce na dyskusję, historię decyzji i w razie czego łatwy powrót do konkretnego zestawu zmian.

Przygotowanie gałęzi do pull requesta

PR nie powinien być niespodzianką ani śmietnikiem. Przed otwarciem:

• zaktualizuj maina i swoją gałąź – git switch main, git pull, potem merge/rebase do feature’a,
• upewnij się, że testy przechodzą – lokalnie lub przez prosty skrypt CI, jeśli projekt go ma,
• przejrzyj własne diffy – git diff main...feature/newsletter albo podgląd w IDE.

Jeśli na diffie widzisz oczywiste śmieci (zakomentowany kod, debugowe console.log, tymczasowe pliki) – wyczyść je, zanim ktoś inny będzie musiał ci o tym pisać. To kilka minut pracy, które wprost skracają czas review.

Tworzenie pull requesta krok po kroku

Zakładamy, że pracujesz na GitHubie, ale na GitLabie/Bitbuckecie koncept jest identyczny:

1. Wypchnij swoją gałąź: git push -u origin feature/newsletter.
2. Wejdź w repo w przeglądarce – często pojawia się baner „Compare & pull request”. Jeśli nie, wybierz „New pull request” ręcznie.
3. Jako bazę ustaw main, jako gałąź źródłową – swój feature.
4. Uzupełnij tytuł i opis.

Tytuł nie musi być poetycki, ma być jednoznaczny: Dodaje moduł newsletter na stronie głównej. W opisie dobrze krótko wyjaśnić:

• co zostało zrobione (w punktach),
• jak testowałeś (np. „przeklikane scenariusze X, Y”),
• czy są znane ograniczenia („brak backendu, tylko mock”).

To zwykle 3–6 zdań. Dłuższe epopeje rzadko ktoś czyta, a pojedyncze „ fixed newsletter” nie daje recenzentowi żadnego kontekstu.

Zakres pull requesta: lepiej mniejszy, ale konkretny

PR załatwia konkretny temat. Jeśli w jednym PR wrzucasz:

• newsletter,
• refaktor całej nawigacji,
• aktualizację paczek,

to sam sobie wydłużasz czas review. Trudno ocenić ryzyko zmian i znaleźć konkretne błędy. Ekonomiczniej jest mieć dwa, trzy mniejsze PR-y niż jednego kolosa, który straszy każdego recenzenta.

Code review bez nadmiernej ceremonii

Ktoś z zespołu dostaje powiadomienie i ogląda twoje zmiany. Dobrze, gdy zasady są proste:

• komentarze techniczne, nie osobiste („ten warunek jest zbędny”, zamiast „czemu zawsze robisz…”),
• propozycje poprawek z krótkim uzasadnieniem („to można wyciągnąć do funkcji, bo używasz tego trzykrotnie”),
• oznaczanie, co jest „nice to have”, a co blokuje merge.

Jako autor możesz od razu odpowiadać na komentarze i poprawiać kod. Każdy nowy commit na tej samej gałęzi automatycznie dopisuje się do PR-a – nie trzeba zakładać nowego.

Wprowadzanie poprawek po review

Dostajesz kilka uwag typu „zmień nazwę funkcji”, „wywal logowanie”, „dodaj test na brak emaila”. Praca jest powtarzalna:

1. Wprowadzasz poprawki lokalnie.
2. Commitujesz: git commit -am "Adresuj uwagi z review: walidacja pustego emaila" (lub precyzyjniej, z git add).
3. Wypychasz: git push.

PR automatycznie aktualizuje się na serwerze. Przy drobnych rzeczach nie ma sensu bawić się w przepisywanie historii (rebase, fixup) – oszczędzasz czas. Sprzątanie historii commitów można rozważyć dopiero w dojrzałych zespołach, gdy naprawdę przeszkadzają drobne commity typu „popraw literówkę”.

Konflikty w pull requeście: minimalny zestaw ruchów

Gdy inny PR dotknął tych samych fragmentów plików, pojawi się informacja, że gałąź ma konflikty i nie da się jej zmergować automatycznie. Najprostszy scenariusz:

git switch main
git pull
git switch feature/newsletter
git merge main
# rozwiąż konflikty w edytorze
git add .
git commit
git push

Platforma PR powinna pokazać, że konflikty zniknęły. Nie ma potrzeby „czarować” z rebase, dopóki nie rozumiesz dokładnie, co robi – merge daje ci ten sam efekt przy mniejszym ryzyku pomyłki.

Scalenie PR i sprzątanie po sobie

Najczęściej zadawane pytania (FAQ)

Po co mi Git, skoro mogę robić kopie folderu projektu?

Ręczne kopiowanie folderów szybko kończy się chaosem: powstaje kilka wersji tego samego projektu i po tygodniu nikt nie wie, która jest aktualna. Tracisz czas na porównywanie plików, przepisywanie zmian i ręczne łączenie „co było z czego”. Git rozwiązuje to systemowo, trzymając całą historię zmian w jednym repozytorium.

Każdy commit to migawka stanu projektu, do której możesz wrócić w kilka sekund, bez szukania starych kopii. W praktyce: mniej ręcznego kopiuj–wklej, więcej realnej pracy nad kodem czy dokumentami, a do tego znacznie niższe ryzyko, że coś „przepiszesz” lub zgubisz.

Czy muszę znać wszystkie komendy Git, żeby zacząć?

Nie. Na start wystarczy kilka poleceń, które pokrywają większość codziennych potrzeb:

• git status – pokazuje, co się zmieniło,
• git add – wybierasz pliki do commita,
• git commit – zapisujesz zmianę w historii,
• git log – przeglądasz historię,
• git branch, git checkout -b – tworzysz i przełączasz gałęzie,
• git push, git pull – wysyłasz i pobierasz zmiany z serwera.

Z takim zestawem ogarniesz solo projekt i prostą współpracę w zespole. Reszty komend można uczyć się stopniowo, dopiero gdy realnie się przydadzą – to oszczędza czas i głowę.

Czy do korzystania z Git potrzebuję konta na GitHubie?

Nie, Git działa lokalnie bez żadnego konta. Możesz mieć repozytorium tylko na swoim komputerze i normalnie commitować, tworzyć branche czy cofać zmiany. To dobry, „bezbolesny” start – zero logowania, zero dodatkowych narzędzi.

Konto na GitHubie, GitLabie czy Bitbuckecie przydaje się dopiero, gdy chcesz: mieć kopię w chmurze (backup), współpracować z innymi albo pokazać swój kod światu. W 90% przypadków na początek wystarczy darmowy GitHub i jedno zdalne repozytorium na najważniejszy projekt.

Jak cofnąć popsute zmiany w Git, gdy „zepsułem projekt”?

Najprostszy scenariusz: regularnie commitujesz działający stan projektu. Jeśli po nocnym „szybkim fixie” coś popsujesz, możesz:

• zrobić kolejny commit z poprawką na bazie aktualnego stanu, albo
• użyć np. git revert, żeby odwrócić konkretny commit i wrócić do poprzedniej, działającej wersji.

Różnica wobec pracy bez Git jest taka, że nie cofasz zmian „na ślepo” i nie odtwarzasz kodu z pamięci. Historia commitów to twoje „bezpieczne kopie” z opisem, co i po co zmieniłeś.

Czy jako początkujący powinienem używać terminala czy graficznego narzędzia do Git?

Najtańszy i najbardziej uniwersalny wariant to terminal + darmowy edytor z prostą integracją z Git, np. VS Code. W terminalu uczysz się podstawowych komend, a VS Code pomaga wizualnie: pokazuje zmiany w plikach, pozwala kliknąć Commit czy obejrzeć różnice.

Typowy, „budżetowy” zestaw na start:

• VS Code jako edytor (darmowy, działa na wszystkich systemach),
• wbudowany terminal w VS Code do poleceń typu git status, git add, git commit,
• opcjonalnie proste GUI typu GitHub Desktop, jeśli bardzo nie lubisz linii komend.

Jak szybko i poprawnie skonfigurować Git po instalacji?

Po instalacji Git na Windows, macOS lub Linux warto zrobić jeden prosty krok: ustawić nazwę i email, które będą się pojawiały w commitach:

• git config --global user.name "Twoje Imię i Nazwisko"
• git config --global user.email "twoj.mail@example.com"

Dzięki temu historia nie będzie anonimowa ani „zaśmiecona” przypadkowymi danymi z systemu. Cała operacja zajmuje kilkanaście sekund i robisz ją raz na komputer – później każdy commit będzie czytelnie podpisany.

Czym jest branch w Git i po co go używać w małym projekcie?

Branch (gałąź) to osobna linia rozwoju projektu. Możesz na niej eksperymentować, robić większy refactoring czy testować nową funkcję, a stabilna wersja na głównej gałęzi (np. main) zostaje nietknięta. To tani sposób na bezpieczne eksperymenty, bez zakładania nowych folderów z kopiami projektu.

W praktyce: gdy chcesz dodać funkcję, robisz git checkout -b nowa-funkcja, pracujesz, commitujesz, a gdy jesteś zadowolony – łączysz zmiany z główną gałęzią. Jeśli coś pójdzie nie tak, zawsze możesz porzucić gałąź bez dotykania stabilnej wersji.

Co warto zapamiętać

• Kopiowanie całych folderów („projekt_kopia_ostatnia_na_pewno”) jest czasochłonne i podatne na błędy, podczas gdy Git trzyma wszystkie wersje w jednym repozytorium i pozwala wrócić do dowolnej migawki projektu jednym poleceniem.
• Największy praktyczny zysk z Gita to mniejszy stres i większa kontrola: regularne commity pozwalają bez strachu eksperymentować, cofać zmiany i nie trzymać w głowie szczegółów sprzed kilku dni.
• Do efektywnej pracy na start wystarczy kilka komend (status, add, commit, log, branch/checkout -b, push/pull), które dają około 80% codziennych efektów bez wkuwania całej dokumentacji.
• Git znacząco ułatwia cofanie popsutych zmian – zamiast ręcznie porównywać pliki i odtwarzać kod z pamięci, można wrócić do poprzedniego commita lub zrobić revert i odzyskać działającą wersję w minutę.
• Instalacja Gita jest jednorazowa, szybka i darmowa na wszystkich głównych systemach (Windows, macOS, Linux), a podstawowa konfiguracja użytkownika (user.name, user.email) kosztuje kilkanaście sekund i czyści historię zmian.
• Nie trzeba inwestować w płatne narzędzia – wygodny workflow da się zbudować na terminalu lub darmowym VS Code z wbudowaną obsługą Gita; graficzne klienty typu GitHub Desktop czy Sourcetree są tylko opcjonalnym ułatwieniem.