Git i GitHub od zera: git tutorial dla początkujących

• Git odpowiada za historię projektu na komputerze.
• GitHub przechowuje repozytoria i umożliwia omawianie zmian.
• Podstawowy rytm pracy to: edycja, sprawdzenie, przygotowanie, commit i wysłanie.
• Polecam zaczynać od osobnego projektu ćwiczeniowego i przechowywać sekrety poza historią Git.

Scalenie, czyli merge, włącza zmiany z jednej gałęzi do drugiej. GitHub opisuje te pojęcia w swoim słowniku repozytoriów.

Przed commitem zmiany przechodzą przez staging area, czyli obszar przygotowania, nazywany też indeksem. Edytujesz pliki w katalogu roboczym, wybierasz ich wersje do następnego zapisu, a potem tworzysz commit. Tak działa podstawowy proces pracy w Git.

Poniższy schemat pokazuje lokalny zapis oraz późniejsze wysłanie zmian, opisane w dokumentacji git push:

flowchart TD
    A[Edytujesz pliki] --> B[Sprawdzasz zmiany]
    B --> C[Przygotowujesz zapis]
    C --> D[Tworzysz commit lokalnie]
    D --> E[Wysyłasz na GitHub]

Ścieżka instalacji poniżej dotyczy Ubuntu Desktop 24.04 LTS. Przygotuj terminal, czyli okno do wpisywania poleceń, edytor tekstu, przeglądarkę oraz dostęp do internetu. Do instalacji potrzebujesz możliwości użycia sudo, czyli wykonania polecenia z uprawnieniami administratora.

Do części z GitHub przygotuj konto z potwierdzonym adresem e-mail. Jeśli już je masz, wykorzystaj istniejące.

Polecam ćwiczyć na dwóch krótkich plikach. Dzięki temu łatwiej zobaczysz, co zostało zapisane, zamiast analizować od razu setki plików wygenerowanej aplikacji.

1. Zainstaluj Git i GitHub CLI

Otwórz terminal. Zainstaluj Git zgodnie ze ścieżką instalacji dla Ubuntu:

sudo apt-get update
sudo apt-get install git

git --version

sudo: unable to send audit message: Operation not permitted
Hit:1 http://security.ubuntu.com/ubuntu noble-security InRelease
Hit:2 https://cli.github.com/packages stable InRelease
Hit:3 https://packages.microsoft.com/repos/code stable InRelease
Hit:4 https://deb.nodesource.com/node_24.x nodistro InRelease
Hit:5 http://archive.ubuntu.com/ubuntu noble InRelease
Hit:6 http://archive.ubuntu.com/ubuntu noble-updates InRelease
Hit:7 http://archive.ubuntu.com/ubuntu noble-backports InRelease
Reading package lists...
sudo: unable to send audit message: Operation not permitted
…
git version 2.43.0

Oczekiwany wynik ostatniego polecenia to nazwa Git oraz numer zainstalowanej wersji. Nie porównuj numeru z przypadkowym zrzutem ekranu w internecie.

GitHub CLI to narzędzie do obsługi GitHub z terminala; uruchamia się je poleceniem gh. Zainstaluj je z oficjalnego źródła pakietów. Poniższy blok dodaje źródło pakietów do konfiguracji systemu i instaluje narzędzie:

(type -p wget >/dev/null || (sudo apt update && sudo apt install wget -y)) \
  && sudo mkdir -p -m 755 /etc/apt/keyrings \
  && gh_key_file=$(mktemp) \
  && wget -nv -O "$gh_key_file" https://cli.github.com/packages/githubcli-archive-keyring.gpg \
  && cat "$gh_key_file" | sudo tee /etc/apt/keyrings/githubcli-archive-keyring.gpg > /dev/null \
  && sudo chmod go+r /etc/apt/keyrings/githubcli-archive-keyring.gpg \
  && sudo mkdir -p -m 755 /etc/apt/sources.list.d \
  && echo "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/githubcli-archive-keyring.gpg] https://cli.github.com/packages stable main" | sudo tee /etc/apt/sources.list.d/github-cli.list > /dev/null \
  && sudo apt update \
  && sudo apt install gh -y

sudo: unable to send audit message: Operation not permitted
2026-10-06 20:07:27 URL:https://cli.github.com/packages/githubcli-archive-keyring.gpg [4528/4528] -> "/tmp/tmp.zhCCwNTtb4" [1]
sudo: unable to send audit message: Operation not permitted
sudo: unable to send audit message: Operation not permitted
sudo: unable to send audit message: Operation not permitted
sudo: unable to send audit message: Operation not permitted
sudo: unable to send audit message: Operation not permitted

WARNING: apt does not have a stable CLI interface. Use with caution in scripts.

…
0 upgraded, 0 newly installed, 0 to remove and 2 not upgraded.

Poczekaj na zakończenie instalacji. Jeśli pojawi się błąd, zatrzymaj się na tym etapie zamiast wykonywać dalsze polecenia.

2. Utwórz repozytorium i ustaw autora

W terminalu przejdź do miejsca, w którym chcesz przechowywać projekty. Wybierz lokalizację, w której nie istnieje jeszcze folder git-start:

mkdir git-start
cd git-start
git init -b main

Initialized empty Git repository in ~/git-start/.git/

git init tworzy repozytorium, a -b main nadaje początkowej gałęzi nazwę main. Powstaje katalog .git z danymi repozytorium. Od teraz wykonuj polecenia w folderze git-start, chyba że instrukcja wyraźnie każe z niego wyjść.

Ustaw nazwę autora oraz adres e-mail. Konfiguracja --global dotyczy wszystkich repozytoriów twojego użytkownika na tym komputerze.

Polecam użyć adresu noreply udostępnianego przez GitHub, aby zachować prywatność osobistego e-maila. Znajdziesz ustawienia pod zdjęciem profilu, następnie Settings i Emails. Dokumentacja wyjaśnia ustawianie adresu używanego w commitach.

Zastąp oba przykładowe teksty własnymi danymi przed wykonaniem poleceń:

git config --global user.name "Twoja nazwa autora"
git config --global user.email "TWOJ_ADRES_NOREPLY"
git config --global user.name
git config --global user.email

Ostatnie polecenia powinny wypisać ustawione wartości. Ta konfiguracja opisuje autora zmian; logowanie do GitHub wykonasz osobno.

3. Przygotuj pliki i zasady ignorowania

Najpierw wykonaj kroki 1–2: musisz mieć zainstalowany Git, utworzone repozytorium i ustawione dane autora. Poniższe bloki uruchom w terminalu, pozostając w folderze git-start. Polecenie cat odczytuje podany tekst, a przekierowanie > zapisuje go do pliku; jeśli plik już istnieje, jego dotychczasowa zawartość zostanie nadpisana.

W terminalu utwórz plik README.md:

cat > README.md <<'EOF'
Moja nauka Gita

To projekt ćwiczeniowy do nauki zapisywania zmian.
EOF

README potraktuj jako krótkie wprowadzenie dla osoby, która pierwszy raz otwiera projekt. Rozszerzenie .md oznacza Markdown, czyli format tekstowy pozwalający zapisywać między innymi nagłówki i listy.

W tym samym folderze utwórz również plik .gitignore:

cat > .gitignore <<'EOF'
.env
.env.*
*.log
EOF

Plik .gitignore zawiera wzorce nazw, które Git ma ignorować wśród plików jeszcze nieśledzonych, czyli takich, których nie było w ostatnim commicie i których nie dodano do obszaru przygotowania. Po dodaniu nowego pliku poleceniem git add Git zaczyna go śledzić. W naszym przykładzie są to .env, nazwy zaczynające się od .env. oraz pliki z końcówką .log. Reguły ignorowania nie wpływają na pliki już śledzone.

4. Sprawdź pliki i wykonaj pierwszy commit

Sprawdź stan projektu:

git status

On branch main

No commits yet

Untracked files:
  (use "git add <file>..." to include in what will be committed)
	.gitignore
	README.md

nothing added to commit but untracked files present (use "git add" to track)

git status pokazuje pliki nieśledzone oraz zmiany przygotowane i nieprzygotowane do commita. W tym przykładzie powinny pojawić się README.md i .gitignore jako nowe pliki.

Przed wykonaniem git add musisz mieć oba pliki zapisane bezpośrednio w bieżącym folderze git-start. Jeśli któregoś brakuje, wróć do kroku 3 i utwórz go przed dalszą pracą.

Przygotuj je do zapisu:

git add README.md .gitignore

Polecenie git add wybiera aktualną zawartość wskazanych plików. Jeśli po jego wykonaniu ponownie zmienisz plik, uruchom git add jeszcze raz, aby przygotować także nową zmianę. Wyjaśnia to rozdział o zapisywaniu zmian w repozytorium.

Obejrzyj przygotowaną zawartość:

git diff --staged

diff --git a/.gitignore b/.gitignore
new file mode 100644
index 0000000..62854d9
--- /dev/null
+++ b/.gitignore
@@ -0,0 +1,3 @@
+.env
+.env.*
+*.log
diff --git a/README.md b/README.md
…
+To projekt ćwiczeniowy do nauki zapisywania zmian.

git diff --staged pokazuje zmiany przeznaczone do następnego commita. Sprawdź, czy widzisz wyłącznie treść swoich dwóch plików. Następnie zapisz je:

git commit -m "Dodaj opis projektu i reguły ignorowania"
git status

[main (root-commit) 67dcab3] Dodaj opis projektu i reguły ignorowania
 2 files changed, 6 insertions(+)
 create mode 100644 .gitignore
 create mode 100644 README.md
On branch main
nothing to commit, working tree clean

git commit zapisuje przygotowaną zawartość, a -m podaje opis zapisu. Po poprawnym wykonaniu zobaczysz podsumowanie commita. Status powinien wskazywać brak zmian do zapisania, w angielskim interfejsie: nothing to commit, working tree clean.

Polecam opisywać cel zmiany, na przykład „Dodaj instrukcję uruchomienia”. Komunikat „zmiany” niewiele pomoże, kiedy wrócisz do projektu po przerwie.

5. Zaloguj się i wyślij projekt na GitHub

Uruchom logowanie przez przeglądarkę:

gh auth login --hostname github.com --git-protocol https --web

Postępuj według komunikatów terminala: otwórz wskazaną stronę, wpisz pokazany kod i zatwierdź dostęp na właściwym koncie. HTTPS to wybrany tutaj sposób komunikacji z GitHub.

Następnie skonfiguruj Git, aby korzystał z obsługi poświadczeń przez GitHub CLI:

gh auth setup-git --hostname github.com

Poświadczenia to dane potwierdzające twoje uprawnienia. GitHub CLI próbuje przechowywać token dostępu, czyli poufny klucz używany do potwierdzania tożsamości w GitHub, w systemowym magazynie poświadczeń; jeśli nie może z niego skorzystać, może zapisać token w zwykłym pliku. Dlatego polecam traktować konfigurację logowania jako prywatną i nie dołączać jej do projektu.

Utwórz repozytorium o nazwie, której jeszcze nie używasz na koncie:

gh repo create git-start --private --source=. --remote=origin --push

Zgodnie z dokumentacją tworzenia repozytorium, --private wybiera repozytorium prywatne, --source=. wskazuje bieżący folder, --remote=origin nadaje nazwę połączeniu zdalnemu, a --push wysyła lokalne commity. Po sukcesie otwórz wypisany adres projektu i sprawdź oba pliki.

Repozytorium publiczne jest dostępne dla wszystkich w internecie. Dostęp do prywatnego jest ograniczony według zasad widoczności GitHub. Polecam pozostać przy prywatnym podczas pierwszych ćwiczeń.

6. Zmień opis na osobnej gałęzi

Gałąź nazwij według zadania, które wykonujesz. Utwórz ją i przełącz się na nią:

git switch -c rozbudowa-opisu

Switched to a new branch 'rozbudowa-opisu'

git switch -c tworzy gałąź i od razu ją wybiera. Oczekiwany wynik to komunikat o przełączeniu na nową gałąź.

Zastąp zawartość pliku README.md:

Moja nauka Gita

To projekt ćwiczeniowy do nauki zapisywania zmian.

Cel projektu: przećwiczyć commit, gałąź i pull request.

Sprawdź różnicę, przygotuj zmianę i zapisz ją:

git diff
git add README.md
git diff --staged
git commit -m "Dopisz cel projektu"
git push -u origin rozbudowa-opisu

Zwykły git diff pokazuje zmiany jeszcze nieprzygotowane, a wariant --staged pokazuje przygotowane. git push -u wysyła gałąź i ustawia powiązanie z jej odpowiednikiem zdalnym. Oczekiwany wynik to informacja o wysłaniu nowej gałęzi.

7. Utwórz pull request i scal zmiany

Pull request pozwala przedstawić zmianę do sprawdzenia przed scaleniem. W swoim projekcie możesz przećwiczyć zarówno rolę autora, jak i osoby oceniającej propozycję.

Utwórz pull request z określoną gałęzią docelową:

gh pr create --base main --head rozbudowa-opisu --title "Rozbuduj opis projektu" --body "Dodaję cel ćwiczenia do README. Sprawdziłem treść zmiany."

--base main wskazuje gałąź docelową, a --head gałąź zawierającą zmianę. Terminal powinien wypisać adres utworzonej propozycji.

Obejrzyj różnice w pull requeście:

gh pr diff

Polecam ocenić trzy rzeczy: czy zmiana realizuje opisany cel, czy dotyczy wyłącznie potrzebnych plików i czy nie zawiera prywatnych danych. Jeżeli potrzebujesz poprawki, wykonaj kolejny commit na tej gałęzi i wyślij go. GitHub aktualizuje istniejący pull request po kolejnych wysłanych zmianach.

Gdy akceptujesz wynik, wykonaj scalenie pull requesta:

gh pr merge --merge

To polecenie zmienia gałąź docelową na GitHub, włączając do niej zaakceptowane zmiany. Po pomyślnym scaleniu zaktualizuj lokalny projekt:

git switch main
git pull --ff-only origin main

--ff-only pozwala zaktualizować gałąź, jeśli lokalna historia nie rozeszła się ze zdalną. W naszym przykładzie README.md na lokalnej gałęzi main powinien już zawierać cel ćwiczenia.

Jeżeli projekt ma już repozytorium, zacznij od klonowania, czyli pobrania jego lokalnej kopii z historią. git clone pozwala także wskazać nazwę nowego katalogu.

1. Zastąp TWOJ_LOGIN nazwą swojego konta.
2. Z folderu git-start przejdź poziom wyżej.
3. Pobierz kopię do nowego folderu i sprawdź status:

cd ..
git clone https://github.com/TWOJ_LOGIN/git-start.git git-start-kopia
cd git-start-kopia
git status

Oczekiwany wynik to folder z plikami projektu i działającym repozytorium. Polecam teraz spróbować dopisać własne zdanie do README, przygotować je i zapisać, korzystając z poznanego rytmu pracy.

Poniższe sytuacje są osobnymi przykładami. Wybierz rozwiązanie pasujące do problemu.

Plik został przygotowany za wcześnie

Po istniejącym commicie możesz wycofać plik z obszaru przygotowania:

git restore --staged README.md

git restore --staged przywraca stan indeksu z ostatniego commita. Edycje w pliku roboczym pozostają. Oczekiwany wynik w statusie to zmiana nieprzygotowana do zapisu.

Chcesz odrzucić lokalną edycję

Jeśli świadomie chcesz zastąpić zawartość pliku wersją z obszaru przygotowania:

git restore README.md

To polecenie nadpisuje lokalne edycje wskazanego pliku. Polecam najpierw zachować kopię, jeśli możesz jeszcze potrzebować treści. Bez opcji --staged źródłem przywracania jest domyślnie indeks, zgodnie z dokumentacją przywracania plików.

Błąd jest już zapisany w commicie

Polecam rozważyć git revert, który zapisuje nowy commit odwracający wcześniejszą zmianę. Wymaga czystego katalogu roboczego.

Zanim skorzystasz z tego przykładu, wykonaj kroki 1–4: potrzebujesz zainstalowanego Git, repozytorium z zapisanym commitem oraz ustawionej nazwy autora i adresu e-mail. Wykonuj poniższe czynności w katalogu tego repozytorium.

1. Sprawdź git status.
2. Wyświetl historię poleceniem git log --oneline.
3. Skopiuj poniższy wzór, zastąp ID_COMMITU rzeczywistym identyfikatorem zwykłego commita z wyświetlonej historii i dopiero wtedy uruchom polecenie. Nie uruchamiaj wzoru z dosłownym tekstem ID_COMMITU:

git revert --no-edit ID_COMMITU

git log --oneline pokazuje skrócone identyfikatory i tytuły zapisów. Wybierz konkretną zmianę, a nie commit scalenia, który wymaga dodatkowego wskazania sposobu odwracania.

Git prosi o dane autora

Wróć do konfiguracji user.name i user.email, sprawdź wartości i ponów commit. Polecam ustawiać autora przed rozpoczęciem ćwiczenia, aby nie przerywać pierwszego zapisu.

Logowanie lub wysłanie zmian nie działa

Sprawdź stan konta:

gh auth status

gh auth status sprawdza uwierzytelnienie i pokazuje aktywne konto. Polecam upewnić się, że jest to konto właściciela projektu, a następnie w razie potrzeby powtórzyć logowanie z kroku 5.

Wysłanie zmian zostało odrzucone

Odrzucenie typu non-fast-forward może oznaczać, że zdalna gałąź zawiera historię, której lokalnie brakuje. Git domyślnie chroni przed takim nadpisaniem historii.

Polecam najpierw zapisać lokalne zmiany i sprawdzić właściwą gałąź. Jeśli pracujesz na main, możesz pobrać i scalić zdalne zmiany:

git pull --no-rebase --no-edit origin main

Ten wariant git pull wybiera scalenie i przyjmuje domyślny komunikat udanego scalenia. Jeśli wystąpi konflikt, rozwiąż go przed ponownym wysłaniem.

Pojawił się konflikt scalenia

Konflikt może wystąpić przy konkurencyjnych zmianach tych samych linii. Dla konfliktu w treści pliku dokumentacja GitHub wskazuje następujący proces:

1. W katalogu repozytorium wykonaj git status.

2. Otwórz wskazany plik i znajdź znaczniki <<<<<<<, ======= oraz >>>>>>>.

3. Wybierz docelową treść i usuń znaczniki.

4. Zapisz poprawiony plik i przygotuj go poleceniem git add z jego nazwą, a następnie wykonaj commit. Dla konfliktu w README.md uruchom w katalogu repozytorium:

   terminalKopiuj

   git add README.md
   git commit -m "Rozwiąż konflikt scalenia"
   git status
   

Jeśli konflikt dotyczy innego pliku, zastąp README.md jego ścieżką. Jeśli konfliktów jest kilka, przygotuj każdy poprawiony plik przed commitem. Po rozwiązaniu wszystkich konfliktów i poprawnym commicie scalenie jest zakończone. Jeśli nie ma innych zmian ani plików nieśledzonych, git status powinien pokazać nothing to commit, working tree clean.

Polecam sprawdzić wynik w edytorze przed zapisaniem rozwiązania.

Sekret trafił do historii

Jeśli zapiszesz hasło lub token dostępu, najpierw go unieważnij albo wymień. Samo usunięcie pliku z bieżącej wersji nie rozwiązuje problemu wcześniejszego zapisu. GitHub opisuje postępowanie po ujawnieniu danych wrażliwych, w tym skutki przepisywania historii.

Czy Git i GitHub to to samo?

Nie. Git zapisuje historię projektu, a GitHub udostępnia miejsce do przechowywania repozytoriów i współpracy. W przykładzie używasz obu narzędzi, ale odpowiadają za różne etapy pracy.

Czy do używania Git potrzebuję konta GitHub?

Do lokalnej pracy konta nie potrzebujesz. Możesz tworzyć commity i przeglądać historię bez połączenia z serwerem, co wyjaśnia opis lokalnych operacji Git.

Czym różni się commit od push?

Commit zapisuje przygotowany stan w lokalnym repozytorium. Push wysyła potrzebne dane i aktualizuje wskazaną gałąź zdalną. Jeśli po commicie projekt na GitHub wygląda tak samo, sprawdź, czy wykonałeś wysłanie zmian.

Czym różni się clone od fork?

Clone pobiera lokalną kopię repozytorium. Fork tworzy nowe repozytorium powiązane z pierwotnym; tak rozróżnia je dokumentacja repozytoriów GitHub. Polecam najpierw przećwiczyć klonowanie własnego projektu.

Przećwicz cały cykl jeszcze raz z własną zmianą.