-
-
Notifications
You must be signed in to change notification settings - Fork 2
Release Workflow Steps
If you're not working on a release-related branch you might rather want to look at the workflow step by step page.
When it’s time to prepare a new release we create a new release branch. This creates a new branch release/1.1
.
Open Git Gui, select Tools-->Release-->Start. As argument pass the name of the release: 1.1
Alternatively on the command line:
$ git flow release start 1.1
Note: Before anyone can submit changes on this branch for code review on Gerrit, someone in Gerrit’s Administrator group needs to create the release/1.1
branch on Gerrit (Branch Name: release/1.1
, Initial Revision: develop
).
To share a release branch so that others can contribute, you can publish the release branch. This pushes the branch release/1.1
to the remote repo.
Open Git Gui. If necessary switch to the release branch (Branch-->Checkout), then select Tools-->Release-->Publish.
Alternatively on the command line:
$ git flow release publish 1.1
Note: Depending on the permissions in Gerrit publishing a release might not be possible until an administrator first creates the release branch in Gerrit (Branch Name: release/1.1
, Initial Revision: develop
).
If someone else already started a release branch and you want to join development on the release branch, you need to track the release branch on the remote repo. This pulls the branch release/1.1
from the remote repo and sets it up as tracking branch.
Open Git Gui, select Tools-->Release-->Track. As argument pass the name of the release: 1.1
Alternatively on the command line:
$ git flow release track 1.1
Then work on any necessary bug fixes in the release branch. When your changes are ready for code review push them to Gerrit. (If you get an error message “remote rejected” then probably the release branch hasn’t been created in Gerrit.)
Open Git Gui, select Tools-->Release-->Submit for Code Review.
Alternatively on the command line:
(release/1.1) $ git review release/1.1
When you’re ready for release, the changes from the release branch need to be merged into the master
and develop
branches. First, make sure all pending changes for the release branch are either merged or abandoned in Gerrit. Then do the following:
Open Git Gui. If necessary switch to the Release branch (Branch-->Checkout), then select Tools-->Release-->Finish.
Alternatively on the command line:
(release/1.1) $ git release 1.1
This syncs the develop
and master
branches with the remote repo, merges release/1.1
into master
and develop
, creates a tag 1.1
on master
and eventually pushes the branches and tag to the remote repo.
Sometimes it is necessary to fix bugs for the latest already released version (1.1). The fixed version will be called 1.1.1. The expectation is that only few people work on this hotfix over a fairly short amount of time. Therefore we don’t create a separate branch on the remote repo. A hotfix is always for the latest released version.
Open Git Gui, select Tools-->Hotfix-->Start. As argument pass the name of the fixed version: 1.1.1
Alternatively on the command line:
$ git flow hotfix start 1.1.1
This will create a new branch hotfix/1.1.1
based on master
.
Then work on the bug fixes in the hotfix branch. When your changes are ready for code review push them to Gerrit:
Open Git Gui, select Tools-->Hotfix-->Submit for Code Review.
Alternatively on the command line:
(hotfix/1.1.1) $ git review master
When the hotfix is ready, the changes from the hotfix branch need to be merged into both master
and develop
:
Open Git Gui. If necessary switch to the Hotfix branch (Branch-->Checkout), then select Tools-->Hotfix-->Finish.
Alternatively on the command line:
(hotfix/1.1.1) $ git hotfin 1.1.1
This syncs the develop
and master
branches with the remote repo, merges hotfix/1.1.1
into master
and develop
, creates a tag 1.1.1
on master
and eventually pushes the branches and tag to the remote repo.
When it becomes necessary to fix a bug in an older released version, we can create a Support branch. For example suppose we recently released version 1.1 but then it’s decided that we also have to re-release 1.0 with a bugfix. The re-release will be 1.0.1.
The support branch will be named after the base version we’re fixing, so in this case support/1.0
. We base it on the tagged version 1.0
.
Open Git Gui, select Tools-->Support-->Start. As argument pass the name of the support branch (1.0) and the tag it is based on (1.0)
Alternatively on the command line:
$ git flow support start 1.0 1.0
This will create a new branch support/1.0
based on the tag 1.0
.
We also need to create a new branch in Gerrit for the support branch support/1.0
(Branch Name: support/1.0
; Initial Revision: 1.0
)
Then work on the bug fixes in the support branch. When your changes are ready for code review push them to Gerrit:
Open Git Gui, select Tools-->Support-->Submit for Code Review.
Alternatively on the command line:
(support/1.0) $ git review support/1.0
When the bugs are fixed and we can release a new version of 1.0, we have to tag the support branch and merge the changes onto the develop
branch.
Open Git Gui. If necessary switch to the Support branch (Branch-->Checkout), then select Tools-->Support-->Finish. Pass the name of the new version (1.0.1) as argument.
Alternatively on the command line:
(support/1.0) $ git supfin 1.0.1
This syncs the develop
branch with the remote repo, creates a tag 1.0.1
on the support/1.0
branch, merges support/1.0
into develop
, and eventually pushes the branches and tag to the remote repo.