Git is pretty permissive how you use it but it is good to have some guidelines how branches should be used in your project or organization. Here is the basic branching model I use:

Each team member should know how branches are used in the project.

• Branches are used for new features, fixes, ideas, etc.
• Shared master branch should always contain production ready code.
• To make a branch compatible with latest master, use git merge master. This should be done if feature branch has been separated from the master for long time.
• To ship a feature, use git merge --no-ff feature. --no-ff ensures that there will always be a merge commit. These merge commits give all kind of useful information.

Each team member should know how the project is released. When you release something, tag that version.

1.2.3
1 = Major version, may break relating systems when increased.
2 = Basic releases.
3 = Small fixes made after the release.

You have two main branches: develop and master. develop is used for the development and all new features are merged there first. master is used for the releases and is just copy of the develop branch with additional hotfixes and tags. You can also bind build hooks to the master branch.

# Example temporary branch names:
develop                 FROM     => MERGE TO
  add/my-feature        (develop => develop)
  remove/my-feature     (develop => develop)
  fix/navigation-broken (develop => develop)
  fix/issue-113         (develop => develop)
master
  fix/1.1.1             (master => master => develop)
  release/1.1.0         (develop => master)

Incorporating a finished feature to 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.

git checkout develop
git merge --no-ff add/my-feature
git branch -d add/my-feature
git push origin develop

Creating a new release.

# Create a new release branch from `develop`.
git checkout -b release/1.2.0 develop
./bump-version.sh 1.2.0
git commit -a -m "Bump version number to 1.2.0"

# Update production.
git checkout master
git merge --no-ff release/1.2.0
git tag -a 1.2.0

# Update development.
git checkout develop
git merge --no-ff release/1.2.0

# Delete the release branch.
git branch -d release/1.2.0

Creating a hotfix for a release.

# Create a new fix branch from `master`.
git checkout -b hotfix/1.2.1 master
./bump-version.sh 1.2.1
git commit -a -m "Bump version number to 1.2.1"

# Fix the problem...
git add -A
git commit -m "Fix severe production problem"

# Update production.
git checkout master
git merge --no-ff hotfix/1.2.1
git tag -a 1.2.1

# Update development.
git checkout develop
git merge --no-ff hotfix/1.2.1

# Delete the branch.
git branch -d hotfix/1.2.1

Sources

• A successful Git branching model