When do you prefer git rebase over git merge?

[Ajaykedia123]

Discussion Type

Question

Discussion Content

Hi everyone,

I'm trying to understand the practical differences between git rebase and git merge. I know what each command does, but I'm curious about real-world workflows.

When do you personally choose rebase instead of merge, and why? Are there situations where one should always be avoided?

[blazee14]

Hi @Ajaykedia123,
Great question, this comes up a lot once you move past the basics. Here's how I think about it in practice:
When I use rebase:

Local, not-yet-pushed commits: Before pushing my branch, I rebase onto the latest main to keep a clean, linear history instead of an unnecessary merge commit.
Cleaning up my own work: With git rebase -i, I squash "fix typo", "oops", "wip" commits into meaningful ones before opening a PR. Makes code review much easier.
Feature branches that haven't been shared: If no one else is working off my branch, rebasing is safe and keeps history readable.

When I use merge:

Shared/public branches: If others have already pulled my branch, I never rebase it, rewriting history that others have based work on causes major conflicts for everyone else.
Integrating a feature into main: When a feature branch is done, I merge it into main (often with --no-ff) so there's a clear commit marking "this feature was merged here", useful for tracking releases and reverting a whole feature if needed.
Long-running branches: For branches like develop or release branches that live for a while, merge preserves the actual timeline of what happened, which is valuable for debugging later.

The golden rule:

Never rebase commits that exist outside your local repository (i.e., that others may have pulled), unless you're 100% sure no one else depends on them.

Situations where you should basically always avoid rebase:

Shared feature branches with multiple contributors.
main/master or any protected/production branch.
Public branches other repos or CI pipelines depend on.

A simple mental model:

Rebase = rewriting history to make it look like it happened linearly (good for your own local, unshared commits).
Merge = preserving history exactly as it happened, including the fact that two branches diverged and came back together (good for anything shared).

A common team workflow: rebase your local feature branch onto main before opening a PR (to avoid a messy history), then merge the PR into main using merge (to keep a clear record of when the feature landed).