Git is the one tool nearly every developer touches every day, and a sloppy workflow quietly taxes the whole team - merge conflicts, unreviewable pull requests, and a history nobody can read during an incident. The good news is that the habits that fix this are simple and cheap. This guide covers the branching strategy, commit hygiene, and pull request discipline that keep a 2026 team shipping fast without leaving a mess behind.
What changed in 2026
- Trunk-based development is the consensus default. Short-lived branches merged frequently won out over heavyweight branching models for most teams.
- AI-written commit messages and PR summaries are common. Assistants draft them well, but a human still owns the why - the part that matters most later.
- Conventional Commits stayed popular for automation. Structured commit prefixes drive changelogs and version bumps in many repos, though they are optional.
- Branch protection is table stakes. Required reviews and passing CI before merge are now the norm, not a nicety, on shared branches.
Branching strategy
For most teams, trunk-based development wins: everyone branches off main, keeps the branch short-lived (hours to a couple of days), and merges back frequently behind feature flags if needed. Long-running branches are where pain lives - they drift from main, accumulate conflicts, and turn the eventual merge into an ordeal.
| Model |
Best for |
Trade-off |
| Trunk-based |
Most teams, continuous delivery |
Needs discipline and CI to keep main green |
| GitHub Flow |
Small to mid teams, simple releases |
Slightly more branch ceremony |
| Git Flow |
Versioned products with parallel releases |
Heavy; overkill for one-environment apps |
Commit and pull request hygiene
- Make commits atomic. One logical change per commit. It makes review, reverting, and bisecting far easier later.
- Write messages for the future reader. A clear subject line under about 50 characters, then a body explaining why, not just what. The diff already shows what changed.
- Keep pull requests small. A focused 200-line PR gets a genuine review; a 2000-line PR gets skimmed and approved. Split large work into reviewable chunks.
- Protect main. Require at least one review and passing CI before merge so nobody breaks the branch everyone depends on.
Add idempotency key to charge endpoint
Retries from the mobile client were creating duplicate charges
when the network dropped after the request reached the server.
Accepting an Idempotency-Key header makes the retry safe.
Merge or rebase
Both are fine; consistency matters more than the choice. Rebasing local work before merging produces a linear, readable history but rewrites commits, so never rebase a branch others have pulled. Merge commits preserve exact history at the cost of a busier graph. A common middle ground is to rebase your own feature branch to stay current, then squash-merge into main for a clean trunk history. Whatever you pick, document it so the team does not mix approaches. These habits pay off most when paired with a fast CI/CD pipeline that gates every merge.
What to skip
- Skip Git Flow for small teams. Its release and hotfix branches add ceremony that one-environment apps do not need. Trunk-based is simpler.
- Skip long-running feature branches. They drift and conflict. Merge small and often, hiding incomplete work behind flags.
- Skip force-pushing shared branches. Rewriting history others have pulled breaks their local copies. Only rebase branches you alone own.
- Skip giant pull requests. They do not get real review. If a change is big, stage it across several small, reviewable PRs.
FAQ
Trunk-based development or Git Flow in 2026?
Trunk-based for most teams shipping continuously to a single environment. Reserve Git Flow for products that maintain multiple released versions in parallel and genuinely need release branches.
Should I rebase or merge?
Either works; be consistent. Rebase your own branch to keep history linear, but never rebase a branch others share. Squash-merging into main is a popular way to keep trunk clean.
How small should a pull request be?
Small enough to review carefully in one sitting - often a few hundred lines. If it is larger, split it. Smaller PRs get better reviews and merge faster.
Do I need Conventional Commits?
Only if you want to automate changelogs and version bumps. They are useful but optional; a clear, consistent message style matters more than the exact format.
Where to go next
Run effective code reviews, compare CI/CD tools, and debug faster when things break.