Przejdź do głównej zawartości

20. Git workflow zespołowy

Git workflow zespołowy

Git to system kontroli wersji — historia kodu, praca równoległa, przywracanie zmian. W zespole kluczowe jest: strategia gałęzi (branch), Pull Requests do code review, konwencja commitów. To nie jest teoria — to codzienne narzędzie w każdej firmie softwarowej.

  1. Dlaczego branch? — Izolacja feature od main — main zawsze działa, gałąź można zepsuć
  2. Co to jest Pull Request? — Propozycja zmian + code review przed merge do main
  3. Conventional Commits? — Konwencja: feat: add login, fix: null pointer, chore: update deps
  4. Jak rozwiązać konflikt? — Dwie osoby edytują ten sam plik — Git nie wie co zostawić
  1. Git podstawy — commit, branch, merge, rebase
  2. Feature branch workflowmain zawsze stabilny, feature na gałęzi
  3. Pull Request + code review — recenzja kodu, komentarze, approve
  4. Conventional Commits — format, typy: feat/fix/chore/docs
  5. Konflikty — jak powstają, jak rozwiązywać

Schemat

Git graph: main branch + dwie feature branches (feat/login, feat/cart) z commitami, merge back do main z Pull Request. Pokaż jak wyglądałby konflikt (dwie gałęzie edytują ten sam plik).

Przykład kodu

Terminal: sekwencja komend git dla typowego feature workflow: checkout -b, add, commit, push, PR na GitHub.

  • Feature branch workflow
  • commit, push, Pull Request
  • Conventional commits

Forma: 10 slajdów, 10 minut

Ocena: 3.0
Okno terminala
# 1. Pobierz najnowszy main
git checkout main
git pull origin main
# 2. Utwórz gałąź dla nowej funkcji
git checkout -b feat/user-login
# 3. Pracuj, commituj regularnie
git add src/components/LoginForm.jsx
git commit -m "feat: add login form with email/password fields"
git add src/hooks/useAuth.js
git commit -m "feat: add useAuth hook for authentication state"
# 4. Wypchnij gałąź na GitHub
git push origin feat/user-login
# 5. Utwórz Pull Request na GitHub
# Opis: co zostało zrobione, jak testować, screenshots
# 6. Po code review i approve — merge do main (przez GitHub UI)
# 7. Usuń gałąź po merge
git branch -d feat/user-login
Okno terminala
# Format: <type>(<scope>): <description>
# [optional body]
# [optional footer]
# Nowa funkcja
git commit -m "feat(auth): add Google OAuth login"
# Naprawa buga
git commit -m "fix(cart): fix total price calculation with discounts"
# Dokumentacja
git commit -m "docs: update README with setup instructions"
# Zmiany konfiguracji
git commit -m "chore(deps): update react to v18.3"
# Refaktor (bez zmiany zachowania)
git commit -m "refactor(auth): extract token validation to utility"
Okno terminala
# Sytuacja: ty i kolega zmieniliście ten sam plik
git merge feat/colleague-branch
# Git pokazuje CONFLICT w pliku:
# <<<<<<< HEAD (twoje zmiany)
# const API_URL = 'https://api.myapp.com';
# =======
# const API_URL = 'https://api.myapp.dev';
# >>>>>>> feat/colleague-branch
# Rozwiąż ręcznie (zostaw właściwą wersję, usuń znaczniki):
# const API_URL = process.env.VITE_API_URL; // Lepsza opcja - zmienna środowiskowa
git add src/config/api.js
git commit -m "fix: resolve merge conflict in api config"

Pokaż GitHub na żywo

Wejdźcie na repozytorium projektu semestralnego i pokażcie Pull Requests, historię commitów, diff. Klasa widzi realne narzędzie, nie teorię.

Demonstracja konfliktu

Stwórzcie na żywo dwie gałęzie, edytujcie ten sam plik i spróbujcie zmergować. Pokażcie jak Git informuje o konflikcie. To najbardziej pamiętalna część prezentacji!

Wartość code review

Podajcie przykład z historii: bug na produkcji który code review by wykrył. NASA, Facebook — znane incydenty spowodowane brakiem review.

Pytanie na Q&A

“Kiedy squash, kiedy merge, kiedy rebase?” — To zaawansowane pytanie — przygotujcie się na skrótową odpowiedź.

Git to nie opcja — to standard!

Każda firma softwarowa używa Git. Każda! Opanowanie workflow zespołowego wyróżni Was w trakcie stażu i pierwszej pracy!