Git Fixing a Merge Broken by Base Branch Rebase: Difference between revisions
No edit summary |
|||
| (4 intermediate revisions by the same user not shown) | |||
| Line 2: | Line 2: | ||
* [[Git Operations#Procedures|Git Operations]] | * [[Git Operations#Procedures|Git Operations]] | ||
* [[Git_Rebasing#What_to_Do_if_the_Base_Branch_was_itself_Rebased|Git Rebasing]] | |||
=Overview= | =Overview= | ||
You may have found yourself in the situation when you attempt to merge just to find out that the base branch is rebased. A typical symptom for this situation is that Git warns about unexpected merge conflicts. What used to be a clean merge suddenly turns into a merge with a large number of conflicts, usually caused by files you don't recognize and don't have anything to do with. This article contains a procedure that will help you recover from that situation and render your merge viable again. It assumes that the [[Git_Concepts#Base_Branch|base branch]] is "develop", and the [[Git_Concepts#Head_Branch|head branch]] to be merged is "topic/something". | |||
You may have found yourself in the situation when you attempt to merge just to find out that the base branch is rebased. A typical symptom for this situation is that Git warns about unexpected merge conflicts. What used to be a clean merge suddenly turns into a merge with a large number of conflicts, usually caused by files you don't recognize and don't have anything to do with. This article contains a procedure that will help you recover from that situation and render your merge viable again. It assumes that the base branch is "develop", and the head branch to be merged is "topic/something". | |||
=Procedure= | =Procedure= | ||
| Line 24: | Line 23: | ||
Rebase the head branch commits at the proper location on the base branch. Note that in the example below, "0742faad3a6c8633f0625e29cf215a6f0f2e189a" is the commit identified previously: | Rebase the head branch commits at the proper location on the base branch. Note that in the example below, "0742faad3a6c8633f0625e29cf215a6f0f2e189a" is the commit identified previously: | ||
git rebase --onto origin/develop --fork-point 0742faad3a6c8633f0625e29cf215a6f0f2e189a | git rebase [[Git_rebase#--onto|--onto]] origin/develop [[Git_rebase#--fork-point|--fork-point]] 0742faad3a6c8633f0625e29cf215a6f0f2e189a | ||
If the command finished successfully, <tt>git log</tt> should show your commit at the top of the branch, with a different parent, and the graphical GitHub PR interface should tell you there are no merge conflicts anymore. | |||
Fix the upstream head branch, doing a "dry run" first: | Fix the upstream head branch, doing a "dry run" first: | ||
Latest revision as of 23:55, 18 February 2020
Internal
Overview
You may have found yourself in the situation when you attempt to merge just to find out that the base branch is rebased. A typical symptom for this situation is that Git warns about unexpected merge conflicts. What used to be a clean merge suddenly turns into a merge with a large number of conflicts, usually caused by files you don't recognize and don't have anything to do with. This article contains a procedure that will help you recover from that situation and render your merge viable again. It assumes that the base branch is "develop", and the head branch to be merged is "topic/something".
Procedure
First, checkout the problematic topic branch and identify the base ("develop") branch commit the head branch originates from:
git checkout topic/something git log
The "develop" branch commit will be the first commit that is not "yours" - that is, the first commit that is not a commit created by you on the "topic/something" branch.
Sync repository state:
git fetch --prune
Rebase the head branch commits at the proper location on the base branch. Note that in the example below, "0742faad3a6c8633f0625e29cf215a6f0f2e189a" is the commit identified previously:
git rebase --onto origin/develop --fork-point 0742faad3a6c8633f0625e29cf215a6f0f2e189a
If the command finished successfully, git log should show your commit at the top of the branch, with a different parent, and the graphical GitHub PR interface should tell you there are no merge conflicts anymore.
Fix the upstream head branch, doing a "dry run" first:
git push -n --force git push --force
Synchronize the state of local "develop" branch with the state of its tracking branch:
git checkout develop git reset --hard origin/develop