Master Git Rebase vs Merge: When to Use Each and Avoid Common Pitfalls

Introduction

git rebase is often considered a Git wizardry that beginners should avoid, but it can actually make development teams' workflow easier. This article compares git rebase with the related git merge command.

Concept

Both git rebase and git merge solve the same problem: integrating changes from one branch into another, but they do it differently. When you develop a new feature on a dedicated branch and another teammate updates the master branch, a divergent history appears.

Merge

The simplest and most common way is to merge master into your feature branch.

git checkout feature
git merge master
# or in one line:
git merge master feature

This creates a new merge commit that links the two branch histories without altering existing commits. However, frequent merges can clutter the history with unnecessary merge commits.

Rebase

As an alternative, you can rebase your feature branch onto master.

git checkout feature
git rebase master

Rebase moves the entire feature branch to the tip of master, rewriting history by creating new commits for each original commit, resulting in a linear history without merge commits.

Benefits include a cleaner project history and a perfect linear timeline, making commands like git log, git bisect, and gitk easier to use. However, rebase trades safety and traceability; rewriting history on public branches can cause disastrous collaboration issues, and you lose the context provided by merge commits.

Interactive Rebase

Interactive rebase lets you modify commits while moving them to a new base, offering full control over the branch history. It is useful for cleaning up messy history before merging a feature branch.

git checkout feature
git rebase -i master

The editor lists all commits to be moved:

pick 33d5b7a Message for commit #1
pick 9480b3d Message for commit #2
pick 5c67e61 Message for commit #3

You can change "pick" to "fixup" to squash commits, for example:

pick 33d5b7a Message for commit #1
fixup 9480b3d Message for commit #2
pick 5c67e61 Message for commit #3

Golden Rule of Rebase

Never rebase a public branch. Rewriting commits that others have based work on will diverge histories and require additional merges, causing confusion.

Force Push

After rebasing, pushing to a remote will be blocked. You can force push with --force, but this overwrites the remote branch and can confuse teammates.

# Use with extreme caution!
git push --force

Local Cleanup

Integrating rebase into your workflow helps keep local feature branches clean. Regular interactive rebases ensure each commit is purposeful.

Rebase offers two base options: the parent branch (e.g., master) or an earlier commit in the feature branch. For example, to rebase only the last three commits:

git checkout feature
git rebase -i HEAD~3

To find the original base of a feature branch, use git merge-base: git merge-base feature master Interactive rebase only affects your local branch; other developers only see the final, clean history.

Conclusion

If you prefer a clean, linear history without unnecessary merge commits, use git rebase when incorporating changes from another branch. If you need to preserve the full history and avoid rewriting public commits, stick with git merge. Both approaches are valid; choose based on your workflow needs.