Git i GitHub – kompletny przewodnik dla początkujących

Jeśli zaczynasz swoją przygodę z programowaniem, prędzej czy później trafisz na dwa pojęcia, bez których nie wyobraża sobie pracy żaden developer: Git i GitHub. Brzmią podobnie, ale to zupełnie inne narzędzia – i żeby sprawnie pracować w IT, musisz dobrze rozumieć różnicę między nimi.

Ten przewodnik przeprowadzi cię przez wszystko, co potrzebujesz wiedzieć na start: czym jest Git, czym jest GitHub, jak zainstalować i skonfigurować środowisko, jakich komend używać na co dzień i jak wygląda prawdziwy workflow developerski. Prosto, konkretnie, z przykładami.

Według danych Stack Overflow, 93% developerów używa Gita jako systemu kontroli wersji – nikt inny nie zbliża się nawet do tego wyniku. Innymi słowy: Git to dziś nie opcja – to absolutna podstawa.

Git – co to jest i dlaczego to rewolucja w pracy z kodem?

Git to rozproszony system kontroli wersji (ang. Distributed Version Control System, DVCS) stworzony w 2005 roku przez Linusa Torvaldsa – tego samego, który zbudował jądro Linuxa. Jego pierwotnym celem było zarządzanie kodem źródłowym Linuxa, który tworzyli jednocześnie tysiące programistów na całym świecie.

Najprościej mówiąc: Git śledzi zmiany w twoich plikach. Każda zmiana, którą zatwierdzisz, zapisuje się w historii projektu. Dzięki temu możesz:

• cofnąć się do dowolnego punktu w historii kodu,
• pracować równolegle nad kilkoma funkcjonalnościami (gałęzie, ang. branches),
• zobaczyć, kto i kiedy wprowadził konkretną zmianę,
• współpracować z innymi programistami bez nadpisywania swoich zmian nawzajem.

Zanim Git stał się standardem, programiści radzili sobie, kopiując foldery z nazwami w stylu projekt_final, projekt_final_v2, projekt_NAPRAWDE_FINAL. Brzmi znajomo? Git rozwiązuje ten problem raz na zawsze.

GitHub – co to jest i czym różni się od Gita?

GitHub to platforma internetowa, która hostuje repozytoria Gita i dodaje do nich warstwę społecznościową oraz narzędzia do współpracy. Jeśli Git to silnik, GitHub to samochód zbudowany na tym silniku.

Kluczowe różnice między Git a GitHub:

• Git to oprogramowanie instalowane lokalnie na twoim komputerze,
• GitHub to serwis w chmurze – twoje repozytorium jest dostępne z każdego miejsca,
• Git działa bez internetu, GitHub wymaga połączenia,
• GitHub oferuje dodatkowe funkcje: Pull Requests, Issues, Actions (CI/CD), Wiki i wiele więcej.

GitHub, przejęty w 2018 roku przez Microsoft za 7,5 miliarda dolarów, to dziś największa platforma hostingowa kodu na świecie. Według oficjalnych danych GitHuba korzysta z niego ponad 180 milionów developerów i hostowanych jest tam ponad 420 milionów repozytoriów.

Istnieją też alternatywy: GitLab (popularny w polskich firmach ze względu na możliwość self-hostingu) i Bitbucket (integruje się z narzędziami Atlassian, jak Jira). Ale dla początkujących – zacznij od GitHuba.

Instalacja i konfiguracja Git – pierwsze kroki

Instalacja Git

• Windows: pobierz instalator ze strony git-scm.com. Podczas instalacji możesz zostawić domyślne opcje
• macOS: Git jest wbudowany w Xcode Command Line Tools. Wpisz w terminalu: xcode-select –install
• Linux (Ubuntu/Debian): sudo apt update && sudo apt install git

Sprawdź instalację – otwórz terminal i wpisz:

git --version

Konfiguracja Git – obowiązkowo po instalacji

Zanim zaczniesz pracować z Gitem, musisz ustawić swoje imię i adres e-mail. Git przypisuje te dane do każdego commita (zatwierdzonej zmiany), żebyś ty i twój zespół wiedzieli, kto co zrobił.

git config --global user.name "Twoje Imię"

git config --global user.email "twoj@email.com"

Flaga –global oznacza, że ustawienie dotyczy wszystkich repozytoriów na twoim komputerze. Możesz też skonfigurować domyślny edytor tekstu (np. VS Code: git config –global core.editor „code –wait”).

Git komendy – 15 poleceń, które musisz znać

Git ma ponad 150 komend, ale w codziennej pracy używasz może 15-20. Oto te najważniejsze, podzielone według etapów pracy.

Rozpoczynanie pracy z repozytorium

git init

Inicjalizuje nowe repozytorium Git w bieżącym folderze. Tworzy ukryty folder .git, w którym Git przechowuje całą historię projektu. Używasz tego raz – na początku projektu.

git clone [URL]

Pobiera istniejące repozytorium z GitHuba (lub innego serwera) na twój komputer. Automatycznie tworzy folder z nazwą projektu i konfiguruje połączenie ze zdalnym repozytorium.

Codzienna praca – zapisywanie zmian

git status

Pokazuje aktualny stan repozytorium: które pliki zostały zmienione, które są gotowe do commita, a których Git jeszcze nie śledzi. To twój najlepszy przyjaciel – używaj go często.

git add [plik] lub git add .

Dodaje zmienione pliki do tzw. staging area – strefy pośredniej, z której commitujesz zmiany. git add . dodaje wszystkie zmienione pliki naraz. To celowe działanie: możesz commitować tylko wybrane zmiany.

git commit -m „Treść commita”

Zapisuje zmiany w historii repozytorium. Flaga -m pozwala dodać opis (commit message) bezpośrednio w linii komend. Dobry opis commita zaczyna się od czasownika: „Add login form”, „Fix navigation bug”, „Update README”.

git log

Wyświetla historię commitów. Przydatny wariant: git log –oneline pokazuje skróconą, czytelną historię. Ctrl+Q lub Q wychodzi z podglądu.

Praca ze zdalnymi repozytoriami

git push origin [branch]

Wysyła lokalne commity do zdalnego repozytorium (na GitHubie). origin to domyślna nazwa zdalnego repozytorium, a main lub master to najczęstsza nazwa głównej gałęzi.

git pull

Pobiera najnowsze zmiany ze zdalnego repozytorium i scala je z twoją lokalną gałęzią. Używaj tego zawsze przed rozpoczęciem nowej pracy, żeby mieć aktualny kod.

git fetch

Pobiera zmiany ze zdalnego repozytorium, ale ich nie scala. Bezpieczniejszy odpowiednik git pull – możesz najpierw sprawdzić, co się zmieniło, a potem zdecydować, co z tym zrobić.

Praca z gałęziami (branches)

git branch

Wyświetla listę wszystkich gałęzi. git branch [nazwa] tworzy nową gałąź. Gałęzie to jedne z najpotężniejszych funkcji Gita – pozwalają pracować nad funkcjonalnością w izolacji od głównego kodu.

git switch [branch] lub git checkout [branch]

Przełącza się na wybraną gałąź. git switch to nowsza, czytelniejsza komenda. git switch -c [nazwa] tworzy nową gałąź i od razu na nią przeskakuje.

git merge [branch]

Scala wybraną gałąź z bieżącą. Gdy skończysz pracę nad nową funkcjonalnością, wracasz do main i robisz git merge feature/twoja-funkcja.

Naprawianie błędów

git diff

Pokazuje dokładnie, co zmieniłeś/-aś w plikach od ostatniego commita. Linie zaczynające się od + to dodania, od – to usunięcia.

git stash

Tymczasowo odkłada niezacommitowane zmiany na bok. Przydatne, gdy musisz pilnie przełączyć się na inną gałąź, ale nie chcesz commitować niedokończonej pracy. git stash pop przywraca odłożone zmiany.

GitHub dla początkujących – jak zacząć?

Zakładanie konta i pierwsze repozytorium

Założenie konta na GitHub.com jest bezpłatne. Po rejestracji możesz od razu tworzyć publiczne i prywatne repozytoria. Aby połączyć lokalne repozytorium z GitHubem:

• Stwórz nowe repozytorium na GitHubie (kliknij „New repository”),
• Skopiuj adres URL repozytorium (HTTPS lub SSH),
• W lokalnym projekcie wpisz: git remote add origin [URL],
• Wypchnij kod: git push -u origin main.

Pull Request – serce współpracy na GitHubie

Pull Request (PR) to propozycja połączenia twoich zmian z główną gałęzią projektu. To kluczowy element pracy w każdym profesjonalnym zespole. Jak wygląda ten proces?

• Tworzysz nową gałąź: git switch -c feature/nowa-funkcja,
• Robisz zmiany, committujesz je i pushujesz na GitHub,
• Na GitHubie klikasz „Compare & pull request”,
• Opisujesz, co zmieniłeś/-aś i dlaczego,
• Zespół robi code review, komentuje, a ty nanosisz poprawki.

Kiedy wszyscy są zadowoleni, PR jest scalany (merged) do głównej gałęzi. To standardowy workflow w praktycznie każdej firmie IT w Polsce.

Git tutorial – typowy workflow w 8 krokach

Teoria jest ważna, ale nic nie zastąpi praktyki. Oto jak wygląda codzienna praca z Gitem i GitHubem w rzeczywistym projekcie:

• Pobierz aktualne zmiany z repozytorium: git pull origin main
• Utwórz nową gałąź dla swojego zadania: git switch -c feature/dodaj-formularz-logowania
• Pracuj nad kodem – edytuj pliki: Otwórz editor (VS Code, WebStorm itp.) i wprowadź zmiany.
• Sprawdź status zmian: git status
• Dodaj zmiany do staging area: git add .
• Zatwierdź zmiany committem: git commit -m „Add login form with email validation”
• Wypchnij gałąź na GitHub: git push origin feature/dodaj-formularz-logowania
• Utwórz Pull Request na GitHubie: Przejdź na github.com, znajdź swoje repozytorium i kliknij „Compare & pull request”.

.gitignore – co to jest i dlaczego to ważne?

Plik .gitignore mówi Gitowi, które pliki i foldery ma ignorować – czyli nie śledzić i nie commitować. To absolutna podstawa każdego projektu. Bez niego możesz przypadkowo wrzucić na GitHuba:

• pliki konfiguracyjne z hasłami i kluczami API (np. .env),
• foldery node_modules z dziesiątkami tysięcy plików,
• pliki tymczasowe i cache’owe generowane przez IDE.

Przykładowy .gitignore dla projektu Node.js:

node_modules/
.env
dist/
.DS_Store

Skorzystaj z generatora gitignore.io – wpisujesz technologię (np. Node, Python, React) i dostajesz gotowy plik. Nie wymyślaj koła na nowo.

Najczęstsze błędy początkujących i jak je naprawić

Commit bezpośrednio do main

W profesjonalnych projektach nikt nie commituje bezpośrednio do głównej gałęzi. Zawsze pracuj na osobnej gałęzi feature branch i łącz przez Pull Request.

Zbyt duże commity

Commit „zrobiłem całą aplikację” to zły commit. Commituj małe, logiczne porcje zmian. Zasada: jeden commit = jedna zmiana logiczna. Dzięki temu historia projektu jest czytelna, a code review możliwy.

Ignorowanie konfliktów merge

Konflikty są normalną częścią pracy z Gitem. Pojawiają się, gdy dwie osoby zmieniły ten sam fragment kodu. Git zaznacza konfliktujące miejsca w pliku – twoim zadaniem jest ręczne rozwiązanie, co zostawić.

Wrzucanie sekretów na GitHuba

To jeden z najpoważniejszych błędów. Klucze API, hasła, tokeny – nigdy nie powinny trafiać do repozytorium. Użyj pliku .env i dodaj go do .gitignore. Pamiętaj: nawet jeśli szybko usuniesz commit, boty skanujące GitHub zdążą wychwycić dane w ciągu sekund.

Dobre praktyki – jak pracować z Gitem profesjonalnie?

• Pisz opisowe commit messages – konwencja Conventional Commits (fix: napraw…, feat: dodaj…, docs: zaktualizuj…) jest standardem w wielu polskich firmach IT.
• Commituj regularnie – nie trzymaj niezacommitowanych zmian przez dni. Traktuj commit jak zapis gry.
• Dbaj o README.md – każde repozytorium na GitHubie powinno mieć dobrze napisany plik README z opisem projektu, instrukcją instalacji i uruchomienia.
• Naucz się git rebase – to alternatywa dla merge, która utrzymuje czystą, liniową historię projektu. Używana często w polskich firmach przy PR-ach.
• GitHub jako portfolio – profil na GitHubie to twoje żywe CV w IT. Rekruterzy i hiring managerowie sprawdzają go podczas rekrutacji. Aktywne repozytoria, regularne commity i projekty własne to ogromny atut.

Narzędzia ułatwiające pracę z Git i GitHub

Terminal to podstawa, ale dla początkujących graficzne interfejsy mogą pomóc zrozumieć, co się dzieje pod spodem:

• GitHub Desktop – oficjalna aplikacja desktopowa GitHuba. Prosta, intuicyjna, idealna na start.
• GitKraken – rozbudowany klient Git z wizualizacją gałęzi. Popularny wśród polskich developerów.
• VS Code + rozszerzenia Git – wbudowana integracja z Gitem i rozszerzenia takie jak GitLens czy Git Graph sprawiają, że nie musisz wychodzić z edytora.
• GitHub CLI (gh) – oficjalne narzędzie wiersza poleceń do zarządzania GitHubem. Możesz tworzyć PR-y, issues i inne operacje bez wychodzenia z terminala.

Podsumowanie – od czego zacząć?

Git i GitHub to umiejętności, które warto opanować jak najwcześniej. Nie musisz znać wszystkich komend od razu – zacznij od podstaw:

• Zainstaluj Git i skonfiguruj (user.name, user.email),
• Załóż konto na GitHubie,
• Zacznij swoje pierwsze repozytorium (git init),
• Naucz się cyklu: add → commit → push,
• Zrób swój pierwszy Pull Request – choćby w fikcyjnym projekcie.

Opanowanie Gita to inwestycja, która zwróci się już od pierwszego dnia pracy w IT. Żadna firma technologiczna w Polsce – od startupu po korporację – nie pracuje bez systemu kontroli wersji.