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.

  • How can I fix a local out of date error with git?
  • Cannot edit code in netbeans when managing merge conflict in a file
  • Failed Xcode Git Merge is stuck
  • Git: can't commit a file even though I've resolved the conflict
  • How to resolve Deleted merge conflict in TortoiseGit?
  • How to merge code and resolve conflicts more easily using git?
  • 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?

  • How to show git status info on the right side of the terminal?
  • git merge local with remote master using terminal
  • The latest commit gone after hard reset
  • How do I merge changes without pulling from a GIT repository?
  • Github API for Python : PyGithub - get a list of all commits for a particular repository
  • Best practice for maintaining updated Git binaries (Git by Git) on Mac OS X 10.5?
  • 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.

    Git Baby is a git and github fan, let's start git clone.