How should Git, branching and code review work in a team?
Version control records every change, who made it and why, and makes rollback possible.
Recommended workflow
- Short-lived feature branches off a protected main (trunk-based development) — merge small and often; use feature flags for unfinished work
- Pull requests with required reviews, passing CI and CODEOWNERS approval; no direct pushes or force-pushes to main
- Commit hygiene: small, cohesive commits with meaningful messages (for example Conventional Commits)
- Merge strategy: squash or rebase for linear history; resolve conflicts on the feature branch, not on main
- Tagging and releases: semantic versioning, changelogs and tagged release artifacts
A good code review checks correctness, security, readability, tests, performance and maintainability — and is respectful and specific. Review the design, not the person.
Pitfalls: long-lived branches, giant pull requests, rubber-stamp reviews, secrets committed to history.