Git merge didn't merge two files only?
I have master branch, and a release branch. Last commit on the release branch added couple lines to files, let’s say, A and B. Then these changes were merged into master (things happen).
Later, number of other commits were made to master, one of which removed those couple lines from A and B again.
- Partial squash-merge
- git: merge back in what I merged out
- git pre-merge (via pre-commit) hook to identify if files in a specific directory have changed
- Git Fast-Forward Merge requires a pull first
- Git npm version management during the development flow
- Merge/Branch Strategy
Now I merge master into release. Everything merges fine (except for couple minor conflicts), but files A and B left unchanged with those several lines present.
How could this happen? I can checkout the commit on release branch before the merge and repeat it again with the same result. Any commands/switches to understand what’s happening during the merge?
It seems I’m just doing something wrong, but I don’t understand how to do it properly. I can replicate the issue very easily, and it seems it’s happening because the ‘bad’ line was first added on master, then removed, and them master merged into release, where ‘bad’ line was also present. So the two commits from master ‘annihilated’, and release left unchanged, right?
So, what I’m doing:
7aee9be is release with ‘bad’ line
84d7ed2 is master before all the changes, older than above
Now I checkout 84d7ed2, add ‘bad’ line, commit (on a new test branch).
Then I remove ‘bad’ line, commit.
So test branch doesn’t have the ‘bad’ line anymore.
Then I checkout 7aee9be and merge test branch into it. ‘bad’ line is back, and the merge commit doesn’t have any changes at all.
2 Solutions collect form web for “Git merge didn't merge two files only?”
It is all about the common ancestor (in a 3-way merging):
If, when doing the final merge (of test, with no bad line) to release (with bad line), the “bad line” was introduced in release after the common ancestor, then the merge would not remove it.
Since that common ancestor:
releasehas introduced the bad line
testhas introduced and then removed the bad line
release won’t remove the bad line in
release in that case: compared to the common ancestor,
test introduces no changes, while
release does. The changes from
release are preserved.
I would start with
git bisect to find out where did the problem started. Once you have the “bad” commit check it out and start track from that point to find out what went wrong. (since something did go wrong in your case)
There are several options:
- Someone did a rebase so your commits are overwritten (not likely but its still an option, since if someone has done rebase most likely that you would have known about it. your branch could become unusable)
- Someone has pushed the “old” code with the force flag
git push origin master --forcewhich will result in overwriting the old code
- When you pulled (pull = fetch+merge) you had a conflict and you resolved it by leaving the lines in place so now they will be checked in again.
As i suggested try to figure out when it all started with the help of
git bisect. Once you figure out what went wrong it will be much easier to resolve it.