Welcome to OStack Knowledge Sharing Community for programmer and developer-Open, Learning and Share
Welcome To Ask or Share your Answers For Others

Categories

0 votes
1.2k views
in Technique[技术] by (71.8m points)

git - Resolve merge conflict only for some files and commit to branch for other teams to resolve theirs

In short, we have one repo which hosts code for different functional teams, i.e. server-side, mobile, ci, automation qa etc.

Now when we are trying to pull down from support-branch bug fixes into dev-release-branch a lot of conflicts appear related to different teams/areas of development. Since we don't have single person covering server-side and mobile, it's really tough to resolve conflicts for one individual.

The question here is: is it possible somehow to resolve only some of the conflicts (e.g. server-side), then push to intermediate branch, and let other teams resolve conflicts related to their area of development. And only after all teams resolve all the conflicts finally merge intermediate branch.

Maybe we are doing something wrong here. Any suggestions would be appreciated (except splitting code base into separate repo, too late for this).

See Question&Answers more detail:os

与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…
Welcome To Ask or Share your Answers For Others

1 Answer

0 votes
by (71.8m points)
git checkout -b server-team-merge dev-release-branch
git merge support-team-fixes
# fix the conflicts you can fix here
git commit -m "server-team partial merge of $(git describe support-team-fixes)"

and each other team does likewise. Then merge the partial-merge branches -- if the results were truly disjoint you can do them all at once, it'll be a trivial operation,

git checkout dev-release-branch
git merge {server,mobile,ci,automation}-team-merge

but if that complains merge them in one at a time to ferret out the different ideas about how some of the conflicts should be resolved.

When you merge a branch, git regards the result as a correct and complete merge of the merged history in the resulting commit, so any subsequent merge will identify the entire history as shared and there'll be nothing left to do. But if you do multiple independent merges from the same parents, those merges aren't in each others' histories and can have any results you want; in subsequent merges of those results Git can see the commits' ancestry and identify the correct base.


与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…
Welcome to OStack Knowledge Sharing Community for programmer and developer-Open, Learning and Share
Click Here to Ask a Question

...