0

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?

Improve this question
4
  • You say that you copied the files from 1.3 into your new branch; was the 1.3 work not done on a branch in the first place? Commented Feb 2, 2016 at 15:45
  • No I've just started at the company and introduced GIT. 1.4 was the development version of the product and I didn't know 1.3 wasn't part of it until I was given it 2 months after starting. 1.3 had been single developer no source control. Commented Feb 2, 2016 at 15:48
  • Please try to draw an ASCII art image of the situation (as with git log --graph --all --oneline). I'm not getting it. Commented Feb 2, 2016 at 15:51
  • added a new paragraph of description on what is happening and what I want. Commented Feb 2, 2016 at 16:00

1 Answer 1

Reset to default
1

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

Improve this answer
Sign up to request clarification or add additional context in comments.

1 Comment

This did solve the problem. It gave me fare more merge conflicts than I can handle with the merge tools I'm using but it did solve the destructive merge issue. Thanks.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.