Labs/Jetpack/FlightDeck/Code Workflow/Management Commands

From MozillaWiki
< Labs‎ | Jetpack‎ | FlightDeck‎ | Code Workflow
Revision as of 09:28, 22 July 2010 by Zalun (talk | contribs) (release branches added)
Jump to navigation Jump to search

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-577738-update_Bespin git@github.com:john/FlightDeck.git -f
 git checkout branch-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 bug-1234-name_of_the_bug

And delete the branch from your local repository

 git branch -d bug-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

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