Wukong branching model

Introduction

Here you will find the branching and commit rules we have defined for this project, if you are new to this project, please read through this page and remember to follow the rules the next time you are working on something for Wukong. Thanks.

Rule number one:

Push all your changes to develop branch, no matter which branch you were on last time, however remember to merge your changes to develop branch and push it to the remote server. Saying this means we are retiring the good ol' WukongMaster branch, so please don't develop on it anymore. I am pretty sure develop branch has all your past changes, so go ahead and switch to develop branch.

git commands to pull remote branch to local (create develop branch):

$ cd NanoKong
$ git checkout -b develop origin/develop

Rule number two:

master branch will contain all stable releases tagged by a version number, so every merge in master branch should come from develop branch or hotfix branches, which I will discuss it later. Please don't do it without notifying all of us in the mailing list first :x

Rule number three:

Do NOT develop on master branch and demo branch, please if you do, backup your changes and reset it. Demo branch should be separated from development and should only merge from master branch.

Rule number four:

If there is a severe bug found in master branch, create a hotfix branch, and merge to master branch AND develop branch once you are done, so remember to merge twice but to different branches. Don't forget to push your fix to github! It is important to keep in mind that developing directly on master branch should be prohibited! So if you accidentally does it on master, simply follow the commands below (don't follow them directly) and switch to the new branch:

$ git checkout -b hotfix#1
$ git add .
$ git add deletedFiles
$ git commit -m 'Commit'

Rule number five:

If you are creating hotfix branch for some bugs in master, please branch for ONE issue at once, that means every hotfix branch should only for one issue on github issue tracker. For example, if I need to create a branch for issue #3, I will create a branch from master called hotfix#3. Only changes relevant to this hotfix will be committed and pushed once you are done with the issue.

Rule number six:

If you are working on a huge feature that could potentially affect multiple components in the project, such as FBP, Master, Mapper, please create a feature branch for it, and name under the same rule as hotfix above, for example if issue #6 contains the description of the new feature, name the branch feature#6, and only commit relevant changes to the branch.

Rule number seven (optional):

Whenever you are working on some hotfix or feature in its respective branch, please squash all local commits before merging back to master branch or develop branch. Since it would be nice and clean if the commits for a particular feature or hotfix could be minimized. For example, you might be working on some issue, but you have 30 commits for it, wouldn't be nicer for others if you can repackage all those commits down into one commit to describe what you did in overview, so that other people will be able to know without having to look through all 30 commits. This technique is called rebase, it is an advanced git technique, so make sure you understand what you are doing before following this rule. If you want to know more about this please refer to (http://gitready.com/advanced/2009/02/10/squashing-commits-with-rebase.html)

inspiration (http://nvie.com/posts/a-successful-git-branching-model/)