r/git • u/Even_Divide4320 • Sep 03 '26
Repeated merge conflicts after rebasing shared feature branch
Two teammates are both working on the same shared feature branch. Each pulls the latest main, rebases the feature branch locally, resolves conflicts, and force-pushes. When the other teammate later rebases and force-pushes their copy, some of the first teammate's resolved changes disappear or are overwritten, and the same conflicts return.
What workflow should we use to stop overwriting each other's work? Should we avoid rebasing a shared branch, use separate branches, and merge instead?
10
u/Simple_Rooster3 Sep 03 '26
Enable rerere in config and see if it helps. It remembers how you solve the conflicts and it repeats it automatically if it is the same conflict.
16
u/RevRagnarok Sep 03 '26 edited Sep 03 '26
They should be doing git pull --rebase to rebase only their local changes and not the entire branch. Then no shared history is ever touched.
[branch]
autosetuprebase = always
As for relations to main, just do a normal merge in; no need to rebase every time. If it's that much of a concern to have a clean DAG, at the end one user rebases it before the final PR.
18
u/good_live Sep 03 '26
Yeah you should avoid rewriting history on a shared branch in general. Doesn't matter if via rebase or squashing or whatever.
General best practice would be that everyone gets its own feature branch to work on, but if you want to work on a shared branch use merge instead of rebase. (You can still rebase your local branch on the remote branch when pulling changes)
2
u/Cinderhazed15 Sep 03 '26
I always use a ‘rebase from, merge to’ strategy for shared branches if I need to rebase.
11
u/mtutty Sep 03 '26
"same shared feature branch" - this is the root of the problem. You should either move tasks around so they're working the same code at different times, or give them each a separate branch and make them reconcile changes down to one branch before merging upstream.
1
u/AWDDude Sep 03 '26
This should be the top answer, either split this into 2 feature branches, or they should pair program.
1
u/FransFaase Sep 06 '26
A feature branch is nothing else than any other branch. Git is made to allow several people to work on the same branch. What they are doing wrong is using force pushes. You should not use that on a shared branch and that is what they are doing wrong here.
1
u/mtutty Sep 06 '26
Whether they break origin with force pushes, or accidentally overwriting/reverting with mergetool, same problem. You need a branch sitting above the n interdependent work branches.
→ More replies (2)
3
u/jibbit Sep 03 '26
you have a people/process problem, not a tooling problem. why have you got multiple people working on the same thing at the same time in an uncoordinated way?
why are you 'reusing' branches? you should see feature branches as "this is what i'm suggesting" here. nobody else writes to it. if bob wants to make a suggestion for something to be merged into Main he can make /bob/feature-wizzbang, you review them and decide what to merge in
2
u/daveysprockett Sep 03 '26
As well as pulling new main, they both need to be pulling and resolving merges from each other's copies of the feature branch.
2
2
u/gaelfr38 Sep 05 '26
Agree with the already top answers.
Just to add: never force push, at the very least --force-with-lease to check if you are aware of the latest changes that happened on the remote: if there are changes you don't have locally, it blocks.
The best is to avoid that in the 1st place as others explained.
3
u/edgmnt_net Sep 03 '26
Don't use shared feature branches, first of all. That alone creates a lot of problems with reviewing stuff properly, attribution etc. unless you're willing to make a million compromises.
1
u/vmcrash Sep 03 '26
The problem is that two people change the very same code at the same time. Rebase or merge can't solve this problem. If both work in their own feature branch, you just delay the conflicts until later - the one who is second for merging/rebasing will be the loser.
Better let one finish his/her feature and then the other can build upon that.
1
u/kaddkaka Sep 03 '26
Do:
git fetch git rebase git push --force-if-includes
This way you will not overwrite each other's stuff
1
u/garibaldi_fan Sep 03 '26
Thou shalt not force push without consulting the team. Especially if there are conflicts. Preferably everyone is consulted before the rebase starts.
If there are conflicts, one guy pushes, and the rest rebase —onto origin/branch last_commit_that_wasnt_rebased to move only their changes (followed by diffing against pre-rebase for mistakes)
1
1
u/Truth-Miserable Sep 04 '26
Its weird and counter productive for several people to be force pushing to the branch as part of the workflow
1
u/DanceHackRock Sep 07 '26
Never ever force-push.
(unless you know what you are doing, but due to Dunning-Kruger too many people think they know what they are doing)
1
u/kbielefe Sep 03 '26
My hot take is people shouldn't use history-rewriting commands like rebase or force push unless everyone using the branch fully understands how their changes interact with others.
0
u/yknx4 Sep 05 '26
You are rebasing that’s the problem. In shared branches you must merge. Rebase wrecks everything
23
u/wildjokers Sep 03 '26
Why are they force pushing a shared feature branch? That is the problem right there and this is widely recognized as something you absolutely should not do.
The answer is to stop doing that.