The “rebase vs merge” debate is one of the most discussed topics in Git. This is because Git provides two different ways to integrate changes, and the choice often comes down to preference.

The Short Answer

Use both—they serve different purposes.

How Rebase Works

When working on a feature branch, and you’re ready to merge it into main, you rebase the feature branch upon main.

This means:

1. All changes committed to main are applied to your feature branch first
2. Then all your feature branch commits are applied after them

Even if work continued on main after you created your feature branch, after rebasing it will look like all the main commits were done before you even created your branch.

The Workflow

1. Create a feature branch from main
2. Make your commits on the feature branch
3. Meanwhile, main might receive new commits
4. Before merging, rebase your feature branch upon main:

git checkout feature-branch
git rebase main

5. Resolve any conflicts during the rebase
6. Once ready (and assuming no new changes to main), merge with a fast-forward:

git checkout main
git merge feature-branch

Benefits of This Approach

Avoiding Merge Commits

When you rebase before merging, you can do a “fast-forward merge” which doesn’t create a merge commit. Merge commits can clutter your history with messages like “Merge branch ‘feature’ into main”.

Cleaner History

Your git log shows a linear history without interleaved commits from different branches. It’s easier to understand what happened and when.

Easier Conflict Resolution

By resolving conflicts during rebase (one commit at a time), you often get smaller, more manageable conflicts than resolving everything at once during a merge.

The Golden Rule

Never rebase main (or any shared branch).

Rebasing rewrites history. If you rebase main, you’re rewriting the history that other developers have based their work on. This leads to divergent histories and painful merge conflicts.

Only rebase feature branches upon main—never the other way around.

When to Just Use Merge

Sometimes a simple merge is fine:

• Quick fixes directly on main
• When you want to preserve the exact history of when things happened
• When working with less experienced team members who might find rebase confusing

Summary

1. Work on feature branches
2. Rebase feature branches upon main before merging
3. Fast-forward merge to avoid merge commits
4. Never rebase shared branches like main

Lessons in this unit:

0:	Introduction
1:	Working with Remotes
2:	Squashing Commits
3:	▶︎ Rebase vs Merge
4:	Git Bisect for Debugging
5:	Git Worktrees
6:	Git Submodules
7:	Understanding Detached HEAD
8:	Managing Secrets in Git
9:	Git Workflows and Best Practices
10:	How to push to 2 repositories at the same time and keep them in sync
11:	How to update a Git branch from another branch
12:	Git, detached HEAD
13:	Trigger deploys on Netlify with submodules
14:	A Git Cheat Sheet
15:	Git, squashing vs not squashing
16:	An incomplete list of great Git tutorials
17:	Git, what if you forgot to add a file to a commit?
18:	Git workflow to manage work on multiple branches
19:	How to setup the Git SSH keys