We decided to use GIT in our company but now got a problem.. We have several bra开发者_高级运维nches 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)
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.
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.
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.
精彩评论