Git Branching Best Practices

These best practices maybe adopted within a team setting, they have been adopted from the blog A Successful Git Branching Model by Vincent Driessen.
Of course you may tweak this model to fit your team setting.

Main and Develop Branches

Unlinke in SVN, branching in Git is encouraged and is a lot less painful.  In a typical project you will have your master branch where code that is published is kept, and develop where your development code lives that you will later merge into master prior to deployments.

Feature Branches

You create a feature branch for example feature-homepageslider if you wish to start a new peace of development.
Typically you would:

  1. Branch from develop:
    git checkout -b feature-homepageslider develop
  2. Merge back into develop:
    Note: The --no-ff flag causes the merge to always create a new commit object
    git checkout develop
    git merge --no-ff feature-homepageslider
  3. Delete feature branch once merged:
    git branch -d feature-homepageslider
    
  4. Push changes up to repo:
    git push origin develop

Release Branches

You create a release branch when you're ready to deploy numerous features / bugfixes.
Typically you would:

  1. Create a release branch:
    Note: You may make small changes such as changing the app version number (As shown by second line commit below) and may also commit small bug fixes which are discovered while creating the release branch, however major feature development should be avoided.
    git checkout -b release-1.2 develop
    git commit -a -m "Bumped version number to 1.2"
  2. Merge release into master:
    git checkout master
    git merge --no-ff release-1.2

  3. Tag release:
    Note: Commits on master must be tagged for easy reference.
    git tag -a 1.2
  4. Merge into develop:
    Note: This is required so that future releases also contain these bug fixes.
    git checkout develop
    git merge --no-ff release-1.2
  5. Remove release branch:
    git branch -d release-1.2

Hotfix Branches

You create a hotfix branch when you're ready to deploy bug fixes.
Typically you would:

  1. Create a hotfix branch:
    git checkout -b hotfix-1.2 master
    git commit -a -m "Bumped version number to 1.2.1"
  2. Apply fix and commit:
    git commit -a -m "Fixed server configuration bug"
  3. Merge hotfix back into master:
    git checkout master
    git merge --no--ff hotfix-1.2.1
  4. Tag release:
    git tag -a 1.2
  5. Merge hotfix back into develop:
    git checkout develop
    git merge --no--ff hotfix-1.2.1
  6. Remove hotfix branch:
    git branch -d hotfix-1.2.1

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