Merge conflicts and incorrect version during feature-finish

[kennedyoliveira]

Hi everyone,

using this plugin in a project and my team are facing a problem with conflicts when finishing a feature, and also the version will be incorrect if not manually correct.

We use in the following way: We start a feature branch via mvn gitflow:feature-start and it's configured to change the version with the name of the branch, so assuming the develop is on 1.0.0-SNAPSHOT and the feature is my-feature we will end up with a branch 1.0.0-my-feature-SNAPSHOT.

When the development is done and we run mvn gitflow:feature-finish we get conflicts during the merge if the version on the develop changed, one example is when we have a release, if a feature started developing when the develop branch was on 1.0.0 and then we finish it when the develop is 1.1.0 then we get a conflict, and if we just consider our version while solving the merge, it will them override the version in the develop with our branch version. Considering our example, if we finish 1.0.0-my-feature-SNAPSHOT in a point in time that develop is on version 1.1.0-SNAPSHOT and we don't manually update our feature branch version, the plugin will use 1.0.0-SNAPSHOT instead of keeping the version in develop.

In our workflow we need that the feature branch have a different naming because they can be used by other projects and we need it for running CI, in this scenario what are the workaround to have the feature branches with different names and not manually merging to develop?

[aleksandr-m]

We can find some workaround for that, but... Usually features are merged before release and if not then why don't you update feature branch? There can be more conflicting changes in release than just version and you still need to bring any left feature branches up to date.

[vdenisov]

That's exactly the case - there's no way to cleanly merge develop back to a feature branch, unless we disable per-feature versioning (the only sane option is to cherry-pick the changes you need on a feature branch, but that's a lot of manual work and pretty error-prone). As for the reasons feature branches not being merged for release, there are many - a developer was blocked and temporarily switched to another feature; or the opposite - ran out of tasks for the sprint and took some from the backlog, etc. So yeah, setting a current development version on a feature branch, if it's different from the feature one, would be an awesome option.

[AdrienHorgnies]

While it's true that many LoC could be conflicting, the version is an easy one to fix: Always set the feature branch to develop branch's version before attempting the merge.

[aleksandr-m]

Let's use #238 to track this issue.