Michael de Silva's Blog

Software Engineer. Rubyist and Roboticist.

Michael de Silva's Blog

Software Engineer. Rubyist and Roboticist.

Extending nvie's Successful Git Branching Model

Recently I've been working on a project where certain devs are not privvy to client-specific details, and this aspect has lead to a rather interesting build workflow.

As such, devs are only able to build debug specific Android releases, and release type releases for debugging purposes. However, actual release-builds require certain changes to the specific app Gradle config, and this is why I am maintaining a dedicated release branch alongside dev. It should be noted, that the release branch was infact a fork of dev.

This workflow is based on the excellent Successful Git branching Model by nvie and cutting a release has a couple extra steps.

-> % git co dev
-> % git co -b release-0.1.7
Switched to a new branch 'release-0.1.7'

-> % mvim CHANGELOG.md

-> % git st
## release-0.1.7
M  CHANGELOG.md
M  MyApp/app/build.gradle

-> % git c "Bump version for release"
[release-0.1.7 032e3c2] Bump version for release
 2 files changed, 9 insertions(+), 2 deletions(-)

# For this particular workflow, we maintain a branch called `release`, originally a fork of `dev`.
# 
# The `release` branch contains release specific details, that we do not wish to share with rest
# of the team, such as specific Gradle configs etc.

-> % git co release
Switched to branch 'release'
Your branch is up-to-date with 'bitbucket/release'.

-> % git co -b prep/release-0.1.7
Switched to a new branch 'prep/release-0.1.7'

# Here we merge our release changes into the dedicated `prep/release` branch.

-> % git merge --no-ff release-0.1.7

# This is where we create the final build, and merge this back to `release` with any changes.

-> % git co release
Switched to branch 'release'
Your branch is up-to-date with 'bitbucket/release'.

-> % git merge --no-ff prep/release-0.1.7

-> % git b -d prep/release-0.1.7
Deleted branch prep/release-0.1.7 (was 425f5f6).

# Finish the release, by merging back to master.

-> % git co master
Switched to branch 'master'
Your branch is up-to-date with 'origin/master'.

-> % git merge --no-ff release-0.1.7
-> % git tag -a v0.1.7 -m "Release v0.1.7"

# Merge any changes in the release back to dev.

-> % git co dev
Switched to branch 'dev'
Your branch is up-to-date with 'origin/dev'.

-> % git merge --no-ff release-0.1.7
Merge made by the 'recursive' strategy.
 CHANGELOG.md             | 7 +++++++
 MyApp/app/build.gradle | 4 ++--
 2 files changed, 9 insertions(+), 2 deletions(-)

-> % git b -d release-0.1.7
comments powered by Disqus