Wybór workflow gitowego ma większy wpływ na produktywność zespołu niż większość decyzji technicznych. Git Flow, GitHub Flow, trunk-based development – to kompletne modele pracy, code review i deploymentu. Pokażę kiedy co stosować i co odróżnia dobry pull request od złego.
Git Flow
Git Flow definiuje kilka typów branchów: main (produkcja), develop (integracja), feature/xxx, release/x.y, hotfix/xxx. Sprawdza się przy oprogramowaniu z numerowanymi wersjami.
git flow init git flow feature start order-export git flow feature finish order-export git flow release start 1.2.0 git flow release finish 1.2.0 git flow hotfix start critical-tax-bug git flow hotfix finish critical-tax-bug
Trunk-Based Development
Jeden główny branch, krótkie feature branche (max kilka dni), CI/CD przy każdym pushu, deploy po merge do main. Wymaga feature flags do ukrywania niegotowych funkcji.
git checkout -b feature/add-loyalty-points git push -u origin feature/add-loyalty-points # Otwórz Pull Request, code review, CI przechodzi # Squash and merge do main, automatyczny deployment
Pull Request – struktura
## Co zrobilem Dodaem eksport zamowien do CSV. Refs: #247 ## Jak testowac 1. Admin > Sales > Orders 2. Zaznacz zamowienia, Export > CSV ## Checklist - [x] Testy przechodza - [x] phpstan --level=8 bez bledow - [x] Breaking changes: brak
Code review – priorytety
Weryfikuj w kolejności: architektura (DI, brak ObjectManager, Service Contracts), logika biznesowa, edge cases, styl kodu. Nie odwrotnie. Sprawdź czy SearchCriteria ma setPageSize – brak limitu to tykająca bomba na dużych katalogach.
Branch naming
feature/JIRA-123-order-export-csv fix/JIRA-456-tax-calculation-virtual refactor/order-service-di-cleanup chore/upgrade-php-84
Podsumowanie
Git Flow – dla zespołów z wersjonowanymi releasami. Trunk-based – dla ciągłego deploymentu. Dobry PR zawiera opis co, dlaczego i jak testować. Code review zaczynaj od architektury, nie stylu. Następny wpis: Git hooks i automatyzacja – pre-commit z PHPStan i integracja z DDEV.
