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?
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.
