Git i GitHub - Kontrola Wersji dla Piratów

Każdy programista musi znać Git - system kontroli wersji. To jak dziennik okrętowy - zapisujesz historię zmian w kodzie.

Czym jest Git?

Git to system kontroli wersji - pozwala:

• Zapisywać historię zmian w kodzie
• Cofać się do poprzednich wersji
• Współpracować z innymi programistami
• Branching - pracować nad różnymi funkcjami równocześnie
• Śledzić kto, co i kiedy zmienił

Git vs GitHub:

• Git - narzędzie lokalne (na Twoim komputerze)
• GitHub - platforma online do przechowywania kodu (jak Dropbox dla programistów)

Instalacja Git

Windows:

Pobierz z: https://git-scm.com/install/windows

Podczas instalacji wybierz:

• Git Bash
• Git from the command line
• Use Vim (lub Nano jeśli wolisz)

Mac:

Sprawdź, czy masz już Git:

git --version

Jeśli go nie ma, macOS zaproponuje instalację Xcode Command Line Tools (Git jest w tym pakiecie). Możesz też sam wpisać xcode-select --install albo zainstalować Git przez Homebrew:

brew install git

Linux (Ubuntu/Debian):

sudo apt-get update
sudo apt-get install git

Konfiguracja Git - Pierwsze kroki

Po instalacji skonfiguruj Git z Twoimi danymi:

git config --global user.name "Jack Sparrow"
git config --global user.email "jack@blackpearl.com"

Dlaczego to ważne? Każdy commit (zapis zmian) będzie miał Twoje imię i email - to jak podpis na dzienniku okrętowym.

Sprawdź konfigurację:

git config --list

Inicjalizacja projektu Git

Masz dwa scenariusze:

Scenariusz 1: Nowy projekt (lokalny)

Gdy tworzysz nowy projekt Next.js, Git jest już zainicjalizowany automatycznie!

create-next-app robi to za Ciebie. Sprawdź:

ls -la

Zobaczysz folder .git/ - to Git repository.

Scenariusz 2: Istniejący folder (bez Git)

Jeśli masz folder bez Git:

cd my-project
git init

To stworzy folder .git/ i zainicjalizuje repozytorium.

Podstawowe komendy Git

1. git status - Stan repozytorium

Sprawdza co się zmieniło:

git status

Zobaczysz:

• Untracked files - nowe pliki, które Git nie śledzi
• Modified files - zmienione pliki
• Staged files - pliki gotowe do commit

On branch main
Changes not staged for commit:
  modified:   app/page.tsx

Untracked files:
  app/pirates/page.tsx

2. git add - Dodawanie plików do staging

Staging area to "poczekalnia" przed commitem.

# Dodaj jeden plik
git add app/page.tsx

# Dodaj wszystkie pliki
git add .

# Dodaj wszystkie pliki .tsx, także z podfolderów (cudzysłów: wzorzec rozwija Git, nie terminal)
git add "*.tsx"

Po git add pliki są staged - gotowe do zapisu (commit).

3. git commit - Zapisywanie zmian

Commit to jak punkt kontrolny w grze - zapisujesz stan kodu.

git commit -m "Add pirate landing page"

-m to message (wiadomość) - krótki opis co zmieniłeś.

Dobre commit messages:

• "Add hero section to landing page"
• "Fix button hover animation"
• "Update Pirate interface with level field"

Złe commit messages:

• "changes"
• "fix"
• "asdfghjk"
• "WIP" (Work In Progress - tylko tymczasowo)

4. git log - Historia commitów

Zobacz historię wszystkich commitów:

git log

Zobaczysz:

commit a3f5b8c (HEAD -> main)
Author: Jack Sparrow <jack@blackpearl.com>
Date:   Sun Nov 24 10:30:00 2024 +0100

    Add pirate landing page

commit b2e4a9d
Author: Jack Sparrow <jack@blackpearl.com>
Date:   Sun Nov 24 09:15:00 2024 +0100

    Initial commit

Skróty:

# Krótka wersja (1 linia na commit)
git log --oneline

# Ostatnie 5 commitów
git log -5

# Z grafiką branchy
git log --graph --oneline

5. git diff - Zobacz zmiany

Porównuje aktualne pliki ze staged/committed wersją:

# Zmiany nie dodane do stage
git diff

# Zmiany w staged files
git diff --staged

Zobaczysz:

diff --git a/app/page.tsx b/app/page.tsx
--- a/app/page.tsx
+++ b/app/page.tsx
@@ -1,5 +1,5 @@
 export default function Home() {
   return (
-    <h1>Hello World</h1>
+    <h1>Ahoy, Pirates!</h1>
   )
 }

.gitignore - Ignorowanie plików

Niektóre pliki NIE powinny być w Git:

• node_modules/ - ogromny folder (setki MB)
• .env.local - sekrety (API keys, passwords)
• .next/ - build output
• dist/, build/ - compiled files

Plik .gitignore mówi Git co ignorować:

# .gitignore
node_modules/
.next/
.env.local
.env
.DS_Store
*.log

Next.js automatycznie tworzy .gitignore - masz to już skonfigurowane!

Branching - Gałęzie pracy

Branch (gałąź) to oddzielna linia rozwoju projektu. Możesz pracować nad nową funkcją bez wpływu na główny kod.

Tworzenie brancha

# Stwórz nowy branch
git branch feature/landing-page

# Przełącz się na nowy branch
git checkout feature/landing-page

# Lub jedno polecenie (stwórz + przełącz)
git checkout -b feature/landing-page

Konwencja nazw:

• feature/nazwa - nowa funkcja
• fix/nazwa - poprawka błędu
• refactor/nazwa - refactoring
• docs/nazwa - dokumentacja

Przełączanie między branchami

# Zobacz wszystkie branche
git branch

# Przełącz na main
git checkout main

# Przełącz na feature branch
git checkout feature/landing-page

Mergowanie branchy

Gdy skończysz funkcję, wlewasz zmiany do main:

# Przełącz się na main
git checkout main

# Wlej zmiany z feature brancha
git merge feature/landing-page

Fast-forward merge: Jeśli main się nie zmienił, Git po prostu przesuwa wskaźnik - to najłatwiejszy merge.

3-way merge: Jeśli oba branche mają nowe commity, Git tworzy nowy commit merge.

Usuwanie brancha

Po zmergowaniu możesz usunąć branch:

git branch -d feature/landing-page

GitHub - Zdalne repozytorium

GitHub to jak piracka wyspa - miejsce gdzie przechowujesz skarby (kod).

Tworzenie repozytorium na GitHub

1. Idź na: https://github.com
2. Kliknij zielony przycisk "New" (lub "New repository")
3. Wypełnij:
   • Repository name: krakens-call
   • Description: "Epic pirate game built with Next.js"
   • Public lub Private (wybierz)
   • NIE zaznaczaj "Initialize with README" (masz już lokalny projekt)
4. Kliknij "Create repository"

Łączenie lokalnego projektu z GitHub

GitHub poda Ci komendy - skopiuj je:

# Dodaj zdalne repozytorium
git remote add origin https://github.com/username/krakens-call.git

# Zmień nazwę brancha na main (jeśli trzeba)
git branch -M main

# Wypchnij kod na GitHub
git push -u origin main

Wyjaśnienie:

• origin - nazwa zdalnego repozytorium (domyślna konwencja)
• -u - ustaw upstream (domyślny branch do push/pull)
• main - nazwa brancha

git push - Wysyłanie zmian

Każdy commit lokalnie → wyślij na GitHub:

# Wypchnij wszystkie commity na origin/main
git push

# Wypchnij konkretny branch
git push origin feature/landing-page

git pull - Pobieranie zmian

Jeśli pracujesz w zespole, inni mogą wprowadzać zmiany:

# Pobierz zmiany z GitHub i wlej do lokalnego brancha
git pull

# Pobierz z konkretnego brancha
git pull origin main

pull = fetch + merge:

• git fetch - pobiera zmiany
• git merge - wlewa je do Twojego brancha

git clone - Klonowanie repozytorium

Pobieranie istniejącego projektu z GitHub:

git clone https://github.com/username/krakens-call.git
cd krakens-call
npm install
npm run dev

Workflow z Git i GitHub

Typowy piracki workflow:

1. Nowa funkcja

# Stwórz branch
git checkout -b feature/pirate-profile

# Pracuj nad kodem...
# Edytuj app/profile/page.tsx

# Sprawdź zmiany
git status
git diff

# Dodaj do stage
git add app/profile/

# Commit
git commit -m "Add pirate profile page with stats"

# Wypchnij na GitHub
git push origin feature/pirate-profile

2. Pull Request na GitHub

1. Idź na GitHub
2. Zobaczysz banner: "feature/pirate-profile had recent pushes"
3. Kliknij "Compare & pull request"
4. Wypełnij:
   • Title: "Add pirate profile page"
   • Description: Co zrobiłeś, dlaczego, screenshoty
5. Kliknij "Create pull request"

Pull Request (PR) to prośba o wlanie zmian z Twojego brancha do main. Zespół może zrobić code review.

3. Review i Merge

1. Inni developerzy przeglądają kod
2. Zostawiają komentarze
3. Ty wprowadzasz poprawki (nowe commity na tym samym branchu)
4. Gdy wszystko OK, ktoś klika "Merge pull request"
5. Branch zostaje wlany do main

4. Sync lokalnego main

# Przełącz się na main
git checkout main

# Pobierz zmiany z GitHub
git pull

# Usuń lokalny feature branch
git branch -d feature/pirate-profile

Cofanie zmian - Gdy coś pójdzie nie tak

Cofnij zmiany w pliku (nie committed)

# Przywróć plik do ostatniego commit
git checkout -- app/page.tsx

# Przywróć wszystkie pliki
git checkout -- .

Usuń pliki ze stage (git add)

# Usuń z stage, zostaw zmiany w pliku
git reset app/page.tsx

# Usuń wszystko ze stage
git reset

Cofnij ostatni commit (lokalnie)

# Cofnij commit, zostaw zmiany w plikach
git reset --soft HEAD~1

# Cofnij commit, usuń zmiany w plikach (DANGER!)
git reset --hard HEAD~1

Uwaga: --hard USUWA zmiany bez możliwości odzyskania!

Revert commit (już pushed)

Jeśli commit jest już na GitHub:

# Stwórz nowy commit odwracający zmiany
git revert a3f5b8c

# Push
git push

revert tworzy nowy commit - bezpieczniejsze niż reset.

Git w Cursorze

Cursor ma wbudowaną obsługę Git!

Source Control panel

1. Kliknij ikonę Source Control (po lewej, 3 rozgałęzione kółka)
2. Zobaczysz:
   • Zmienione pliki
   • Przycisk + (git add)
   • Pole do wpisania commit message
   • Przycisk Commit

Workflow w Cursorze:

1. Edytuj pliki
2. Otwórz Source Control (Ctrl + Shift + G, na Macu też Control)
3. Kliknij + przy plikach (stage)
4. Wpisz commit message
5. Kliknij Commit
6. Kliknij "..." → Push

AI Commit Messages: Cursor AI może sugerować commit messages na podstawie zmian!

Używanie AI do Git

Zapytaj Cursor AI:

Prompt 1:

Jak cofnąć ostatni commit w Git?

Prompt 2:

Napisz dobry commit message dla zmian w landing page - dodałem hero section i cta button

Prompt 3:

Jak rozwiązać merge conflict w app/page.tsx?

Git Best Practices

Commituj często - małe, częste commity > rzadkie, duże Dobre commit messages - wyjaśnij CO i DLACZEGO Branch per feature - jedna funkcja = jeden branch Pull before push - zawsze git pull przed git push Nie commituj secrets - .env w .gitignore Code review - używaj Pull Requests Main zawsze działa - nie merge'uj broken code do main

Nie commituj node_modules/ - ogromny, niepotrzebny Nie push --force na main (chyba że absolutnie musisz) Nie commituj WIP bez opisu - opisz co jest w trakcie

Podsumowanie

Git - system kontroli wersji, dziennik okrętowy kodu GitHub - platforma do przechowywania kodu online git init - inicjalizacja repozytorium git add - dodawanie plików do stage git commit - zapisywanie zmian (snapshot) git push - wysyłanie commitów na GitHub git pull - pobieranie zmian z GitHub git branch - tworzenie gałęzi (branch) git merge - wlewanie zmian między branchami Pull Request - prośba o review i merge .gitignore - pliki ignorowane przez Git Cursor Source Control - GUI dla Git w edytorze

Następne kroki: W kolejnych modułach będziemy używać Git do:

• Zapisywania postępów w projekcie
• Tworzenia feature branchy
• Deploymentu na Vercel (Vercel łączy się z GitHub!)

Do zobaczenia!