It would be great to have something similar to the Advanced Merge feature with SVN in the new Git world in Mendix.
We have a very large application servicing multiple lines of business in various states of test and deployment. Having an advanced merge feature and being able to cherry-pick commits in bulk made deployments between environments a lot easier. Now, we have to merge our commits one by one, which takes a long time and is much harder to keep track of now with the Git hash instead of the revision number in the history.
Are there any plans to bring this feature back for Git? Or to easily integrate with 3rd party Git tools to handle this?
Hi Tom, thank you for your answer.
To clarify: in our branching strategy we create a feature branch from the main line, which is then merged back into three target branches: dev, accp, and main.
Because we have three target branches that can each be in a different phase of development, it’s not feasible to first merge dev, accp, or main back into the feature branch. Doing so would risk introducing unrelated logic into branches where it does not belong—for example, pulling in dev changes into accp via the feature branch.
Also, using merge feature branch in this way means we’re resolving conflicts between dev and a feature branch based on an older version of main. The comparison is made against an older main line. This often results in conflicts in areas unrelated to the user story, and resolving these conflicts carries the risk of mistakenly reintroducing deleted logic or overwriting newer changes in dev. The risk reverses: you might unintentionally overwrite newer fixes in dev when resolving conflicts against your older base and if something was removed from dev after your feature branch was cut, resolving conflicts incorrectly can bring that outdated logic back.
For these reasons, this approach isn’t a workable solution for us, which makes cherry-picking the only safe option. Bulk cherry-picking is essential—it’s a standard Git capability that becomes critical for large and complex Mendix apps where multiple engineers collaborate across different release phases.
Thank you for your input as well, Niels. We have learned from multiple customers that there is a need for bulk cherry-picking, and I'll add your feedback to that.
Regarding your last remark:
> However, merging a feature branch can unintentionally bring back deleted logic or microflows, since it compares the feature branch (which is based on an older main and does not include the latest changes from dev) with dev. Cherry-picking is the only safe way to ensure we don’t reintroduce outdated logic or accidentally remove newer changes.
The "safe way" in Git to prevent reintroducing deleted logic or other outdated changes when merging a feature branch is to regularly update your feature branch with the latest changes from the target branch before merging the feature branch.
Although I understand that with cherry-picking you can also avoid this problem, it requires manual overhead (having to exactly know which commits to pick), loses some historical information (as new commits are created when cherry-picking) and is in general not deemed scalable for larger teams.
Having said that, we may still choose to offer this option as it's a part of some people's preferred workflow. But until we have that, perhaps 'merging your feature branch back regularly' could be the solution for you to solve that issue.
Totally agree with Rory. For large and complex Mendix applications with multiple engineers collaborating, the current setup without bulk cherry-picking is really inefficient — merging changes takes far too long.
In our case, we use a branching strategy with dev, accp, and main lines. For each US/feature, we branch from main, develop in the feature branch, and then merge back individually into dev (peer review, regression checks, conflict resolution), accp (acceptance testing), and main (production).
However, merging a feature branch can unintentionally bring back deleted logic or microflows, since it compares the feature branch (which is based on an older main and does not include the latest changes from dev) with dev. Cherry-picking is the only safe way to ensure we don’t reintroduce outdated logic or accidentally remove newer changes. Bulk cherry-picking would save significant time and reduce risk in this workflow — just like we used to have in SVN.
By GIT a developer sees all commits of own branch in history of main branch. This creates an ambiguous situation. It is better to see only commits to main branch.
No one update this?