{"id":13682509,"url":"https://github.com/aleksandr-m/gitflow-maven-plugin","last_synced_at":"2025-04-12T17:44:57.713Z","repository":{"id":16534037,"uuid":"19287338","full_name":"aleksandr-m/gitflow-maven-plugin","owner":"aleksandr-m","description":"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.","archived":false,"fork":false,"pushed_at":"2024-06-21T13:02:44.000Z","size":1753,"stargazers_count":500,"open_issues_count":59,"forks_count":185,"subscribers_count":23,"default_branch":"master","last_synced_at":"2025-04-03T19:15:57.036Z","etag":null,"topics":["git","git-workflows","gitflow","github-flow","java","maven","maven-plugin"],"latest_commit_sha":null,"homepage":"https://aleksandr-m.github.io/gitflow-maven-plugin/","language":"Java","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"apache-2.0","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/aleksandr-m.png","metadata":{"files":{"readme":"README.md","changelog":"CHANGELOG.md","contributing":null,"funding":".github/FUNDING.yml","license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null},"funding":{"github":"aleksandr-m"}},"created_at":"2014-04-29T18:35:29.000Z","updated_at":"2025-03-17T15:01:03.000Z","dependencies_parsed_at":"2023-12-25T12:51:31.454Z","dependency_job_id":"e3bcff01-aa9c-4bdd-a400-5c310f20535a","html_url":"https://github.com/aleksandr-m/gitflow-maven-plugin","commit_stats":null,"previous_names":[],"tags_count":35,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/aleksandr-m%2Fgitflow-maven-plugin","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/aleksandr-m%2Fgitflow-maven-plugin/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/aleksandr-m%2Fgitflow-maven-plugin/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/aleksandr-m%2Fgitflow-maven-plugin/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/aleksandr-m","download_url":"https://codeload.github.com/aleksandr-m/gitflow-maven-plugin/tar.gz/refs/heads/master","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":248609494,"owners_count":21132914,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["git","git-workflows","gitflow","github-flow","java","maven","maven-plugin"],"created_at":"2024-08-02T13:01:47.273Z","updated_at":"2025-04-12T17:44:57.690Z","avatar_url":"https://github.com/aleksandr-m.png","language":"Java","funding_links":["https://github.com/sponsors/aleksandr-m"],"categories":["Java"],"sub_categories":[],"readme":"# Git-Flow Maven Plugin\n\n[![verify](https://github.com/aleksandr-m/gitflow-maven-plugin/workflows/verify/badge.svg)](https://github.com/aleksandr-m/gitflow-maven-plugin/actions)\n[![Maven Central](https://maven-badges.herokuapp.com/maven-central/com.amashchenko.maven.plugin/gitflow-maven-plugin/badge.svg?subject=Maven%20Central)](https://maven-badges.herokuapp.com/maven-central/com.amashchenko.maven.plugin/gitflow-maven-plugin/)\n[![License](https://img.shields.io/badge/License-Apache%20License%202.0-blue.svg)](https://www.apache.org/licenses/LICENSE-2.0.html)\n\nThe Maven plugin that supports various Git workflows, including Vincent Driessen's [successful Git branching model](https://nvie.com/posts/a-successful-git-branching-model/) and [GitHub Flow](https://guides.github.com/introduction/flow/).\n\nCurrently a Java implementation of Git version control system [JGit](https://eclipse.dev/jgit/) doesn't support [`.gitattributes`](https://git-scm.com/book/en/Customizing-Git-Git-Attributes).\n\nThis plugin runs Git and Maven commands from the command line ensuring that all Git features work properly.\n\n## Changelog\n\nSee what's changed - [CHANGELOG](CHANGELOG.md)\n\n# Installation\n\nThe plugin is available from Maven Central.\n    \n    \u003cbuild\u003e\n        \u003cplugins\u003e\n            \u003cplugin\u003e\n                \u003cgroupId\u003ecom.amashchenko.maven.plugin\u003c/groupId\u003e\n                \u003cartifactId\u003egitflow-maven-plugin\u003c/artifactId\u003e\n                \u003cversion\u003e1.21.0\u003c/version\u003e\n                \u003cconfiguration\u003e\n                    \u003c!-- optional configuration --\u003e\n                \u003c/configuration\u003e\n            \u003c/plugin\u003e\n        \u003c/plugins\u003e\n    \u003c/build\u003e\n\n\n# Goals Overview\n\n- `gitflow:release-start` - Starts a release branch and updates version(s) to release version.\n- `gitflow:release-finish` - Merges a release branch and updates version(s) to next development version.\n- `gitflow:release` - Releases project w/o creating a release branch.\n- `gitflow:feature-start` - Starts a feature branch and optionally updates version(s).\n- `gitflow:feature-finish` - Merges a feature branch.\n- `gitflow:hotfix-start` - Starts a hotfix branch and updates version(s) to hotfix version.\n- `gitflow:hotfix-finish` - Merges a hotfix branch.\n- `gitflow:support-start` - Starts a support branch from the production tag.\n- `gitflow:version-update` - Updates version in release or support branch, optionally tagging and pushing it to the remote repository.\n- `gitflow:help` - Displays help information.\n\n\n# Git Workflows\n\nThe gitflow-maven-plugin is very versatile. It can be easily configured to use different Git workflows.\n\n## GitHub Flow\n\nThe GitHub Flow is a lightweight, branch-based workflow that supports teams and projects where deployments are made regularly.\n\nTo configure this plugin to use single branch model, such as GitHub Flow, just set the `developmentBranch` parameter to the same value as the `productionBranch` in your pom.xml file.\n\n    \u003cgitFlowConfig\u003e\n        \u003cdevelopmentBranch\u003emaster\u003c/developmentBranch\u003e\n    \u003c/gitFlowConfig\u003e\n\nThat's it!\n\n\n# Maven Wrapper support\n\nThe plugin will automatically use Maven Wrapper for internal Maven goals if plugin is started with the wrapper.\n\n\n# Internal Maven plugins\n\nThe `versions-maven-plugin` and `tycho-versions-plugin` are used internally to update versions and properties of the project. To change versions of internal plugins use `versionsMavenPluginVersion` and `tychoVersionsPluginVersion` properties respectively.\n\n### Handling multi-module projects\n\nIf your project consists of multiple modules with and without parent-child relationships, you have to supply additional arguments if you want to update all module versions. In case of the `versions-maven-plugin`, there is [`processAllModules`](https://www.mojohaus.org/versions-maven-plugin/set-mojo.html#processAllModules), which can be supplied as follows:\n\n```\nmvn gitflow:\u003cgoal\u003e -DargLine='-DprocessAllModules'\n```\n\n\n# Git Submodules\n\nThe plugin looks for the `.gitmodules` file and if it exists the `git submodule update` command will be executed before each Git commit. This is needed to avoid leaving working copy in dirty state which can happen when switching between branches.\nTo explicitly control whether Git submodules will be updated before commit the `updateGitSubmodules` parameter can be used. Setting it to `true` will enable Git submodules update and `false` will disable it even if `.gitmodules` file exists. The default value is not set, meaning the plugin tries to automatically determine if update is needed.\n\n\n# Eclipse Plugins build with Tycho\n\nSince version `1.1.0` this plugin supports Eclipse plugin projects which are build with [Tycho](https://eclipse.org/tycho/).\nTo enable this feature put `\u003ctychoBuild\u003etrue\u003c/tychoBuild\u003e` into `\u003cconfiguration\u003e` section of this plugin in your pom.xml file.\n\n### Features of `tychoBuild` \n\nThe [`tycho-versions-plugin`](https://eclipse.org/tycho/sitedocs/tycho-release/tycho-versions-plugin/plugin-info.html) Maven plugin will be used to set versions instead of [`versions-maven-plugin`](https://www.mojohaus.org/versions-maven-plugin/).\n\nFeature name will not be appended to project version on `gitflow:feature-start` goal even if the `skipFeatureVersion` is set to `false`.\n\nIf version has qualifier then it will not be removed in the release or hotfix goals.\n\n\n# Signing Your Work\n\nTo sign tags and/or commits you need to configure GPG and install personal key. Read more [Git Tools - Signing Your Work](https://git-scm.com/book/en/v2/Git-Tools-Signing-Your-Work).\n\nNext you need to configure Git to use your personal key.\n\n```\ngit config --global user.signingkey GPG_key_id\n```\n\nSometimes you need to tell Git where the GPG program is. Use `gpg.program` option for that.\n\n```\ngit config --global gpg.program \"path_to_gpg\"\n```\n\n### Signing Tags\n\nThe `gitflow:release`, `gitflow:release-finish` and `gitflow:hotfix-finish` goals have `gpgSignTag` parameter. Set it to `true` to sign tags with configured personal key. The default value is `false`.\n\n### Signing Commits\n\nAll goals have `gpgSignCommit` parameter. Set it to `true` to sign commits with configured personal key. The default value is `false`.\n\n\n# Support for Reproducible Builds\n\n[Reproducible builds](https://reproducible-builds.org/) are a set of software development practices that create an independently-verifiable path from source to binary code.\n\nTo configure your Maven build to support reproducible builds follow [official guide](https://maven.apache.org/guides/mini/guide-reproducible-builds.html).\n\nIf your project has `project.build.outputTimestamp` property this plugin will update its value whenever the versions are updated. \n\nThis can be disabled by setting the configuration parameter `updateOutputTimestamp` to `false`.\n\n\n# Plugin Common Parameters\n\nAll parameters are optional. The `gitFlowConfig` parameters defaults are the same as in the example below.\nMaven and Git executables are assumed to be in the PATH, if executables are not available in the PATH or you want to use different version use `mvnExecutable` and `gitExecutable` parameters.\nThe `installProject` parameter controls whether the Maven `install` goal will be called during the mojo execution. The default value for this parameter is `false` (i.e. the project will NOT be installed).\nSince `1.0.7` version of this plugin the output of the executed commands will NOT be printed into the console. This can be changed by setting `verbose` parameter to `true`.\n\n    \u003cconfiguration\u003e\n        \u003cmvnExecutable\u003epath_to_maven_executable\u003c/mvnExecutable\u003e\n        \u003cgitExecutable\u003epath_to_git_executable\u003c/gitExecutable\u003e\n\n        \u003cinstallProject\u003efalse\u003c/installProject\u003e\n        \u003cverbose\u003efalse\u003c/verbose\u003e\n\n        \u003cgitFlowConfig\u003e\n            \u003cproductionBranch\u003emaster\u003c/productionBranch\u003e\n            \u003cdevelopmentBranch\u003edevelop\u003c/developmentBranch\u003e\n            \u003cfeatureBranchPrefix\u003efeature/\u003c/featureBranchPrefix\u003e\n            \u003creleaseBranchPrefix\u003erelease/\u003c/releaseBranchPrefix\u003e\n            \u003chotfixBranchPrefix\u003ehotfix/\u003c/hotfixBranchPrefix\u003e\n            \u003csupportBranchPrefix\u003esupport/\u003c/supportBranchPrefix\u003e\n            \u003cversionTagPrefix\u003e\u003c/versionTagPrefix\u003e\n            \u003corigin\u003eorigin\u003c/origin\u003e\n        \u003c/gitFlowConfig\u003e\n\n        \u003ccommitMessages\u003e\n            \u003c!-- since 1.2.1, see Customizing commit messages --\u003e\n        \u003c/commitMessages\u003e\n    \u003c/configuration\u003e\n\n## Customizing commit messages\n\nSince `1.2.1` commit messages can be changed in plugin's configuration section in pom.xml. Commit messages defaults are seen below.\n\n    \u003cconfiguration\u003e\n        \u003ccommitMessages\u003e\n            \u003cfeatureStartMessage\u003eUpdate versions for feature branch\u003c/featureStartMessage\u003e\n            \u003cfeatureFinishMessage\u003eUpdate versions for development branch\u003c/featureFinishMessage\u003e\n\n            \u003chotfixStartMessage\u003eUpdate versions for hotfix\u003c/hotfixStartMessage\u003e\n            \u003chotfixFinishMessage\u003eUpdate for next development version\u003c/hotfixFinishMessage\u003e\n\n            \u003chotfixVersionUpdateMessage\u003eUpdate to hotfix version\u003c/hotfixVersionUpdateMessage\u003e\n\n            \u003creleaseStartMessage\u003eUpdate versions for release\u003c/releaseStartMessage\u003e\n            \u003creleaseFinishMessage\u003eUpdate for next development version\u003c/releaseFinishMessage\u003e\n\n            \u003creleaseVersionUpdateMessage\u003eUpdate for next development version\u003c/releaseVersionUpdateMessage\u003e\n\n            \u003c!-- git merge messages --\u003e\n            \u003c!-- Default git merge commit message will be used if left empty or undefined. --\u003e\n\n            \u003creleaseFinishMergeMessage\u003e\u003c/releaseFinishMergeMessage\u003e\n            \u003creleaseFinishDevMergeMessage\u003e\u003c/releaseFinishDevMergeMessage\u003e\n\n            \u003cfeatureFinishDevMergeMessage\u003e\u003c/featureFinishDevMergeMessage\u003e\n            \u003cfeatureSquashMessage\u003e\u003c/featureSquashMessage\u003e\n\n            \u003chotfixFinishMergeMessage\u003e\u003c/hotfixFinishMergeMessage\u003e\n            \u003chotfixFinishDevMergeMessage\u003e\u003c/hotfixFinishDevMergeMessage\u003e\n            \u003chotfixFinishReleaseMergeMessage\u003e\u003c/hotfixFinishReleaseMergeMessage\u003e\n            \u003chotfixFinishSupportMergeMessage\u003e\u003c/hotfixFinishSupportMergeMessage\u003e\n\n            \u003c!-- / git merge messages --\u003e\n\n            \u003ctagHotfixMessage\u003eTag hotfix\u003c/tagHotfixMessage\u003e\n            \u003ctagReleaseMessage\u003eTag release\u003c/tagReleaseMessage\u003e\n            \u003ctagVersionUpdateMessage\u003eTag version update\u003c/tagVersionUpdateMessage\u003e\n\n            \u003c!-- Migration Note: This was called \u003cupdateDevToAvoidConflitsMessage\u003e in version 1.11.0, but has been deprecated in favour of the correctly spelt one below. --\u003e\n            \u003cupdateDevToAvoidConflictsMessage\u003eUpdate develop to production version to avoid merge conflicts\u003c/updateDevToAvoidConflictsMessage\u003e\n            \u003cupdateDevBackPreMergeStateMessage\u003eUpdate develop version back to pre-merge state\u003c/updateDevBackPreMergeStateMessage\u003e\n            \n            \u003cupdateReleaseToAvoidConflictsMessage\u003eUpdate release to hotfix version to avoid merge conflicts\u003c/updateReleaseToAvoidConflictsMessage\u003e\n            \u003cupdateReleaseBackPreMergeStateMessage\u003eUpdate release version back to pre-merge state\u003c/updateReleaseBackPreMergeStateMessage\u003e\n            \n            \u003cupdateFeatureBackMessage\u003eUpdate feature branch back to feature version\u003c/updateFeatureBackMessage\u003e\n            \u003cfeatureFinishIncrementVersionMessage\u003eIncrement feature version\u003c/featureFinishIncrementVersionMessage\u003e\n            \n            \u003csupportStartMessage\u003eUpdate versions for support branch\u003c/supportStartMessage\u003e\n            \n            \u003cversionUpdateMessage\u003eUpdate versions\u003c/versionUpdateMessage\u003e\n        \u003c/commitMessages\u003e\n    \u003c/configuration\u003e\n\nMaven properties can be used in commit messages. For example `\u003cfeatureStartMessage\u003eupdating ${project.artifactId} project for feature branch\u003c/featureStartMessage\u003e` will produce message where \n`${project.artifactId}` will be substituted for projects `\u003cartifactId\u003e`.\n\nNote that although `${project.version}` can be used, any changes to version introduced by this goal won't be reflected in a commit message for this goal (see Custom properties).\n\nCommit messages can be prefixed by using `commitMessagePrefix` parameter. Leading or trailing whitespaces can be preserved by using `xml:space=\"preserve\"` attribute e.g. `\u003ccommitMessagePrefix xml:space=\"preserve\"\u003e[gitflow] \u003c/commitMessagePrefix\u003e`.\n\n### Custom properties in commit messages\n\n`@{version}` will be replaced with the updated version.\n\n`@{featureName}` will be replaced in `feature-` goals with the name of the current feature.\n\n## Maven arguments\n\nThe `argLine` parameter can be used to pass command line arguments to the underlying Maven commands. For example, `-DcreateChecksum` in `mvn gitflow:release-start -DargLine=-DcreateChecksum` \nwill be passed to all underlying Maven commands.\n\n## Maven CI friendly versions\n\nMaven property can be updated with the new version by setting the `versionProperty` parameter with the property you want to update.\nFor example, `-DversionProperty=revision` will update the `\u003crevision\u003e` property defined in the project pom.xml.\n\nThe `skipUpdateVersion` parameter can be used to skip updating `\u003cversion\u003e` in the pom.xml. The default value is `false` (i.e. the version will be updated).\n\nTo support [CI friendly versioning](https://maven.apache.org/maven-ci-friendly.html) in projects which use `\u003cversion\u003e${revision}\u003c/version\u003e` set `versionProperty` to `revision` and `skipUpdateVersion` to `true`.\n\n## Additional goal parameters\n\nThe `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.\nThe default value is `false` (i.e. the release/hotfix will be tagged).\n\nThe `gitflow:feature-start` goal has `skipFeatureVersion` parameter which controls whether the feature name will be appended to the project version or not.\nThe 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`).\n\nThe `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.\nBy default it isn't set.\n\nThe `gitflow:feature-finish` goal has `incrementVersionAtFinish` parameter which if set to `true` will increment version number during feature finish. The default is `false`.\n\nAll `-finish` goals have `keepBranch` parameter which controls whether created support branch will be kept in Git after the goal finishes.\nThe 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.\n\nAll `-finish` goals and `gitflow:release` have `skipTestProject` parameter which controls whether Maven `test` goal will be called before merging branches.\nThe default value is `false` (i.e. the project will be tested before merging branches).\n\nAll `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).\n\nThe `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.\nBy 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.\nThis has the benefit of being able to easily cancel the release process simply by deleting the release branch.\nIf 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.\nThen the development branch is set to the next development version.\nThis allows the development branch to continue immediately with a new version and helps avoid any future merge conflicts related to project versioning.\nHas effect only when there are separate development and production branches.\n\nThe `gitflow:release-start` goal has `sameBranchName` parameter which can be used to use the same name for the release branch. The default value is `false`.\nBy itself the default `releaseBranchPrefix` is not a valid branch name. You must change it when setting `sameBranchName` to `true`.\nWill have no effect if the `branchName` parameter is set.\n\nThe `gitflow:release-start` goal has `branchName` parameter which controls how the release branch will be named.\n\nThe `gitflow:release-start` goal has `fromCommit` parameter which allows to start the release from the specific commit (SHA).\n\nThe `gitflow:release-start` and `gitflow:release-finish` goals have `useSnapshotInRelease` parameter which allows to start the release with SNAPSHOT version and finish it without this value in project version. By default the value is `false`.\nFor example, if the release version  is `1.0.2` and `useSnapshotInRelease` is set to `true` and using `gitflow:release-start` goal then the release version will be `1.0.2-SNAPSHOT` and when finishing the release with `gitflow:release-finish` goal, the release version will be `1.0.2`\n\nThe `gitflow:release` and `gitflow:release-finish` goals have `skipReleaseMergeProdBranch` parameter which prevents merging the release branch into the production branch. The default value is `false`.\n\nThe `gitflow:release-finish` goal has `skipReleaseMergeDevBranch` parameter which prevents merging the release branch into the development branch. The default value is `false`.\n\nThe `gitflow:hotfix-start` and `gitflow:hotfix-finish` goals have `useSnapshotInHotfix` parameter which allows to start the hotfix with SNAPSHOT version and finish it without this value in the version. By default the value is `false`.\nFor example, if the hotfix version  is `1.0.2.1` and `useSnapshotInHotfix` is set to `true` and using `gitflow:hotfix-start` goal then the hotfix version will be `1.0.2.1-SNAPSHOT` and when finishing the release with `gitflow:hotfix-finish` goal, the release version will be `1.0.2.1`\n\nThe `gitflow:hotfix-finish` goal supports the parameter `skipMergeDevBranch` which prevents merging the hotfix branch into the development branch. \n\nThe `gitflow:hotfix-finish` goal supports the parameter `skipMergeProdBranch` which prevents merging the hotfix branch into the production branch and deletes the hotfix branch leaving only the tagged commit. Useful, along with `skipMergeDevBranch`, to allow hotfixes to very old code that are not applicable to current development.\n\nThe `gitflow:release-finish` and `gitflow:hotfix-finish` goals have `noBackMerge` and `noBackMergeHotfix` parameters respectively. They control which branch is merged to development branch. If set to `true` then release or hotfix branch will be merged to development branch. If set to `false` and tag is present (`skipTag` parameter is set to `false`) then tag will be merged. If there is no tag then production branch will be merged to development branch.\n\nThe `gitflow:release` goal has `noBackMerge` parameter, which controls which branch is merged to development branch. If set to `true` then merge will be skipped. If set to `false` and tag is present (`skipTag` is set to `false`) then tag will be merged. If there is no tag then production branch will be merged to development branch.\n\n### Versioning\n\nThe `gitflow:release-finish` and `gitflow:release` goals have `digitsOnlyDevVersion` parameter which will remove qualifiers from the next development version if set to `true`.\nFor example, if the release version is `1.0.0-Final` then development version will be `1.0.1-SNAPSHOT`.\nThe default value is `false` (i.e. qualifiers will be preserved in next development version).\n\nThe `gitflow:release-finish` and `gitflow:release` goals have `versionDigitToIncrement` parameter which controls which digit to increment in the next development version. Starts from zero.\nFor 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`.\nIf not set or set to not valid value defaults to increment last digit in the version.\n\nThe `gitflow:hotfix-start` goal has `hotfixVersionDigitToIncrement` parameter which controls which digit to increment in the hotfix version. Starts from zero.\n\nVersioninig can be controlled by using [Maven version policy](https://maven.apache.org/maven-release/maven-release-api/apidocs/org/apache/maven/shared/release/policy/version/VersionPolicy.html) implementation. Create appropriate implementation and add it as dependency to the project, use `projectVersionPolicyId` parameter to set policy id to use. If policy is set then other parameters controlling the generation of version are ignored (i.e. `digitsOnlyDevVersion`, `versionDigitToIncrement`).\n\nVersion update of all modules ignoring groupId and artifactId can be forced by setting `versionsForceUpdate` parameter to `true`. The default value is `false`.\n\n### Remote interaction\n\nAt 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.\nBoth of these options can be turned off by setting `fetchRemote` parameter to `false`.\n\nAt 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`.\n\nAt 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`.\n\nThe default remote name is `origin`. It can be customized with `\u003cgitFlowConfig\u003e\u003corigin\u003ecustom_origin\u003c/origin\u003e\u003c/gitFlowConfig\u003e` configuration in pom.xml.\n\nGit [push-options](https://git-scm.com/docs/git-push#Documentation/git-push.txt--oltoptiongt) can be added to push command with the `gitPushOptions` parameter. Multiple options can be added separated with a space e.g. `-DgitPushOptions=\"merge_request.create merge_request.target=develop merge_request.label='Super feature'\"`.\n\n### Rebase, Merge, Fast Forward, Squash\n\nRelease branch can be rebased instead of merged by setting `releaseRebase` parameter to `true`. The default value is `false` (i.e. merge will be performed).\n\nRelease branch can be merged without `--no-ff` option by setting `releaseMergeNoFF` parameter to `false`. The default value is `true` (i.e. `merge --no-ff` will be performed).\nThe `releaseMergeNoFF` parameter has no effect when `releaseRebase` parameter is set to `true`.\n\nRelease branch can be merged with `--ff-only` option by setting `releaseMergeFFOnly` parameter to `true`. The default value is `false` (i.e. The `--ff-only` option won't be used).\n\nFeature branch can be squashed before merging by setting `featureSquash` parameter to `true`. The default value is `false` (i.e. merge w/o squash will be performed).\n\n### Running custom Maven goals\n\nThe `preFeatureFinishGoals` parameter can be used in `gitflow:feature-finish` goal to run defined Maven goals before the finishing and merging a feature.\nE.g. `mvn gitflow:feature-finish -DpreFeatureFinishGoals=test` will run `mvn test` goal in the feature branch before merging into the development branch.\n\nThe `postFeatureFinishGoals` parameter can be used in `gitflow:feature-finish` goal to run defined Maven goals after merging a feature.\nE.g. `mvn gitflow:feature-finish -postFeatureFinishGoals=test` will run `mvn test` goal in the development branch after merging a feature.\n\nThe `preReleaseGoals` parameter can be used in `gitflow:release-finish` and `gitflow:release` goals to run defined Maven goals before the release.\nE.g. `mvn gitflow:release-finish -DpreReleaseGoals=test` will run `mvn test` goal in the release branch before merging into the production branch.\n\nThe `postReleaseGoals` parameter can be used in `gitflow:release-finish` and `gitflow:release` goals to run defined Maven goals after the release.\nE.g. `mvn gitflow:release-finish -DpostReleaseGoals=deploy` will run `mvn deploy` goal in the production branch after the release.\n\nThe `gitflow:hotfix-finish` goal has `preHotfixGoals` and `postHotfixGoals` parameters which can be used to run defined Maven goals before and after the hotfix respectively.\n\n# Non-interactive Mode\n\nMaven can be run in non-interactive (batch) mode. By using non-interactive mode goals can be run in continuous integration environment.\nTo put Maven in the batch mode use `-B` or `--batch-mode` option.\n\n## Non-interactive Release\n\nReleases could be performed without prompting for the release version during `gitflow:release-start` or `gitflow:release` goals by telling Maven to run in non-interactive (batch) mode.\nThe `releaseVersion` parameter can be used to set the release version in non-interactive mode. If `releaseVersion` parameter is not set then the default release version will be used.\n\n    mvn -B gitflow:release-start gitflow:release-finish\n    \nTo release w/o creating separate release branch use `gitflow:release` goal.\n\n    mvn -B gitflow:release\n\nThis gives the ability to perform releases in non-interactive mode (e.g. in CI server).\n\nThe `gitflow:release-finish` and `gitflow:release` goals have `developmentVersion` parameter which can be used to set the next development version in non-interactive mode.\n\n## Non-interactive Feature\n\nThe `gitflow:feature-start` and `gitflow:feature-finish` goals have `featureName` parameter which can be used to set a name of the feature in non-interactive mode.\n\nThe `gitflow:feature-finish` goal has `featureBranch` parameter which can be used to set feature branch name in non-interactive mode. It must start with the feature branch prefix. The `featureBranch` will be used instead of `featureName` if both are set.\n\n## Non-interactive Hotfix\n\nThe `gitflow:hotfix-start` goal has `fromBranch` parameter which can be used to set starting branch of the hotfix. It can be set to production branch or one of the support branches.\nIf it is left blank then hotfix will be started from the production branch.\n\nThe `gitflow:hotfix-start` and `gitflow:hotfix-finish` goals have `hotfixVersion` parameter which can be used to set version of the hotfix.\nIf it is left blank in `gitflow:hotfix-start` goal then the default version will be used.\n\nThe `gitflow:hotfix-finish` goal has `hotfixBranch` parameter which can be used to set hotfix branch name in non-interactive mode. It must start with the hotfix branch prefix. The `hotfixBranch` will be used instead of `hotfixVersion` if both are set.\n\n## Non-interactive Support\n\nThe `gitflow:support-start` goal can be run in non-interactive mode. Use `tagName` parameter to set tag from which supporting branch will be started.\nIf `tagName` is not set but the goal is running in non-interactive mode then the last tag will be used.\n\nThe `gitflow:support-start` goal has `supportBranchName` parameter which can be used to set branch name to use instead of the default.\n\nThe `gitflow:support-start` goal has `useSnapshotInSupport` parameter which allows to start the support with SNAPSHOT version.\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Faleksandr-m%2Fgitflow-maven-plugin","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Faleksandr-m%2Fgitflow-maven-plugin","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Faleksandr-m%2Fgitflow-maven-plugin/lists"}