This article demonstrates common problems which software development teams face when developing Java applications with Apache Maven and Git Flow and also how these problems can be easily resolved by the Maven Flow project.
Setup Demo Project
The article will use a demo library project on GitHub. For better understanding, I highly recommend that you setup the project and follow along.
Create a fork of the demo project in your GitHub account. When creating the fork, make sure you uncheck the “Copy the develop branch only” option, as we will need all the repository branches:
Feature Branch Conflicts
When you view the repository branches, you can see that in addition to main and develop, there are 3 feature branches and 1 release branch:
Create a pull request from branch feature/add-banana into develop. When creating the pull request, make sure you choose your fork as the base repository (and not the original repository from maven-flow):
Now create pull requests the same way for the other 2 feature branches.
If we review the pull requests, we can see that all of them can be merged without any conflicts. Let’s go ahead and merge the pull request for adding a banana.
After the merge, we can review the other 2 pull requests, and we see that they cannot be merged anymore, because there is a conflict in the changelog file:
This is because all the feature branches are trying to edit the same changelog section:
Normally we would have to resolve this conflict manually, but who wants to do that when Maven Flow can do it for us automatically?
We will see how Maven Flow solve this in a moment, but first let’s have a look at another problem, this time with the release branch.
Release Branch Conflicts
Going back to the repository branches, we can see that we have a release branch named release/1.0, which also needs to be merged into develop.
So let’s create a pull request for this branch as well. Again, don’t forget to select your fork and not the original maven-flow repository.
If we review this pull request, we can see that in addition to the changelog file, we also have a conflict in pom.xml. This is because the project version has been bumped both in develop and the release branch:
Luckily, Maven Flow can resolve this problem for us as well.
Maven Flow To The Rescue!
Now that we have shown the typical merge problems with Git Flow and Maven, we can demonstrate how Maven Flow solves them.
The demo project contains preconfigured GitHub actions which use Maven Flow. We just have to enable them.
Got to the “Actions” section in your forked repository and click the big green button to enable GitHub actions.
Merging Feature Branches
First we will resolve the merge conflict in the cranberry feature branch. Select workflow “MF Merge from Develop”, click on “Run workflow”, select feature/add-cranberry in “Use workflow from” and click the green “Run workflow” button:
After the workflow finishes, we can review the cranberry pull request again, and see that the changelog conflict has been resolved! We can now merge the pull request, so let’s do it.
Now we can go to the pull request for feature/add-dragon-fruit and we can see that there are also no more conflicts. That’s because Maven Flow resolved for us automatically!
So how did this happen? Well, let’s look at the actions tab:
When we merged feature/add-cranberry into develop, workflow “MF Maven Build” was executed. This workflow is configured to run on every push. Inside the workflow, there is a step which finds all feature pull request that are opened, and merges the changes from develop into the feature branches.
So in the current setup, all changes in develop are automatically merged into all opened feature pull requests with changelog conflicts resolved. For a detailed description of how the conflict resolution works, see documentation of the maven-flow/merge GitHub action.
We can now easily merge the dragon fruit pull request.
Merging Release Branches
Last thing we need to do is to merge release/1.0 into develop. If we check the pull request, we can see there are still ugly conflicts in changelog and pom.xml.
But this is not a problem, because workflow “MF Maven Build” also has a step named “Merge Release to Develop” which is executed when the workflow runs on a release branch. So every bug fix commited into a release branch will automatically be merged into develop with changelog and pom.xml conflicts resolved.
Since in this example we did not commit anything into the release branch, we have to run the workflow “MF Maven Build” on release/1.0 manually.
Final Result
After successfully merging everything, we can review the state of the develop branch.
If we look at the changelog file (CHANGELOG.md), we can see that all the project versions have been added in the same order as they were released. On top of the changelog is version 1.1.0, which is the currently being developed. It contains all the changes we have merged and the changes are in the exact same order as we merged them:
Leave a Reply