Branching Workflows

In this video, we’ll talk about how to structure and manage your branches.

Branches can be put in two different groups: short-lived branches and long-running branches. Before we talk about these groups in detail, please note that this distinction is only a semantic one. Technically, a branch is just a branch.

Short-Lived Branches

Let’s start with short-lived branches. In the earlier videos, I repeated one piece of advice pretty often: Create a new branch for every topic, for each new feature, experiment, or bug fix. Branches for these kinds of things are called “short-lived” branches.

And they share two important characteristics:

• They are about a single topic. We use them to isolate code from other topics’ code.
• They typically have a rather short lifespan, usually only until you’ve finished working on the topic. For example, when that feature is complete, or that bug is fixed, we’ll integrate the branch into a general development or master branch. And it’s often deleted after that.

Long-Running Branches

Long-running branches are different. They exist independent of a single feature or bugfix. They represent states in your project lifecycle - like a “production”, “testing”, or “development” state. And they remain in your project for a longer time - often, in fact, all the time.

Typically, a couple of rules apply to these long-running branches:

• You shouldn’t work on them directly. Instead, you integrate other branches (like feature branches or other long-running branches) into them. But you perform commits directly on those branches.
• Often, long-running branches have a hierarchy between them: e.g. “master” is used as the highest-order branch. It should only contain production code. One level lower, a “development” branch could exist. It’s used to test developed features and is then integrated into “master”…

Which long-running branches should be created and how they should be used can’t be generalized. This depends a lot on the requirements of the project and the team (e.g. its size and style of development). In any case, you need clear rules that everybody in the team must agree on.

Let’s look at a very simple workflow that’s in use in a lot of teams. It uses “master” as its only long-running branch. Having only a single long-running branch in your workflow keeps things as simple as possible.

Keep in mind that the “master” branch effectively represents your production code. Therefore, one thing is extremely important: everything that gets integrated into master must be stable. It must be tested, reviewed, and approved by whatever methods you have to assure quality.

Also remember that no work should happen directly on “master” (which is also a very common rule). If you find yourself typing “git commit” while you’re on the master branch, you should ask yourself if you’re doing the right thing…

Regarding short-lived branches, this workflow is also very straightforward: Every time you start working on a new feature or bugfix, you should create a new branch for this topic. This is a common practice in almost all branching workflows. And it definitely should become a habit for you, too.

Since we only have a single long-running branch, all new topic branches are based off of this “master” branch. And when your work is done in this topic, of course, it should be merged back into “master”.

Another good habit is to integrate often. This has two aspects:

• you should integrate your colleagues’ work as often as possible into your local branches. The reason for this is easy: the longer you wait, the more changes will happen - and the higher the risk for a merge conflict.
• you should also push your new code regularly to the remote. This makes sure that people working with you can integrate often on their end.

This is it for today - thanks for watching!