In order to release a new version of an application, it is required to combine branching and tagging techniques.
Release Pull Request
Check out a release branch from the
developbranch. Naming for the branch should follow the pattern
Open a pull request with the release branch as origin and the
mainbranch as destination. Naming for the pull request should follow the pattern
Release - <version number>e.g.
Release - 1.0.0.
The description of the pull request must abide by this template:
On the first line, include the link to the GitHub milestone or the release on the project management tool to make it easier for reviewers to get the complete requirements:
# Github milestone https://github.com/nimblehq/git-templates/milestone/41?closed=1 # Clubhouse https://app.clubhouse.io/acme/label/12345
- Features: provide the list of features in the release.
- Chores: provide the list of chores in the release.
- Bugs: provide the list of bugs fixes in the release.
Once the pull request is approved and the test suite has run successfully, merge the release branch.
Once code is merged into the
main branch, we keep track of versions by using git tags.
Add a tag locally corresponding to the version released from the
git tag -a 1.0.0.
Add a changelog in the commit message for the tag following this convention when entering the interactive mode:
- List changes as a bullet point list
Group changes into sections for each issue type:
Features - [ch682] As a user I can view the list of job positions (#125) - [ch683] As a user I can view the details of a job position (#128) Bugs - [ch688] Fix: Login with LinkedIn (#126) Chores - [ch678] Set up staging environment (#127)
Having the pull request ID is preferred but not compulsory. On Github, the ID is parsed and linked to the pull request making is useful.
Push the newly added tag to the remote with
git push --tags.