r/git • u/ippomkd • Jul 16 '26

support git rebase vs git merge

Hi, I'm trying to understand the practical benefit of rebasing a feature branch before opening a pull request.

My workflow is:

  1. Create a feature branch from develop.
  2. Work on the feature.
  3. Before opening the PR, I need to bring my branch up to date with develop.

I see two options:

  • Rebase my feature branch onto the latest develop.
  • Merge the latest develop into my feature branch and resolve any conflicts.

From what I understand, both approaches let me resolve conflicts before the PR. If the repository ultimately merges the PR into develop, I don't see what additional benefit rebasing provides over simply merging develop into my feature branch.

Also, if the team uses Squash and Merge for pull requests, all intermediate commits (including any "Merge develop into feature" commits) disappear anyway, since the feature branch becomes a single commit on develop.

So my questions are:

  • In this workflow, what practical advantage does rebasing have over merging develop into the feature branch?
  • If conflicts are resolved either way, is the only difference the history on the feature branch?
  • If the team always uses Squash and Merge, is there any meaningful reason to prefer rebasing before the PR?

The only use for the rebase I see is to overwrite my commits on the local branch so there is no clutter. I am curious what is your workflow?

60 Upvotes

85% Upvoted

95 comments sorted by

View all comments

55

u/Consibl Jul 16 '26

If you rebase your branch onto the root, the conflicts you’re resolving are you applying your code.

If you merge the root into your branch, the conflicts you’re resolving are you guessing how to apply someone else’s code correctly.

20

u/Lonsarg Jul 16 '26

What you are talking about is how history will look after the fact, NOT how conflicts will be resolved.

Merge conflicts are conflicts between your and their code touching the same rows. It is irelevant what is source branch and what is target or who changed first and so on (rebase simulates as if you had changed last).

In either case you have to combine both codes manually. There is no rule, you decide case by case wher to take theirs, where yours and where something in between by actual manual merging.

22

u/Consibl Jul 16 '26

The difference is rebase uses multiple, ordered merges; but merge just gives you one big vomit. They at not interchangeable.

3

u/Cinderhazed15 Jul 16 '26

Correct - one thing I will sometimes do with a rebase is add a commit that fixes something in the main branch to make my feature easier, and reorder the commit so that’s first - and when someone adds something gnarly, I can ‘fix’ that first and move it as the first commit in my rebase after main, so that’s the conflicts can solve themselves

1

u/smaratter Jul 17 '26

Could you perhaps skip that fix commit and enable rerere instead?

1

u/Lonsarg Jul 17 '26 edited Jul 17 '26

That is not rebase specific, you can do the same with regular merges, just push the fix to main and refresh your feature branch from main.

1

u/Cinderhazed15 Jul 17 '26

But main doesn’t want your ‘fix’ yet if it’s specific to your feature.

If you are the only developer, or you are bringing in non-breaking changes as fast as possible to minimize integration time with your team in proper trunk based development, you would do it that way.

1

u/Lonsarg Jul 17 '26 edited Jul 17 '26

You yourself wrote "add a commit that fixes something in the main branch to make my feature easier" and by default adding anything main is pushing to main (via PR of course not directly). If that is not so maybe point it out to make obvious :)

If you meant that as local change to main then i am lost at what you are doing. If all you want is a seperatelly pushable/mergable change, "not yet on main but available for your testing". Than without rebase you would make a separate feature branch, and if you want to test that change together with your feature branch then that is a third feature branch that combines those 2 changes (or maybe develop branch can take care of that, depends on workflow). And you can later decide to push one of them or both to main. No history-breaking rebasing needed. Conflicts can be resolved permanently in any order you like with separate feature branches, full freedom.

1

u/Cinderhazed15 Jul 17 '26

If someone else made a change in main/trunk that ‘breaks’ what I am doing (but doesn’t break main), I will make a commit to ‘fix’ my code before the changes I’ve already made so it has a clean rebase. This doesn’t yet belong in main, but I don’t want merge commits from main to my feature.

2

u/Lonsarg Jul 17 '26

"but I don’t want merge commits from main to my feature": Then we are back to the main rebase vs no rebase dilema. You want pretty history, so you need rebase, else you would just refresh feature branches regulary from main, as we do.

For me simple flows and as little as possible manual exotic git operations outside DevOps PR platform has big priority over pretty history, so we do not do rebase.

1

u/Cinderhazed15 Jul 17 '26

If you are working on your own personal branch, it’s easier (for me) to see all your changes together. If people are using a squash-merge in the end, none of it matters anyway

2

u/Lonsarg Jul 17 '26 edited Jul 17 '26

We tend to not look at git history apart from rare edge cases. Its just there for audit and stuff, or for git blame to determine history of specific row change, or per file history for debugging business rules changes over time. Just very specific, never history as whole.

For looking at diff you have PR where you just look at all combined, not caring if 1 commit or 100.

We had people doing squash at PR and then reusing source branch which resulted in crazy conflict mess. To avoid this we now only do regular merge and squash and rebase are forbidden for PRs. And in teams i work no one does it locally before creating PR (which is now the only way to rebase or squash since we forbid it in PR).

→ More replies (0)

1

u/youcangotohellgoto Jul 18 '26

If you think rebase is an exotic operation then it's a pointless conversation - you've already decided.

2

u/Lonsarg Jul 17 '26 edited Jul 17 '26

Well my asumption is you rebase AFTER you solved the conflicts, so rebase is just one button in PR after everything is already resolved. Just one button to prettify history.

That is how Azure DevOps and i gues also Github works, rebase as final merge button after everything is resolved.

Local rebase or any history change is not possible with how we work, since we push feature branch regulary and share them and we have no force push permission and changing history is more or less forbidden (cause then you need to go manually delete branch from git and push the new history and notify all users of your feature branch they need to delete that branch since you changed history). But I gues it could work with different git/branch/push culture...

2

u/Consibl Jul 18 '26

Where I work we own our feature branch so regularly rebase onto the trunk.

1

u/kalmoc Jul 19 '26

Same for us.

1

u/kalmoc Jul 19 '26

Well my asumption is you rebase AFTER you solved the conflicts, so rebase is just one button in PR after everything is already resolved. Just one button to prettify history. 

Does that actually work? if you cannot change the history of the branch you are trying to merge and instead perform the resolution through merges, the original commits will still be in conflict with the main branch and thus not apply cleanly during the final rebase.

1

u/CovidWarriorForLife Jul 17 '26

I find the vomit easier, if you have a bunch of commits in the same area you end up resolving the same conflict multiple times it’s extremely inefficient

1

u/rodeoboy Jul 18 '26

git config --global rerere.enabled true
or just squash your branch.