Merge a branch to another branch

I’m new, and just tested this. You are right… and I’m sorry that I can’t upvote this to a bug.

Use case; the lead developer is planning a big database upgrade, and splits MAIN. The team decides to do smaller bug fixes/updates. In the overworking hours, the lead developer wants to merge the TEAM branch back into his LEAD branch, solve the conflicts, and merge the result into the TEAM branch, to be save he also remerges the MAIN branch into his branch, and that all to update MAIN to his LEAD branch in the next weekend.

If you can’t do this you end in a lockdown situation; you can’t merge as you would create merge conflicts for others to solve, and that is not allowed. 

We’ve discussed this idea - there is a good possibility that this is feasible if a shared origin version can be found between the two versions.

Given the following diagram:

Merging HOTFIX_N to FEATURE_X would use MAIN as origin.

This means all changes that have been done between MAIN and FEATURE_X will be compared to all changes between MAIN and HOTFIX_N.

After merging HOTFIX_N to both MAIN and FEATURE_X, it will appear to subsequent merges that these actions have been done in both branches. This may result in some conflicts of duplicate actions being performed. Usually, these are automatically resolved.

Merging FEATURE_X to FEATURE_Y would use DEVELOP as origin.

This means all changes that have been done in FEATURE_X will be compared to all changes that have been done in FEATURE_Y.

Merging FEATURE_Y to HOTFIX_N would use MAIN as origin.

Executing this merge would include all changes that have been done in FEATURE_Y compared to MAIN. This is not limited to changes done in the branch. This includes changes that may have been done before branch creation. For instance in DEVELOP or RELEASE. If only a single column was added to FEATURE_Y, the merge to HOTFIX_N may include a lot more. After all, this single column may be added to a table that does not yet exist in MAIN and HOTFIX_N but was added in DEVELOP.

Would this solution cover this idea?

Hi @Anne Buit ,

Faced same issue as above, would definetly need such Merging capability. Upvoting the idea.

thanks

Mike

Hi @J. de Lange,

Would this solution cover this idea?

@Anne Buit @Mark Jongeling Since @J. de Lange is on a long holiday break, I’ll answer on his behalf: as far as I can tell this is exactly what we would want!

We’ve been in the situation too often where we’re developing on 2 different Releases (each having their own Release Branch and their respective Develop/Feature branches) and at some point we’d conclude that we needed functionality from one another. However, having to merge incomplete Releases to the Main for this purpose was not always desirable or feasible.

Now, what I understand from the examples from Anne, this scenario would be resolved since the 2 Releases share the same Main and all changes since will be merged without impacting the Main itself at that point in time.

@Anne Buit why wouldn’t your solution cover the Idea? Is there a caveat/what are the disadvantages of your solution?

The only real caveat is as follows:

When merging FEATURE_X to FEATURE_Y, it will not only merge the changes done in FEATURE_X to FEATURE_Y, but it will also include any changes done in DEVELOP as marked by the orange delta.

This might be unexpected - when you merge FEATURE_X to FEATURE_Y, you might expect only to merge the set of changes done in the source branch, in FEATURE_X.

This is unfortunately not possible as this can cause integrity problems. For instance, in FEATURE_X, a column might have been added to a table that was added in DEVELOP after FEATURE_Y was branched but before FEATURE_X was branched.

This impact is magnified the further the distance is to the shared origin.

@Anne Buit That shoulds like desired behavior to me! Since both of the Feature branches are from the same origin branch, we would definitely want to have all changes merged. We're eager to see this feature coming.