Multiple features developed in parallel and git merging at once

Question

Having such a situation in git graph:

dev *
     \_ featureA 
      \_ featureB

and I requested merges for each of the features to the dev branch. Both features are developed in parallel and are going to be merged in the same time.

The merge request of the branch featureA has been accepted and now when my colleague wants to merge featureB he sees merge conflict because in CMakeLists.txt in the root directory both of the features add a line in the file at the same place; in featureA:

CMakelists.txt:10:
    add_subdirectory(featureA)

in featureB:

CMakelists.txt:10:
    add_subdirectory(featureB)

The question is should he resolve this merge conflicts by hand or should I rebase the branch featureB locally and then repush the branch or maybe there is something wrong in the workflow and other approach should be taken when having such a situation?

Both solutions are correct. I'd use merge for such situation. — Michał Walenciak, Jun 07 '18 at 10:07
Rebasing won't necessarily result in fewer conflicts. There could be fewer or greater conflicts. For a conflict as small as this, what is wrong with resolving it by hand? — Tim Biegeleisen, Jun 07 '18 at 10:09

score 3 · Accepted Answer · answered Jun 07 '18 at 14:10

Let me preface by saying that there is no right or wrong solution here — the way you handle a merge conflict like this depends on what kind of branch featureB is.

Option 1: rebase if `featureB` is a private branch

If featureB is a private branch – meaning you're the only one committing to it – then I'd suggest you rebase it on top of dev after featureA has been merged.

That means going from this:

A--B---M dev
 \    /
  C--D featureA
   \
    E--F featureB

To this:

A--B---M dev
 \    / \
  C--D   E--F featureB

Keep in mind that rebasing is still a kind of merge, the difference being that git-rebase applies one commit at a time on top of the previous one, while git-merge merges two commits with their entire set of changes in a single operation.

Doing a rebase forces you to solve the conflict at the commit that introduced the conflicting change. This has a couple of advantages:

It gives you more context around the change, thus making it easier to find a resolution.
The resolution will become part of the commit itself – where it belongs – instead of ending up in a merge commit, potentially mixed up with other unrelated conflict resolutions.

Option 2: merge if `featureB` is a public branch

If, however, featureB is a public branch – that is, multiple people commit to it, then you can't rebase it because that would be rewriting history. In that case, you're better off handling the merge conflict in a regular merge on the dev branch.

The resulting history will then look something like this:

A--B---M------N dev
 \    / \    /
  C--D   E--F featureB

where N is where you resolve the conflict.

Multiple features developed in parallel and git merging at once

1 Answers1

Option 1: rebase if featureB is a private branch

Option 2: merge if featureB is a public branch

Option 1: rebase if `featureB` is a private branch

Option 2: merge if `featureB` is a public branch