CODEWITHSUNDEEP
gitmergegit-merge
Horaland
Horaland

Reputation: 907

Git destructivly mergeing

I've just started using GIT with a new company and imported the latest dev version of the project (v1.4) as the initial commit. I've been happily branching the project to add new features when my Boss produced v1.3 which has been developed in isolation to v1.4 so contains features not in 1.4.

So I need to add 1.3 into GIT and merge it int the master.

Obviously 1.3 is lacking all the new 1.4 code and 1.4 is lacking the new 1.3 code.

I branched the master and called the branch 1.3, then copied the 1.3 files into the branch and committed it.

I thought merge should be non-destructive so If I merge 1.3 into the master it will either merge nicely or more likely give me loads of conflicts that I can resolve manually. What is is actually doing is deleting any new code from the branch that I am mergeing into so if I merger 1.3 into master I loose all the new 1.4 code in the master files and if I merge master into 1.3 I loose all the new 1.3 code.

So in the master I have a load of common code and 2 new functions added in 1.4 called new14function() and anotherNew14Function(). IN the 1.3 branch I don't have those functions but I do have a new13Function() that isn't in the master. When I merge 1.3 into master it deletes the new14function() and anotherNew14Function() functions. What I want is the master to contain ew14function(), anotherNew14Function() and new13Function().

What am I doing wrong and how do I get it to combine the 2 files without destroying the content of one of the branches?

Upvotes: 0

Views: 42

Answers (1)

David Deutsch
David Deutsch

Reputation: 19045

OK, so since 1.3 was never under source control, you will indeed have a lot of merge conflicts - in fact, any difference in any file will be a merge conflict. What you need to do is create a branch with no parent, and copy the 1.3 code into it, and then merge that branch into master (or whatever). To do this, use git checkout --orphan v1.3.

Again, this is assuming that the 1.3 code was never under source control. If instead the developer of the 1.3 code started with a copy from commit X, you should start your v1.3 branch from X. This will save you some conflicts.

The reason why your approach did not work is that you branched from a commit that was after your code and the 1.3 code actually diverged, so git thinks that all the changes since then have been in the 1.3 branch (with none being in the main/1.4 branch), so the 1.3 branch "wins".

Upvotes: 1

Related Questions