Spinneret Blog | Git Branching Strategy
Simple Git Branching Strategy

By Michael Stepanian

Git is the premier version control system today. Using git effectively is important for any developer to learn, and extremely useful for companies wishing to increase their output. Branching models are utilized by large teams to organize and effectuate large scale merges between many team members. In a small team, a complex branching strategy like this well-known one may be overkill. Here is a simple branching strategy which has been very successful for us:


The only endless branch is master. Features, bugs, and hotfixes branch off of master and are merged back into master. In our example, let's say the team consists of two members, a manager and developer. The developer is in charge of creating new branches and committing to the branches. The manager is tasked with merging the branches into master.

Branch Naming Policy

Branches should be named starting with feature/, bug/, or hotfix/ depending on what kind of branch it is, followed by a brief description of the branch, e.g. feature/new-page or bug/broken-link.

Creating a New Branch and Working in It
The developer creates a new branch in the following way:
  1. Check out the master branch and pull to have the latest version to branch from

    $ git checkout master
    $ git pull
  2. Create a new branch from master and check it out

    $ git checkout -b feature/my-new-branch
  3. Work in branch and add changes

    $ git add -u

    Use -u as default, or if there are untracked files in the repo you do not want to commit.

    $ git add -A

    Use -A to include untracked files.

  4. Commit your work with a commit message.

    $ git commit -m "My changes"

    Add a small comment to every commit describing what changes you made

    Unstable (code-breaking) commits are allowed in feature branches. If the commit you just made is unstable, include UNSTABLE in the comment

  5. Push your changes.

    $ git push

    For the first push, you will need to create the branch on remote:

    $ git push --set-upstream origin feature/my-new-branch
Merging Branches
In this strategy, the developer does most of the work even when merging into master. He merges the latest version of master into the branch before merging the branch into master to take care of any merge conflicts outside of master. For the merging process, we have three "steps" which are useful for communicating the merge between the manager and developer.
  1. The manager makes sure master is up to date, making any commits and pushes necessary.

    (Step 1 done).

  2. The developer checks out and pulls master

    $ git checkout master
    $ git pull
  3. Check out the branch to be merged and merge master into the branch

    $ git checkout feature/my-new-branch
    $ git merge master
  4. Push the merge.

    $ git push

    If there are conflicts, fix the conflicts then do:

    $ git add -u
    $ git commit -m "Merging master into feature/my-new-branch"
    $ git push

    (Step 2 done).

  5. The manager fetches the newly updated branch.

    $ git fetch
  6. Compare the branch with master and do code review. A GitHub pull request is a good way to do this.

  7. The manager merges the branch with master and tests master locally. If everything is running smoothly, he pushes master.

    $ git checkout master
    $ git merge feature/my-new-branch
    $ git push

    (Step 3 done).


After the branch is merged and master is pushed, it can be safely removed from remote. An easy way to do this is to go to https://github.com/my-company/MyProject/branches, see if each branch is up to date with master, and remove the ones that are.