I and another developer have been working on a topic branch topic
for a few days. We have been sharing changes by pushing and merging topic
from a shar开发者_StackOverflow社区ed repo.
We have also been keeping up with master
by merging with it frequently. So, now, our log shows our commits interspersed with the later commits from master.
I would like to rebase so our commits all come after master. Conflicts are plentiful within the files we worked on, but I know that I want to use the topic
version in all cases.
I tried git rebase -s recursive -X ours origin/master
but that included both the topic
version and the master
version, which is very wrong. I want to only include the topic
version of files I have worked on.
I then tried git rebase -s ours origin/master
, but that seems to remove my commits.
What is the correct way to rebase, favoring my changes in topic
?
Not a fun situation. Maybe some variant of what you're trying will work, but I'd try something different.
Let's call the merge commits M1, M2, ..., MN
git reset M1^1
git rebase M1^2
Record the result, e.g. git tag topic-rebased1
git reset M2^1
git rebase --onto topic-rebased1 M1
git rebase M2^2
Go back to (3) and repeat until you've rebased all the merges
What you really need is a strategy for doing this in future to not get into this mess.
I suggest something like:
Do exactly what you did before, except make one person responsible for merging master into the topic branch
The person responsible for merging also maintains a rebasing branch. Each time they merge master into the non-rebasing branch they also rebase the latest changes from the non-rebasing branch onto the rebasing branch and then rebase the rebasing branch onto master
Yes, I know - it sucks.
During a rebase, "ours" and "theirs" are reversed.
精彩评论