Search code examples
gitgitlabsquashgit-squash

How to perform sporadic merging of one branch into another

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
Solution

  • 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).