THIS PAGE IS A WORKING DRAFT
	The page may be difficult to navigate, and some information on its subject might be incomplete and/or evolving rapidly. If you have any questions or ideas, please add them as a new topic on the discussion page.

This article is inspired by A successful Git branching model.

Main branches

• master (development)
• production

master

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

production

1. Must branch off from: release-

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
3. 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 production
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 --tags

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
 git push main master

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

hotfix-#-

1. May branch off from: production
2. Must branch back into: support or production
3. May branch back into: release and master
4. Branch naming convention: hotfix-1234-name_of_the_hotfix where 1234 is the bug number in bugzilla

Hotfix branches are very much like bug-#- branches, albeit unplanned. They are meant to prepare a production or support release. They arise from the necessity to act upon an undesired state of live production version. Hotfix branch may be branched off from the correspondind tag on the production branch that marks the production version.

Hotfix has to merge back into production (if it's relative to the current production version) or (else) into support- branch.

If the hotfix is sensible in the current development it may be merged to release or master branch.

workflow

Merge the remote hotfix branch production (or support)

 git remote add -t hotfix-1234-name_of_the_hotfix john-1234-name_of_the_hotfix git@github.com:john/FlightDeck.git -f
 git checkout production 
 git merge --no-ff john-1234-name_of_the_hotfix
 git tag -a 1.0a3.1
 git push main production --tags

Delete local branch after usage

 git branch -d john-1234-name_of_the_hotfix