GIT -- gitflow的maven插件（gitflow-maven-plugin）

参考：https://github.com/aleksandr-m/gitflow-maven-plugin
maven如何引入插件，详见上面的参考地址

用法：

命令	说明
mvn gitflow:release-start	Starts a release branch and updates version(s) to release version.
mvn gitflow:release-finish	Merges a release branch and updates version(s) to next development version.
mvn gitflow:release	Releases project w/o creating a release branch.
mvn gitflow:feature-start	Starts a feature branch and optionally updates version(s).
mvn gitflow:feature-finish	Merges a feature branch.
mvn gitflow:hotfix-start	Starts a hotfix branch and updates version(s) to hotfix version.
mvn gitflow:hotfix-finish	Merges a hotfix branch.
mvn gitflow:support-start	Starts a support branch from the production tag.
mvn gitflow:help	Displays help information.

分支模型详见博客：http://blog.csdn.net/gaopeng0071/article/details/78773499

以上的maven操作，都可以增加参数，来达到快捷方便的效果。如下
mvn -DpushRemote=true -DallowSnapshots=false gitflow:release-start
- DpushRemote：true的时候自动push到远端仓库
- DallowSnapshots：true的时候，允许创建的分支中存在*-SNAPSHOT的jar存在。
- DskipTestProject=true：跳过单元测试

---

如下目标参数引用官网的介绍

• The gitflow:release-finish, gitflow:release and gitflow:hotfix-finish goals have skipTag parameter. This parameter controls whether the release/hotfix will be tagged in Git. The default value is false (i.e. the release/hotfix will be tagged).

• The gitflow:feature-start goal has skipFeatureVersion parameter which controls whether the feature name will be appended to the project version or not. The default value is false (e.g. if the project version is 1.0.0-SNAPSHOT and feature name is feature_name then after the execution it will be 1.0.0-feature_name-SNAPSHOT).

• The gitflow:feature-start goal has featureNamePattern parameter which allows to enforce naming of the feature branches with a regular expression. Doesn’t have effect if it isn’t set or left blank. By default it isn’t set.

• All -finish goals have keepBranch parameter which controls whether created support branch will be kept in Git after the goal finishes. The default value is false (i.e. the supporting branch will be deleted). If the pushRemote parameter is set to true and keepBranch is false remote branch will be deleted as well.

• All -finish goals and gitflow:release have skipTestProject parameter which controls whether Maven test goal will be called before merging branches. The default value is false (i.e. the project will be tested before merging branches).

• All release goals have allowSnapshots parameter which controls whether SNAPSHOT dependencies are allowed. The default value is false (i.e. build fails if there SNAPSHOT dependency in project).

• The gitflow:release-finish and gitflow:release goals have digitsOnlyDevVersion parameter which will remove qualifiers from the next development version if set to true. For example, if the release version is 1.0.0-Final then development version will be 1.0.1-SNAPSHOT. The default value is false (i.e. qualifiers will be preserved in next development version).

• The gitflow:release-finish and gitflow:release goals have developmentVersion parameter which can be used to set the next development version in non-interactive mode.

• The gitflow:release-finish and gitflow:release goals have versionDigitToIncrement parameter which controls which digit to increment in the next development version. Starts from zero. For example, if the release version is 1.2.3.4 and versionDigitToIncrement is set to 1 then the next development version will be 1.3.0.0-SNAPSHOT. If not set or set to not valid value defaults to increment last digit in the version.

• The gitflow:release-start and gitflow:release-finish have commitDevelopmentVersionAtStart parameter which controls whether the next development version is set and committed at start or after finish. By default the value is false which means that the next development version is set on the development branch after the release branch has been merged onto the development branch when finishing the release. This has the benefit of being able to easily cancel the release process simply by deleting the release branch. If the value is true then versioning happens on gitflow:release-start. First the project version is set to the release version on the development branch and the release branch is created. Then the development branch is set to the next development version. This allows the development branch to continue immediately with a new version and helps avoid any future merge conflicts related to project versioning. Has effect only when there are separate development and production branches.

• The gitflow:release-start goal have fromCommit parameter which allows to start the release from the specific commit (SHA).

Remote interaction

At the start of the each goal remote branch(es) will be fetched and compared with the local branch(es). If the local branch doesn’t exist it will be checked out from the remote. Both of these options can be turned off by setting fetchRemote parameter to false.

At the end of the -finish goals development or production and development branches will be pushed to remote. This can be turned off by setting pushRemote parameter to false.

At the end of the -start goals newly created branch (release / feature / hotfix) can be pushed to the remote. This can be achieved by setting pushRemote parameter to true.

The default remote name is origin. It can be customized with custom_origin configuration in pom.xml.