Chapter 59: Git Branching Models

Slide Deck Git Practices Slides

Git Branches

git branches

A branch in a git repository is just a name associated with a particular commit.

In general, I would recommend giving all of Chaper 3 a read.

Things to discuss:


Gitflow is a strict set of rules for handling branches in a git repository.

There are two main branches that live forever:

In additional to the two main branches, there are a large number of supporting branches. These branches are short-lived and are deleted after they are merged. They come in three varieties:

Feature Branches

Feature branches are used to develop new features. They branch off from develop and are merged back into develop.

The are named whatever you want, and should typically not be synchronized with the origin repository.

Release Branches

Release branches are used to prepare the repository for a release. This can include making sure all test cases pass, updating documentation and version numbers, and minor bug-fixing. They branch off from develop and are merged back into both develop and master simultaneously.

They are named release-* where the * is the name of the release.

Hotfix Branches

Hotfix branches are used to fix bugs on a released version of your software. They branch off from master and are merged back into both develop and master.


This is a very rigid structure for a repository, and it may sometimes not be worth the headache of implementing, but at the very least it serves as a good set of ideas to apply when managing the workflow of your project.

When merging in Gitflow it is recommend to use the --no-ff flag so that a commit is always created to record history of the merge. This is interesting because it is a move in the complete opposite direction of Git methodologies that encourage rebasing. Instead of trying to hide the development history of your project, Gitflow encourages recording it in great detail.

Is using Gitflow a good idea? Consider this article:

What are the problems?


OneFlow is an alternative git branching model proposed by the author of the “GitFlow is harmful” post above.

It is different from GitFlow in the following ways:

GitHub Flow

Most of you will probably be using GitHub to manage your repositories this quarter so it’s worth taking a look at the branching model that GitHub supports and recommends.

In general, the main thing to know about how GitHub works is using Pull Requests, or PRs.

When you create a PR on GitHub, you indicate that you would like to have some set of changes merged into the project. The most common scenarios is that you want to merge your changes from a fork into the original project, or you want to merge a branch you created into master.

In this class I’d recommend going with the branch option since forks are mostly useful when developers aren’t working together but are working on the same thing (i.e. the open source community).

The best thing about PRs, in my opinion, is that they:

A simple and effective rule to use with PRs is that someone other than the author of the PR must merge it.

Through the GitHub interface you also get to choose whether your changes are integrated with a merge commit, rebase, or squash commit.

Git Tips

How to avoid merge conflicts