1

I develop on a branch dev and every couple of weeks want to merge the current state into a branch staging. It seems I didn't think this through enough, because now that I want to do this for the second time I get a conflict, since the last common ancestor is still from when I split dev off -- and the first difference was added to staging in a separate commit.

I used a gitlab merge request in both cases, with the squash commits box checked.

Is my approach inherently wrong and I need to switch to something different, or is there a way to make it work?

As a picture: The v_0.2 merge fails. What I want is to do is a cherry pick of features 5-7, and I had hoped that gitlab would understand that since I had already merged features 1-4. But it doesn't.

enter image description here

As console output: ffc9a2c Is both branch's last common parent (apparently, the merge that happened there put that commit properly as the new parent), after which I started the merging scheme I described above. You can see staging in its entirety from that point onwards. I omitted most of dev, since it's just really long.

git log from staging:
*   5ac9823 Merge branch 'dev' into 'staging'
|\  
| * 50bac27 Code update for v1.rc0.0
|/  
*   5f38284 Merge branch 'dev' into 'staging'
|\  
| *   ffc9a2c Merge branch 'formatting_fix' into 'dev'


git log from dev:
*   176971e Merge branch 'doctest_fix' into 'dev'
|\  
| * 4f0a423 Fix bug for doctest in filters.py
.
.
.
*   945d9ab Merge branch 'return_codes' into 'dev'  # v1.rc0.0 took place here
|\  
| * aed6133 Replace return codes 
.
.
.
|  
*   ffc9a2c Merge branch 'formatting_fix' into 'dev'
|\  
| * 0451416 Improving Error Message Quality
kowsky
  • 12,647
  • 2
  • 28
  • 41
Arne
  • 17,706
  • 5
  • 83
  • 99
  • I think your problem might be the `squash commits` box. You did not merge the commits `feature_1` to `feature_4` directly, but a new, squashed commit that introduces the same changes. The `v_0.2` merge now has conflicts since you try to merge another squashed commit, partly introducing the same changes. Can you show an actual graph of your repository, like `gitk` or `git log --graph` shows it? – kowsky Apr 04 '18 at 09:58
  • I'll try to append the relevant logs from staging and dev. The thing is, I might do hotfixes on staging that won't be in dev, so I can't assume that their hashes can be the same. Will that not be a problem? And if it isn't why should a squashed commit be? – Arne Apr 04 '18 at 10:05

1 Answers1

1

Your problem is the squash commits box. You did not merge the commits feature_1 to feature_4 directly, but a new, squashed commit that introduces the same changes. The v_0.2 merge now has conflicts since you try to merge another squashed commit, partly introducing the same changes.

From gits perspective, when you try to merge dev into stable with v_0.2, there are changes on the same files in stable that are not on dev (from the squashed merge commit) as well as changes in dev that are not on stable (new changes as well as changes from feature_1 to 4, since these commits are not part of stables history, only the changes have been introduced).

I think the best solution here would be not so squash the changes from dev when merging them to stable. You could also solve this via merging stable into dev or rebasing dev on stable, but this would make things even more confusing.

The hashes do not have to be the same; it is no problem to deploy hotfixes on staging and not taking them to develop (from a git perspective. In terms of a clean workflow, it's at least questionable to fix something and not merge it back to develop).

kowsky
  • 12,647
  • 2
  • 28
  • 41
  • Alright, I'll try your suggestion and report back if it works. I am a bit sad that squashing won't work though, reverting changes on staging would be a lot easier if its history only included version updates and hotfixes. – Arne Apr 04 '18 at 11:01
  • I see your point there. There are controversial opinions on squashing (as can be seen [here](https://stackoverflow.com/questions/41139783/gitflow-squash-commits-when-merging-from-develop-to-master#41298098)). I'm not entirely sure these conflicts cannot be prevented otherwise; your workflow only seems to be problematic when `feature_5,6,7` touch the same files as `feature_1..4`. – kowsky Apr 04 '18 at 11:08
  • Setting `merge.conflictstyle diff3` (see [here](https://stackoverflow.com/questions/27417656/should-diff3-be-default-conflictstyle-on-git)) helps to unterstand what is going on: when I recreate your case, it shows different changes in HEAD and `dev`, while the merged common ancestor is empty. Since different things were added on both branches in the same place, a conflict is inevitable. – kowsky Apr 04 '18 at 11:26
  • I tested your approach and could recreate your results. Thanks for your help and time =) – Arne Apr 04 '18 at 13:37