Resolving conflicts in a team with a big project
I’m interested in learning the best way to resolve conflicts in a big team.
For example I have a master branch in which the team has made quite a lot of changes and then I’m rebasing latest changes from the upstream (master and upstream are not connected). And I got conflicts. The problem is that somebody in the team knows better how to solve conflicts in one file and some other knows better about the other.
So the question is: is it possible to push unresolved branch to remote wait until colleagues resolve conflicts in their local environments and push them back and then make git rebase –continue.
And if not what is the best way to solve this problem?
2 Solutions collect form web for “Resolving conflicts in a team with a big project”
The short answer is no, you cannot push a conflicted merge.
The slightly longer answer is that merging takes place in (and via) git’s index (also called the staging area). The index has a dual role, of acting as a staging area for the next commit, and also as a cache to speed up scanning the work tree. For merge purposes the cache aspect can mostly be ignored.
In the index, every entry that corresponds to a work-tree file has up to four “slots” (at most three of which are in use), called stages:
- Stage 0 is a normal, unconflicted file.
- Stage 1 is the common ancestor version of a conflicted file;
- Stage 2 is the “target branch” version (basically the version from the branch you’re on as you do the merge); and
- Stage 3 is the “merge branch” version (from the branch you’re trying to merge).
If a file has no conflicts, stages 1-3 are empty; if a file has a merge conflict, stage 0 is empty, and some or all of slots 1-3 are populated (depending on the particular merge conflict, some may be empty, e.g., perhaps the conflict is “both created” in which case there’s no common ancestor, or perhaps it is “modified by them but removed by us” in which case there’s no stage-2 entry).
To mark a file as resolved, you
git add or
git rm its path; this removes the stage 1-3 entries and puts in a stage 0 entry (for
git rm the stage 0 entry is “this file is to be gone once we make a commit”).
When making a new commit, git transforms the staging area into a set of “tree” objects that will describe all the files that go in that commit. To make trees from the staging area, it can only have stage-0 entries; only those entries go into the tree.
When you use
git push or
git fetch, you transfer commits between repositories. Only whole commits (and their trees and other related objects) are transferable this way. Hence a conflicted, in-process merge, which happens in the index and uses stages 1-3, cannot be transported across machines. This is a fundamental design limitation of git as it is implemented today.
Git works so that your server must never be in conflict.
If on your local project you have conflicts on one file when you pull remote new commits, it’s because you changed this file. So you are the person who knows how to solve conflicts.
That’s why git wants you to solve conflicts before push on server.