aleksandr-m / gitflow-maven-plugin

The Git-Flow Maven Plugin supports various Git workflows, including GitFlow and GitHub Flow. This plugin runs Git and Maven commands from the command line.
https://aleksandr-m.github.io/gitflow-maven-plugin/
Apache License 2.0
493 stars 181 forks source link

Avoiding version update direct commit on develop / master #226

Closed sndmails2arun closed 4 years ago

sndmails2arun commented 4 years ago

Few of the teams I work with has put in restrictions on their repo to reject any direct commits on the develop and master branches , and allow only merge commits to be pushed to remote.

So when I do feature-finish for eg. , if the feature version in pom is 1.0-feature1-SNAPHOT , it merges that in to develop, then update the version in develop to 1.0-SNAPSHOT with another commit. For us this commit would be rejected by our remote repo since it is not a merge commit. I am not sure if there was a specific reason for doing it this way.

Possible solution: If the commit to update the version is is done on the feature branch , and then it merges to develop, the end result will be same but just with a merge commit. So the logic would be , feature-finish > check current develop version and copy it > change the version on feature branch and commit > checkout develop > merge feature branch and commit

aleksandr-m commented 4 years ago

One downside of this is when the feature branch is kept after finish then version in it will be w/o feature name. Ideas?

sndmails2arun commented 4 years ago

Yea you are right. I did't think about that use case. I can think of couple of solutions

  1. If keepBranch flag is True, at -finish stage, check out a temp branch from the feature branch (say feature/my_awesome_feature_merge), update the develop's pom version into it, and then merge to develop. Leave the feature branch as is.
  2. Have this new flow available only if the keepBranch is False. If the flag is on, continue the existing logic. I feel this is not a good solution with this messy logic in code.
  3. Make the develop branch version update on the current feature branch, merge to develop. After that if the keepBranch flag is True, update the version on the feature branch back to its version and commit to the feature branch.
  4. Don't care to change the current behavior. If teams has restrictions on repo, that needs to be removed and implement some other audit mechanism to avoid accidental commits on the branch.
aleksandr-m commented 4 years ago

@sndmails2arun Same here :+1: . Implemented the 3. Thanks for reporting and possible solutions!

sndmails2arun commented 4 years ago

👍Thank you very much. You are awesome ! 👍

aleksandr-m commented 3 years ago

@sndmails2arun 1.15.0 is out!