Reputation: 197
Consider the state
A - B - C - D - E - F - G (master)
\
B1 - B2 - B3 (B-branch)
Now i want to rebase B-branch onto G. Everything works well, except for E
which is a merge commit that adds a bunch of "TODO" comments around the code changed in the B branch, but which causes confusion on git diff algo, and even selecting git checkout --ours
on every single conflict, still gets a bad state after the rebase.
What's the best way to ignore the changes on commit E and rebase the branch?
Upvotes: 1
Views: 480
Reputation: 197
answering myself as the answer become obvious after i drew the branches. but please let me know if there is something smarter.
A: just checkout master, revert the trouble/undesirable commit, and carry on as usual!
# NOTE: you can name a copy of master any other name to keep
# your actual master/main branch clean, using the actual
# master branch on the example for clarity.
# if you do use your master branch, reset it back afterwards!
git checkout master
git pull
git revert E
# at this point we have
# A - B - C - D - E - F - G - H(revert E)
git checkout branchB
git rebase master
done. now we have
A - B - C - D - E - F - G - H - B1 - B2 - B3
if we call H
as B0
it makes it easier to visualize what the branch actually looks like from a pull-request point of view:
before:
master: A - B - C - D - E - F - G
B-branch: `- B1 - B2 - B3
after:
master: A - B - C - D - E - F - G
B-branch: `- B0 - B1 - B2 - B3
which is a up to date clean merge. and you can easily add the changes from E back on a B4 commit if needed, without going insane with conflict-per-commit if leaving git rebase do it.
Note that you can revert as many commits as needed ;) This is perfect if the "temporary" solution to a problem was added while you worked on the permanent fix later on. It also documents exactly what was done instead of hiding the reverts in the reworked post-conflict commits.
Upvotes: 3