The choice of Git workflow has a bigger impact on team productivity than most technical decisions. Git Flow, GitHub Flow, trunk-based development are complete models for work, code review, and deployment. I show when to use each and what separates a good pull request from a bad one.
Git Flow
Git Flow defines several branch types: main (production), develop (integration), feature/xxx, release/x.y, hotfix/xxx. Works well for versioned software with numbered releases.
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
One main branch, short feature branches (max a few days), CI/CD on every push, deploy after merge to main. Requires feature flags to hide unfinished features.
git checkout -b feature/add-loyalty-points git push -u origin feature/add-loyalty-points # Open Pull Request, code review, CI passes # Squash and merge to main, automatic deployment
Pull Request – structure
## What I did Added order export to CSV. Refs: #247 ## How to test 1. Admin > Sales > Orders 2. Select orders, Export > CSV ## Checklist - [x] Tests passing - [x] phpstan --level=8 no errors - [x] Breaking changes: none
Code review – priorities
Review in order: architecture (DI, no ObjectManager, Service Contracts), business logic, edge cases, code style. Not the reverse. Check that SearchCriteria has setPageSize – missing limit is a time bomb on large catalogues.
Branch naming
feature/JIRA-123-order-export-csv fix/JIRA-456-tax-calculation-virtual refactor/order-service-di-cleanup chore/upgrade-php-84
Summary
Git Flow – for teams with versioned releases. Trunk-based – for continuous deployment. A good PR contains a description of what, why, and how to test. Start code review with architecture, not style. Next post: Git hooks and automation – pre-commit with PHPStan and DDEV integration.
