Labs/Jetpack/FlightDeck/Code Workflow/Management Commands

This article is inspired by A successful Git branching model.

Main branches

• master
• trunk

master

We use master branch for development commits. That's the place where we will merge bug-#- hotfix-#- and release- branches.

trunk

Production branch. It is used to export code for production sites. That's the place where we will merge hotfix-#- and release- branches only.

Supporting branches

• bug-#-
• release-
• support-
• hotfix-#-

bug-#-

1. May branch from: master
2. Must merge back to: master

Branch naming convention: bug-1234-name_of_the_bug where 1234 is the number of the bug in bugzilla

These branches are used to develop new features for the upcoming or a distant future release. This branch exists for the time of development of this topic only. It's goal is to be merged back into master

workflow

Pull the bug-#- branch from developer john

 git remote add -t bug-1234-name_of_the_bug john-1234-name_of_the_bug git@github.com:john/FlightDeck.git -f
 git checkout john-1234-name_of_the_bug

Now it's possible to test if the feature is working. If so - merge it into the master

 git checkout master
 git merge --no-ff john-1234-name_of_the_bug

And delete the branch from your local repository

 git branch -d john-1234-name_of_the_bug

Push the master to the main repository

 git push main master

release-

1. May branch off from: master
2. Must merge back into: master and trunk
3. Branch naming convention: release-1.0a3 where 1.0a3 is the target production version

Release branches are created after the code is frozen. They support preparation of a new production release. They allow for minor last-minute bugfixes. By doing all of this work on a release branch, the master branch is cleared to receive features for the next release.

workflow

Branch off from master

 git checkout -b release-1.0a3

Set version inside the settings and then commit the changes

 vi flightdeck/settings.py
 git commit flightdeck/settings.py -a "Bumped to version number 1.0a3"

After the release is ready, merge into the production branch

 git checkout production
 git merge --no-ff release-1.0a3

Tag the version

 git tag -a 1.0a3

Push the changes to main repository

 git push main production

To keep the changes made in the release branch, we need to merge those back into master

 git checkout master
 git merge --no-ff release-1.0a3

If this would lead to a conflict resolve it and commit. Release branch is not needed anymore, delete it

 git branch -d release-1.0a3

support-

1. May branch off from: hotfix-#-
2. May branch into: hotfix-#-
3. Branch naming convention: support-1.0a3 where 1.0a3 is a version of the production

Support branches are created to support old production version. Sometimes a fix for an old version is not compatible with the current production version. We will merge the hotfix into the support branch and tag it with the new version number.

workflow

There has to be a hotfix branch created after the release was already merged into production

 git remote add -t hotfix-1234-name_of_the_hotfix john-1234-name_of_the_hotfix git@github.com:john/FlightDeck.git -f

If there is no support branch for the release - create it from a first hotfix

 git checkout -b release-1.0a3 john-1234-name_of_the_hotfix

else - merge the hotfix into support branch

 git checkout release-1.0a3
 git merge --no-ff john-1234-name_of_the_hotfix

change the version to 1.0a3.1

 vi flightdeck/settings.py
 git commit flightdeck/settings.py -m "Bumped version number to 1.0a3.1"
 git tag -a 1.0a3.1
 git push main release-1.0a3 --tags