Git Flow hooks

This repository contains git hooks for git flow to help deploy releases and hotfixes in my go, nodejs repositories.

Here are some sample repositories for GitHub, BitBucket, and GitLab:

• gitflow-pr-sandbox on GitHub,
• gitflow-pr-sandbox on BitBucket,
• gitflow-pr-sandbox on GitLab,

Pre-Requisites

The hooks from this repository will work only with git flow AVH Edition. The basic git-flow does not handle git hooks. Make sure to install the proper version!

The version of the target repository is assumed to follow the semver specifications.

Installation

First, you should git clone this project.

Then, from its folder, you just run the deployment script, pointing it at the target repository:

./hook-it /path/to/repo

On Windows:

.\hook-it.ps1 -Path /path/to/repo

The Bash script supports the -v switch to display more information and the -n switch to see what would be executed. Check the script's help with ./hook-it -h.

The PowerShell script support the -Verbose switch to display more information and the -WhatIf switch to see what would be executed. Check the script's help with Get-Help .\hook-it.ps1.

The script will check if the repository is valid and has git-flow already, if not it will try to initialize it in the repository.

The script also checks if your installed git-flow is the AVH edition, and stops if it is not the case.

Configuration

By default, the hooks will prevent you from:

• committing anything to the master branch
• committing anything that has unresolved merge conflicts
• force Pull Request usage

In case you do not want either of these features, you can turn them off with:

git config --bool gitflow.allow-master-commit true
git config --bool gitflow.allow-conflict-commit true
git config --bool gitflow.use-pull-request false

You can also change the prefix used to tag the new release/hotfix (default is "v"):

git config gitflow.prefix.versiontag v

When using Pull Requests, if the origin is on GitHub, the scripts will rely on the Github's CLI (gh) and will fail if the tool is not present.

If the origin is on BitBucket, the scripts will rely on the Bitbucket's CLI (bb) and will fail if the tool is not present. You can configure which Bitbucket profile is used in your git config (git config bitbucket.cli.profile myprofile)

If the origin is on GitLab, the scripts will reply on the GitLab's CLI (glab) and will fail if the tool is not present.

The scripts will also bump the Helm Chart version if it is present. You can configure the location of the chart with:

git config gitflow.path.chart path/to/chart

The default location is: chart/

You can turn off the chart feature with:

git config --bool gitflow.bump-chart false

The scripts will also update the OCI annotations (version and created) in the Dockerfile if present.

You can turn off the Dockerfile feature with:

git config --bool gitflow.bump-dockerfile false

You can also change the default name and location of the Dockerfile:

git config gitflow.path.dockerfile path/to/Dockerfile

The scripts will also bump the Appveyor version if it is present.

You can turn off the Appveyor feature with:

git config --bool gitflow.bump-appveyor false

Usage

Once the hooks are initialized, everything can be done in the target repository folder.

Starting a new release can be done simply:

git flow release start xxx

Similarly, starting a hotfix can be done as follows:

git flow hotfix start xxx

Where xxx is the new version you are releasing/hotfixing, it is mandatory. If xxx is one of major, minor, patch, the scripts will bump the corresponding component of the current version (from the repository code) according to the semver recommandations.

For example, if the current version is 1.2.3:

• major will update the version to 2.0.0
• minor will update the version to 1.3.0
• patch will update the version to 1.2.4

The scripts will also commit the bumped files.

Depending on the language, the scripts will bump the following files:

• version.go in Go (or any file that contains the line: var VERSION = "1.2.3");
• package.json in Node.js;

If you use Pull Requests, you should publish the release once to create a Pull Request:

git flow release publish

As indicated in the command line result instruction, while merging the Pull Request, the approver should not delete the release branch.

When the release is ready, simply finish it:

git flow release finish

Note: The finish process will fail if there is no Pull Request (asuming you use the Pull Request usage feature) or the current Pull Request has not been properly merged.

Examples:

git flow release start 12.3.4

git flow release start major

You do not need to repeat the version when finishing the release/hotfix if you are on their branch.

As stated earlier, if the repository has a "chart" folder, the scripts will update the "appVersion" accordingly as well. They will also bump the chart version according to the same rules used for the application version.

Hooks Update

Whenever there is an update to this repository, simply re-run the hook-it script to update the target repositories.

TODO

The hooks should log their work and maybe display some nicer progress.

Maybe having some in-repository code that would allow the hooks to update to the current version of this repository.

Acknowledgments

Thanks to Peter van der Does and Jasper N. Brouwer for their git flow hooks examples (resp. petervanderdoes/gitflow-avh, jaspernbrouwer/git-flow-hooks) that inspired me.

Of course, we wouldn't have any git flow without Vincent Driessen and his inspiring blog post A successful Git branching model about 10 years ago...