5

We decided to use GIT in our company but now got a problem.. We have several branches with different features. Now what we need is to merge that branches and push it to Master. How shall we do that with autoreplace - we have branch-a, branch-b, branch-c - we need to get them all in Master but in case of repeated files the branch-b should be Major and branch-c - minor.

Upd: 

branch-a:
-file1
-file2
-file3
-file4



branch-b:
-file1
-file5
-file6



branch-c:
-file1
-file2
-file7
-file8

we need in result: 

Master:
-file1 (from b)
-file2 (from a)
-file3 (from a)
-file4 (from a)
-file5 (from b)
-file6 (from b)
-file7 (from c)
-file8 (from c)
Khaled Annajar
  • 15,542
  • 5
  • 34
  • 45
Chvanikoff
  • 1,309
  • 3
  • 13
  • 21

3 Answers3

11

Perform an octopus merge and don't commit '--no-commit'. From master

git merge --no-commit branch-a branch-b branch-c

resolve any conflicts, then if as you want, take a specific version of a file and commit:

git checkout branch-b -- file3

repeat for other specific files.

git add . -A
git commit

This is the way your custom work-flow would work.

Hope this helps.

Adam Dymitruk
  • 124,556
  • 26
  • 146
  • 141
2

I haven't tested this, but this might do what you want:

git checkout master
git merge -s recursive -X theirs branch-c
git merge -s recursive -X theirs branch-a
git merge -s recursive -X theirs branch-b

This is using the recursive merge strategy, but saying that if there are any conflicts when merging, to always resolve them in favour of the branch you're merging into your current branch. To find the documentation for this, look at the section on the recursive merge strategy in the git merge man page, and the ours and theirs options to that strategy.

The problem with this is that if the changes you've made to the files in each branch don't conflict, you'll have some of the changes from one branch and one in the other. If that's not what you want (and I concede that I don't quite understand your workflow in the first place) you might have to do, for example:

git merge --no-commit branch-c

... and then update the index with each file version that you want manually before committing that merge commit. After running that command, you could find all the files which are present on both branches with:

comm -1 -2 <(git ls-tree -r --name-only master|sort) <(git ls-tree -r --name-only branch-c|sort) > common.txt

... and then pick the branch-c version for each one with:

xargs -n 1 git checkout branch-c -- < common.txt

... and then committing with git commit as usual.

Just to reiterate, I'm pretty sure I'd never want to do this - git's default merge behaviour almost always does what I want, only leaving genuine conflicts to resolve.

Mark Longair
  • 446,582
  • 72
  • 411
  • 327
  • theirs strategy has been deprecated because of loss of information potential. You need to do ours from the other side. But this poses a problem: the first parent on the merge commit reflects the wrong branch following – Adam Dymitruk Mar 16 '11 at 19:40
  • @adymitruk: My first downvote :( That **isn't** the `theirs` strategy, that's the `theirs` option to the `recursive` strategy, which is quite different and not deprectated - it's still in the current git master. – Mark Longair Mar 16 '11 at 19:56
  • ah thanks for the clarification. I can't unvote for another 43 mins :( – Adam Dymitruk Mar 16 '11 at 20:23
  • tried to reverse it.. now it says I can't again.. so there is a weird time window within which I can change my vote. Can't do it too early and now I can't do it because it's too late. SO fail. Sorry :( – Adam Dymitruk Mar 17 '11 at 01:34
  • @adymitruk: I think that's because after some time window you can't change a vote unless the answer has been edited. I've edited it now, but in any case don't worry about it - I'm not that bothered about the -2 :) – Mark Longair Mar 17 '11 at 08:16
0

file copy - a simple alternative

One way to do this would be to checkout the master branch. In separate repositories, checkout the minor and major branch files. Copy in the minor files and then the major files, so that the major files overwrite the minor files. Then commit the result.

The file copy will even simply allow you to decide on a case by case basis (if necessary) whether you really want the major file to overwrite the minor file or not, and a good file copy program will give you dates and filesizes of the files and possibly previews too, to help you make an informed decision.

This might not be the best way of doing things for your particular case. Just treat it as an extra tool in your toolbox. Of course, if merging is what you want to do, rather than just overwriting, then git is still the tool to use, helped along with a mergetool such as kdiff3.

Ivan
  • 4,383
  • 36
  • 27