4

Is it possible to merge at step 4 without conflict?

  1. cherry-pick commit 'E' from branch1 to branch2

     branch1 : A - B - C - D - E
                 \
 branch2 :         F - G - E(cherry-pick from 1)

  2. The commits are added to branch2

     branch1 : A - B - C - D - E
                \
 branch2 :         F - G - E - H - I

  3. Rebase interactively and squash commits because they are the solution to the same problem.

    (Now, I think it was bad decision...)

     branch1 : A - B - C - D - E
                \
 branch2 :        F - G - I'

  4. Cherry-pick squashed commit again to branch1...

    (Would it be better to cherry-pick commit H, I to branch1?)

     branch1 : A - B - C - D - E - I'(conflict?)
                 \
 branch2 :         F - G - I'
YoungJinAn
  • 53
  • 5

1 Answers1

1

This is an interesting question, but nobody will be able to provide a definitive answer unless you were to provide the actual git repository so the changesets could be examined.

The fact that there is a merge conflict has nothing to do with whether commits H and I are cherry picked individually or are rebased together. The fact that E got squashed as well might be a factor.

More importantly, though, is a small problem with the premise of the question. "Is it possible to merge without conflict?" Why does this merge need to happen without conflict? It's probably correct and appropriate for there to be a conflict.

When git says "there's a conflict", that does NOT mean "you messed up, these can't be merged." Rather, it means "I (git) can't figure out how these changes should be merged. I need human help."

Here's the solution: Get some good diff/merge software (I use P4Merge on Windows, but there are lots of options). Examine the contents of each of the commits in question. Understand what the conflict is (most likely H or I changed a line that had been changed in E, or maybe H and I depend on changes that had already been made in F or G). Resolve each conflict: this may mean keeping the original line, or keeping the newer line, or modifying the line in a new way that incorporates changes from both branches - it's entirely context dependent.

Don't be afraid to consult with team members on conflict resolution - chances are you'll be deciding if some of their work is going to get erased.

thelr
  • 1,134
  • 11
  • 30
  • Thanks for the reply. As you said, if there is a conflict, i'll try to resolve it. However, i thought if i didn't squashed the commits, it's likely that no conflict has occured. But on the other hand , i thought small commits for the same goal make the branch difficult to manage unnecessarily. – YoungJinAn Jun 04 '20 at 12:55
  • I think the "best practice" for git is usually to tend towards frequent, small commits. If there is a conflict caused by the squashing, it is that you included E in the squash, then tried to cherry-pick it back. – thelr Jun 04 '20 at 13:11