Branching Workflow

Branches

So far, all of our version histories have been sequential. Each commit follows the next in an ordered line. For example:

However, sometimes it can be useful to manage different versions of code simultaneously. For example, you may have a script that performs a scientific analysis, but want to use different parameters or settings for different analyses. Alternatively, you may want to have a version where you can test out new features while maintaining a version you know already works. In this case, our version history might look something like this:

In git parlance, these concurrent versions are known as branches. Branches are derived from a common point in a version history, but each branch will have a unique history after the split point. For example, this is the version history for the default branch:

whereas this is the version history for the branch implementing a new feature:

You can then switch between different branches and add commits as your needs dictate.

Merging

As mentioned, you might branch your code so you can test new features that might break the code. However, once you finish developing the new features, you may be ready to consolidate the two branches.

This will ensure that your new features are incorporated into future analyses and will help keep your repository clean and easy to navigate. Combining two branches into one branch is known as merging.

Note that when you perform a merge, the histories of the two branches are also combined.