Q: Your team debates whether to use squash-merge, rebase-merge, or regular merge commits when closing PRs. What are the tradeoffs of each strategy?

Each strategy produces a different commit history shape with different tradeoffs:

• Pros: preserves full branch history; you can see exactly what happened on the feature branch; easy to revert the entire PR with git revert -m 1 .
• Cons: history is noisy with "fix typo" and "WIP" commits; git log on main shows every commit from every branch; git bisect may land on broken intermediate commits.
• Pros: one clean commit per PR on main; git log is easy to read; each commit is a complete, reviewable unit; git bisect is highly effective.
• Cons: original branch history is lost (individual commits disappear); the squashed commit has a single author even if the PR had multiple contributors; if the PR is large, the single commit is hard to review or partially revert.
• Pros: linear history, no merge commits; each commit is preserved individually; clean git log.

1. Merge commit (--no-ff): 2. Squash merge: 3. Rebase merge (fast-forward): Recommendation by team maturity: Many teams use squash for feature PRs and merge commits for release/hotfix merges.

*   Merge PR #42: Add user auth
|\
| * Fix test
| * Add JWT middleware
| * Add login endpoint
|/
* Previous main commit

• Cons: no visual grouping of "this PR's commits"; harder to revert an entire PR (must revert multiple commits); requires the feature branch to be rebased onto latest main before merging; commit SHAs change.
• Small team, disciplined commits: rebase-merge — clean, linear, each commit meaningful.
• Medium team, mixed commit quality: squash-merge — hides messy history, one commit = one PR.
• Large team, compliance needs: merge commits — full traceability, easy PR-level reverts, audit trail preserved.