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?
Thank you for your feedback Desiree. The comments and number of votes don't go unnoticed.
Can I ask you to please register a ticket for the remark about losing work when rebasing? This is something we'll definitely want to investigate.
> We already confirmed that with rebase changes can get lost entirely (this is reproducible completely if you want the test scenario)
The merging with Git has become very complicated. We already confirmed that with rebase changes can get lost entirely (EDIT: Seems this got resolved in 10.24.9 at least with the scenario I tried before or it's because our git history has changed in the mean time) and with merge you still have a lot of conflicts with (like Niels says) things that should be unrelated to the story but that Mendix cannot properly recognize...
We really miss advanced merge with multiple revisions and we are honestly just wasting so much time for a process that needs to exist. You need to be able to differentiate between what is allowed to go to a test environment, an acceptance environment and what to a production environment. Feature flags are not sufficient to solve this as there's simply circumstances where you need to change already existing logic where flags are not always a proper solution.
We've tried multiple ways of working but it all comes down to that a lot of conflicts arise because you cannot merge topdown basically. So you merge to seperate branches which Mendix cannot recognize as 'being the same', and that I get, however that means one way or the other you have to deal with a lot of extra work that is all solved with bringing back advanced merge of multiple revisions (cherry pick git basically of multiple revisions).
So please give this a proper place on your roadmap!
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?