Przegląd popularnych strategii branżowych i najlepszych praktyk pracy z Git w zespole.
"Kto nadpisał moje zmiany?" "Czemu na produkcji jest stary kod?" "Merge conflict - 47 plików" - brzmi znajomo? Bez ustalonych reguł pracy z Git, zespół 5 programistów potrafi wygenerować więcej chaosu niż startup w pivotcie.
Pracowaliśmy z zespołami, gdzie brak workflow kosztował dni pracy - nadpisane zmiany, zgubione feature'y, hotfixy które nigdy nie trafiły na develop. Oto jak tego uniknąć.
Trzy filozofie: Git Flow vs GitHub Flow vs Trunk-Based
Nie ma "najlepszego" workflow - jest ten dopasowany do Twojego zespołu i cyklu wydań.
Git Flow (Vincent Driessen)
- Gałęzie: main, develop, feature/*, release/*, hotfix/*
- Dla kogo: produkty z zaplanowanymi wersjami (v1.0, v2.0)
- Plusy: czysta historia, łatwe hotfixy, równoległe releasy
- Minusy: skomplikowany dla małych zespołów, długie feature branches
GitHub Flow
- Gałęzie: main + feature branches
- Dla kogo: continuous deployment, SaaS, małe zespoły
- Plusy: prostota, szybkie iteracje, łatwy onboarding
- Minusy: trudniejsze zarządzanie wieloma wersjami
Trunk-Based Development to podejście "elite performers" z raportu DORA - zespoły z najwyższą częstotliwością deployów i najniższym czasem naprawy błędów. Ale wymaga: solidnego CI/CD, testów automatycznych, feature flags i dojrzałej kultury code review.
Jak wdrożyć workflow w zespole?
Wybierz workflow i udokumentuj
Zespół 2-5 osób, CI/CD? GitHub Flow. Zaplanowane releasy, wiele wersji? Git Flow. Spisz decyzję w README lub wiki.
Skonfiguruj branch protection
Zablokuj push do main. Wymuś PR z minimum 1 review. Włącz wymagane sprawdzenia CI przed merge.
Ustal konwencje nazewnictwa
feature/ABC-123-user-login, bugfix/ABC-456-null-pointer, hotfix/v1.2.1-security-patch. Linkuj do ticketów.
Wdróż conventional commits
feat:, fix:, docs:, refactor:, test:, chore: - automatyczne changelogi, semantic versioning.
Retrospektywa workflow
Co miesiąc: czy workflow działa? Czy są bottlenecki? Czy code review nie trwa zbyt długo?
5 praktyk, które zmienią jakość Twojego repo
Atomic commits
Jeden commit = jedna logiczna zmiana. Nie "WIP", nie "fixes", nie "changes". Każdy commit powinien kompilować się i przechodzić testy.
Rebase przed merge
git pull --rebase zamiast git pull. Liniowa historia zamiast "spaghetti graph". Łatwiejszy git bisect, czytelniejszy git log.
Squash przy merge do main
Feature branch może mieć 20 commitów WIP - ale do main wchodzi jeden, czytelny commit z pełnym opisem zmiany.
Pre-commit hooks
Husky + lint-staged: automatyczny linting, formatowanie, sprawdzenie typów PRZED commitem. Zero "fix linting" commitów.
Meaningful PR descriptions
Co zmienia? Dlaczego? Jak testować? Screenshots dla zmian UI. Template PR w repo to must-have.
Komendy Git, które musisz znać
# Interaktywny rebase - uporządkuj commity przed PR
git rebase -i HEAD~5
# Stash z nazwą - nie zgub WIP
git stash push -m "feature X work in progress"
# Cherry-pick - przenieś commit między branchami
git cherry-pick abc123
# Bisect - znajdź commit który wprowadził bug
git bisect start
git bisect bad HEAD
git bisect good v1.0.0
# Reflog - odzyskaj "utracone" commity
git reflog
git checkout HEAD@{2}
Metryki zdrowego repo
Google opublikowało badania: PR powyżej 400 linii mają drastycznie niższą jakość review. Duże PR = surface-level review = bugi na produkcji.
Chaos w repo? Pomożemy uporządkować
Audyt workflow, wdrożenie branch protection, konfiguracja CI/CD, szkolenie zespołu - zbudujemy proces, który działa.