I have committed a big merge. Later, it appears that some files weren\'t merged correctly. I want to redo just these files, not the entire merge - the merge was big and I do
You can, in fact, simply perform the merge again. (Be sure you have git rerere
turned off.)
Remember, git merge
looks at three things: your current commit, the commit you ask it to merge, and the merge-base of those two commits. (Well, also your strategy arguments and so on, of course, but you can repeat those as well.) It's true that you already committed a merge result, but you can still get back on the commit you were on earlier:
o---o---X <-- otherbranch
/ \
...--o--* \
\ \
o--o--o--Y--M <-- HEAD -> yourbranch
Your merge M
is the result of merging commits Y
and X
(with merge base *
). But you can check out commit Y
as either a detached HEAD or a new branch. To make a new branch:
git checkout -b newbranch yourbranch^
which produces:
o---o----X <-- otherbranch
/ \
...--o--* M <-- yourbranch
\ /
o--o--o--Y <-- HEAD -> newbranch
(this is the exact same graph but I moved M
up a bit to make room for newbranch
to point to commit Y
—think of the graph as being kind of rubbery/stretchy, or printed on Play-Doh®, or whatever). Now you can git merge otherbranch
and start re-creating commit M
.
Now you can grab merge results (rather than re-resolving) using git checkout yourbranch -- path
for various path
s (even the top path), and optionally git checkout -m
parts to re-create conflicts.
When you are all done, git commit
will make a new M2
merge whose first parent is Y
and second parent is X
, and newbranch
will point to the new merge M2
.
Since git created a commit that represents your big merge with conflicts you could have just change that commit. To do that, in your working directory, do all the fixes, add to index and amend commit.
# do all the fixes
git add .
git commit --amend
If you have already pushed the branch after merging, and you suspect that someone else may have pulled it, then you should avoid editing the merge commit. Instead, you are safest just fixing the files and making a new commit with those changes.
If this be not a concern, then you can try amending the merge commit, assumint that this merge commit is at the HEAD
of your branch. Just edit the files which were merged wrongly, test your code, and if you are satisfied, then do an amended commit via:
git commit --amend -m 'merge completed successfully'
If you now inspect your commit history via git log
, you will notice that the number of commits is the same as when you first completed the merge. But the latest commit is not the same as the first merge commit. Rather, it is a completely new commit with a new SHA-1 hash.