Version control with Git gives us multiple ways to manage changes in a codebase. While git merge is the more beginner-friendly approach, git rebase often becomes the go-to for developers who want cleaner commit history and a more streamlined workflow. In this article, I’ll walk you through why we need rebase, the difference between merge and rebase, and why I personally prefer using rebase when raising pull requests.

Why Rebase?

When working in team, this is a often that branch gets diverged. You might be developing a new feature on a branch, while the main branch continues to receive commits from other teammates. Over time, your branch falls behind. Now to keep your feature branch up-to-date and don't have conflicts, you need to incorporate these changes.

Now, many developers (myselft also) usages git merge way too much but the issue is that git merge introduce a new "merge commit" every time. Over a long running branch this can clutter your history with numerous merge commits. Now this is where rebase comes. Simply, Rebase allows you to “replay” your commits on top of the latest branch, making it look as if you started your work from the most recent commit of main.

StackEdit stores your files in your browser, which means all your files are automatically saved locally and are accessible offline!

The primary goal of rebase is to simplify history. This helps.

• Keep commit history linear and easy to follow.
• Avoid unnecessary merge commits cluttering the history.
• Ensure your feature integrates smoothly before raising a PR.

Merge vs Rebase

Don't get me wrong, merge is the way to go, but for sometimes i want my commit history to be clean and especially i don't want any confusion later on. This way, if a feature causes issues down the line, I can easily trace it back without confusion.

Both merge and rebase solve the same problem, bringing your branch up to date with another branch. But they do it differently.

Git Merge

• Combines histories by creating a new merge commit.
• Preserves the chronological history of commits as they actually happened.
• Can clutter the history with a lot of merge commits, especially in long-running branches.

Git Rebase

• Moves your commits on top of the branch you’re rebasing onto.
• Produces a linear history without extra merge commits.
• Rewrites commit history (so should be used carefully on shared branches).

Why I Prefer Rebase When Raising PRs

When raising a PR, your goal is to present a focused, high-quality, and easy-to-review set of changes. Personally, I find rebase to be cleaner when preparing my branch for a pull request. Here’s why:

1. Cleaner Commit History – Reviewers see a straight line of commits, making it easier to follow the logic of changes. No extra merge commits distracting from the actual work.
2. Better Collaboration – When multiple developers are raising PRs, rebased branches integrate more smoothly with fewer conflicts during merges into main.
3. Easier Code Review – Rebasing helps ensure your branch already has the latest changes from main, reducing the “surprise conflicts” when merging the PR.
4. Professional Workflow – Many large engineering teams encourage rebasing before raising PRs for the sake of history clarity and consistency.

Still scratching your head about git rebase?

Don’t worry, I made a beginner-friendly video that goes from “wait, what just happened?” to “ohhh, I get it now!”.

Check it out here 👉