Dev Notes

Why I Prefer Rebase Over Merge

This is an opinionated take. Merge works fine for many teams. But here is why I prefer rebase.

The Problem with Merge

Frequent merge commits create noise:

* Merge branch main into feature
* Merge branch main into feature
* Merge branch main into feature
* Actually useful commit
* Merge branch main into feature

The actual work gets buried under merge commits.

Rebase Workflow

# Start feature branch
git checkout -b feature/add-auth

# ... make commits ...

# Before merging, rebase onto latest main
git fetch origin
git rebase origin/main

# Force push to update PR (only for your own branch)
git push --force-with-lease

# Merge PR (fast-forward or squash)

Golden Rule

Never rebase shared branches. Only rebase your own feature branches before merging.

Interactive Rebase

Clean up commits before merging:

git rebase -i HEAD~3
pick abc1234 Add user model
fixup def5678 Fix typo in user model
pick ghi9012 Add authentication middleware

This squashes the typo fix into the original commit.

When Merge is Better

  • Shared branches where multiple people push directly
  • Release branches where you need to preserve the merge point
  • When you do not care about commit history (and that is okay)

My Setup

# Always rebase when pulling
git config --global pull.rebase true

# Auto-stash before rebase
git config --global rebase.autoStash true

Clean history is not just aesthetics. It makes git bisect, git log, and code reviews significantly more effective.