Git branching

gistfile1.txt

Notes from - http://nvie.com/posts/a-successful-git-branching-model/

The main branches  
    master
    develop

Supporting branches
    Feature branches
    Release branches
    Hotfix branches

Feature branch
  May branch off from: develop
  Must merge back into: develop
  Branch naming convention: anything except master, develop, release-*, or hotfix-*

Creating a feature branch
  $ git checkout -b myfeature develop
  Switched to a new branch "myfeature"
  
Incorporating a finished feature on develop
  $ git checkout develop
   Switched to branch 'develop'
  $ git merge --no-ff myfeature
   Updating ea1b82a..05e9557
   (Summary of changes)
  $ git branch -d myfeature
   Deleted branch myfeature (was 05e9557).
  $ git push origin develop
  
The --no-ff flag causes the merge to always create a new commit object, even if the merge could be performed with a fast-forward. This avoids losing information about the historical existence of a feature branch and groups together all commits that together added the feature. Reverting a whole feature is easier done wiht --no-ff flag set.

Release branches
  May branch off from: develop
  Must merge back into: develop and master
  Branch naming convention: release-*
  
  Release branches support preparation of a new production release. They allow for last-minute dotting of i’s and crossing t’s.
  
  $ git checkout master
   Switched to branch 'master'
  $ git merge --no-ff release-1.2
   Merge made by recursive.
   (Summary of changes)
  $ git tag -a 1.2
  
To keep the changes made in the release branch, we need to merge those back into develop, though. In Git:
   $git checkout develop
    Switched to branch 'develop'
   $git merge --no-ff release-1.2
    Merge made by recursive.
    (Summary of changes)
   $ git branch -d release-1.2
    Deleted branch release-1.2 (was ff452fe).
    
Hotfix branches
  May branch off from: master
  Must merge back into: develop and master
  Branch naming convention: hotfix-*
  
When a critical bug in a production version must be resolved immediately, a hotfix branch may be branched off from the corresponding tag on the master branch that marks the production version.

Creating hotfix branches
 Hotfix branches are created from the master branch. For example, say version 1.2 is the current production release running live and causing troubles due to a severe bug. But changes on develop are yet unstable. We may then branch off a hotfix branch and start fixing the problem:
 
 $ git checkout -b hotfix-1.2.1 master
  Switched to a new branch "hotfix-1.2.1"
 $ ./bump-version.sh 1.2.1
  Files modified successfully, version bumped to 1.2.1.
 $ git commit -a -m "Bumped version number to 1.2.1"
  [hotfix-1.2.1 41e61bb] Bumped version number to 1.2.1
  1 files changed, 1 insertions(+), 1 deletions(-)
  $ git commit -m "Fixed severe production problem"
   [hotfix-1.2.1 abbe5d6] Fixed severe production problem
   5 files changed, 32 insertions(+), 17 deletions(-)
   
Finishing a hotfix branch
  $ git checkout master
  Switched to branch 'master'
  $ git merge --no-ff hotfix-1.2.1
  Merge made by recursive.
  (Summary of changes)
  $ git tag -a 1.2.1
  
  Next, include the bugfix in develop, too:
  $ git checkout develop
  Switched to branch 'develop'
  $ git merge --no-ff hotfix-1.2.1
  Merge made by recursive.
  (Summary of changes)
  
  The one exception to the rule here is that, when a release branch currently exists, the hotfix changes need to be merged into that release branch, instead of develop. 
  Finally remove the temporary branch:
  $ git branch -d hotfix-1.2.1
  Deleted branch hotfix-1.2.1 (was abbe5d6).