Pierwsze kroki z Git – podstawowe komendy

TL;DR: Git to system kontroli wersji który śledzi zmiany w kodzie. Najważniejsze komendy to: git init (tworzenie repo), git add (dodawanie plików), git commit (zapisywanie zmian) i git push (wysyłanie do serwera). To podstawa pracy każdego programisty.

Dlaczego Git jest kluczowy dla programisty

Wyobraź sobie, że piszesz esej i co jakiś czas zapisujesz kopię: „esej_v1.doc”, „esej_v2.doc”, „esej_final.doc”, „esej_final_naprawde.doc”. Git robi to samo, ale elegancko i automatycznie dla Twojego kodu.

Co się nauczysz:

  • Czym jest Git i dlaczego każdy programista go używa
  • Jak zainstalować i skonfigurować Git na swoim komputerze
  • 5 najważniejszych komend Git które używasz codziennie
  • Jak cofnąć zmiany gdy coś pójdzie nie tak
  • Podstawy pracy z GitHub jako zdalnym repozytorium
Wymagania wstępne: Podstawowa znajomość linii komend (terminal/command prompt). Jeśli nie wiesz jak otwierać terminal, najpierw przeczytaj nasz artykuł o podstawach pracy z terminalem.

Czym jest Git i dlaczego powstał

Git to system kontroli wersji – narzędzie które śledzi zmiany w plikach w czasie. Został stworzony przez Linusa Torvaldsa (tego od Linuxa) w 2005 roku, bo istniejące narzędzia nie nadążały za potrzebami dużych projektów programistycznych.

Analogia: Git to jak biblioteka z historią wszystkich wersji Twojego kodu. Możesz „wypożyczyć” starą wersję, zobaczyć co się zmieniło, a nawet stworzyć alternatywną historię (branch) gdzie testujesz nowe pomysły.

Instalacja i pierwsza konfiguracja Git

Instalacja na różnych systemach

Windows:
Pobierz z git-scm.com i zainstaluj z domyślnymi ustawieniami. To da Ci Git Bash – terminal który „rozumie” komendy Unix.

macOS:

# Używając Homebrew (polecane)
brew install git

# Lub pobierz z git-scm.com

Ubuntu/Debian:

sudo apt update
sudo apt install git

Pierwsza konfiguracja

Po instalacji musisz „przedstawić się” Git-owi:

# Ustaw swoje imię i nazwisko
git config --global user.name "Jan Kowalski"

# Ustaw swój email (ważne: użyj tego samego co na GitHub)
git config --global user.email "jan.kowalski@example.com"

# Sprawdź czy się zapisało
git config --list
Flaga –global oznacza że te ustawienia będą używane we wszystkich Twoich projektach. Możesz je później zmienić dla konkretnego projektu pomijając –global.

Podstawowe koncepcje – repozytorium, commit, branch

Repozytorium (Repository)

Repozytorium – folder z Twoim projektem który Git „pilnuje”. Zawiera wszystkie pliki + ukryty folder .git z historią zmian.

Commit

Commit – „zdjęcie” Twojego kodu w konkretnym momencie. Każdy commit ma unikalny ID, opis zmian i informację kto/kiedy go stworzył.

Branch (gałąź)

Branch – równoległa „linia rozwoju” kodu. Domyślny branch to master. Możesz stworzyć nowy branch żeby eksperymentować bez wpływu na główny kod.

5 najważniejszych komend Git

1. git init – tworzenie nowego repozytorium

# Stwórz nowy folder dla projektu
mkdir moj-pierwszy-projekt
cd moj-pierwszy-projekt

# Zainicjuj Git w tym folderze
git init

# Sprawdź status
git status

Po git init pojawi się ukryty folder .git – to „mózg” Twojego repozytorium.

2. git add – dodawanie plików do staging area

# Stwórz plik
echo "console.log('Hello World!');" > app.js

# Dodaj jeden plik
git add app.js

# Lub dodaj wszystkie zmienione pliki
git add .

# Sprawdź co jest w staging area
git status
Staging area to jak „koszyk w sklepie” – dodajesz rzeczy które chcesz „kupić” (commitować), ale jeszcze nie płacisz (nie robisz commit).

3. git commit – zapisywanie zmian

# Commit z opisem w jednej linii
git commit -m "Dodaj pierwszą wersję app.js"

# Sprawdź historię commitów
git log --oneline
Pro tip: Dobre opisy commitów to sztuka! Zamiast „poprawki” napisz „Napraw walidację emaila w formularzu rejestracji”. Twoje przyszłe ja będzie wdzięczne.

4. git status – sprawdzanie stanu repozytorium

# Sprawdź co się dzieje w repozytorium
git status

# Krótka wersja
git status -s

To najczęściej używana komenda – pokazuje które pliki są zmienione, które w staging area, a które niesledzą.

5. git log – przeglądanie historii

# Pełna historia
git log

# Skrócona (polecana na co dzień)
git log --oneline

# Historia z grafiką (dla branch'y)
git log --oneline --graph

# Historia z datami i autorami
git log --pretty=format:"%h %an %ad %s" --date=short

Cofanie zmian – gdy coś pójdzie nie tak

Cofanie zmian które nie są jeszcze w commit

# Cofnij zmiany w konkretnym pliku
git checkout -- app.js

# Usuń plik ze staging area (ale zostaw zmiany w pliku)
git reset app.js

# Cofnij wszystkie zmiany do ostatniego commit
git reset --hard HEAD
Uwaga: git reset –hard NIEODWRACALNIE usuwa wszystkie niezapisane zmiany. Używaj ostrożnie!

Cofanie commit’a

# Cofnij ostatni commit (ale zostaw zmiany w plikach)
git reset --soft HEAD~1

# Cofnij ostatni commit i usuń zmiany
git reset --hard HEAD~1

# Stwórz nowy commit który odwraca poprzedni (bezpieczniejsze)
git revert HEAD

Podstawy pracy z GitHub

Łączenie lokalnego repo z GitHub

1. Stwórz nowe repozytorium na GitHub.com
2. Skopiuj URL z GitHub (np. https://github.com/twoja-nazwa/moj-projekt.git)
3. Połącz lokalne repo z GitHub:

# Dodaj remote (zdalne repo)
git remote add origin https://github.com/twoja-nazwa/moj-projekt.git

# Wyślij kod na GitHub
git push -u origin master

# Przy kolejnych push wystarczy
git push

Pobieranie kodu z GitHub

# Sklonuj istniejące repo
git clone https://github.com/ktos/jakis-projekt.git

# Pobierz najnowsze zmiany
git pull

Typowe błędy początkujących

Błąd 1: Robienie commit bez sprawdzenia git status. Skutek: commitowanie plików których nie chciałeś.

Rozwiązanie: Zawsze rób git status przed git add.
Błąd 2: Opisy commit’ów typu „zmiany”, „poprawki”, „a”.

Rozwiązanie: Pisz co robiłeś: „Dodaj walidację formularza”, „Napraw błąd w kalkulacji VAT”.
Błąd 3: Commitowanie hasełł, kluczy API, plików konfiguracyjnych.

Rozwiązanie: Używaj pliku .gitignore i zmiennych środowiskowych.
Błąd 4: Panika przy „nieclean working directory”.

Rozwiązanie: git status i git stash to Twoi przyjaciele.

Plik .gitignore – co nie powinno być w repo

Stwórz plik .gitignore w głównym folderze projektu:

# Pliki IDE
.idea/
*.iml
.vscode/

# Pliki systemu
.DS_Store
Thumbs.db

# Pliki buildu
*.class
target/
build/
node_modules/

# Pliki konfiguracyjne z hasłami
*.env
config.properties
database.config

# Logi
*.log
logs/
Pro tip: GitHub ma gotowe szablony .gitignore dla różnych języków. Przy tworzeniu repo zaznacz „Add .gitignore” i wybierz swój język.

Workflow na co dzień

Typowy dzień programisty z Git:

# Rano - pobierz najnowsze zmiany
git pull

# Sprawdź na czym pracujesz
git status

# Pracuj nad kodem...
# (edytujesz pliki w IDE)

# Co jakiś czas sprawdzaj co zmieniłeś
git status
git diff

# Gdy skończysz kawałek funkcjonalności
git add .
git commit -m "Dodaj funkcję eksportu danych do CSV"

# Na koniec dnia wyślij zmiany
git push
Co oznacza „origin” w git push origin master?

Origin to domyślna nazwa dla zdalnego repozytorium (np. na GitHub). Master to nazwa branch’a. Komenda oznacza „wyślij branch master do zdalnego repo o nazwie origin”.

Czy mogę usunąć folder .git?

Tak, ale STRACISZ CAŁĄ HISTORIĘ projektu. Folder .git zawiera wszystkie informacje o commitach, branch’ach i remote repo. Po usunięciu zostanie Ci zwykły folder z plikami.

Jak zmienić opis ostatniego commita?

Użyj git commit –amend -m „Nowy opis”. UWAGA: to zmienia historię, więc rób to tylko z commitami które jeszcze nie są na serwerze.

Co to jest „detached HEAD state”?

To oznacza że „patrzysz” na konkretny commit, nie na branch. Zwykle po git checkout [commit-hash]. Wróć do normalnego stanu przez git checkout master.

Dlaczego git add przed git commit?

Git ma trzystopniowy workflow: Working Directory (twoje pliki) → Staging Area (git add) → Repository (git commit). Możesz wybrać KTÓRE zmiany chcesz commitować, nie wszystkie na raz.

Jak zobaczyć różnice między plikami?

git diff pokazuje co zmieniłeś w plikach. git diff –staged pokazuje różnice w staging area. git diff HEAD~1 porównuje z poprzednim commitem.

Co zrobić gdy git push nie działa?

Najpierw git pull żeby pobrać najnowsze zmiany z serwera. Jeśli są konflikty, rozwiąż je i zrób nowy commit. Potem git push powinno działać.

Przydatne zasoby:

🚀 Zadanie dla Ciebie

Stwórz swoje pierwsze repozytorium:

  1. Stwórz folder „moj-pierwszy-git-projekt”
  2. Zainicjuj Git w tym folderze
  3. Stwórz plik README.md z opisem projektu
  4. Dodaj, commituj i wyślij na GitHub
  5. Edytuj README.md, zrób drugi commit
  6. Sprawdź historię komendą git log –oneline

Bonus: Stwórz plik .gitignore i dodaj do niego kilka typowych plików do ignorowania.

Czy masz już swoje pierwsze repo na GitHub? Podziel się linkiem w komentarzach – będziemy Cię dopingować! 🚀

Zostaw komentarz

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *

Przewijanie do góry