Branching, merging, and ensuring a clear main build

When do we run a build? Every time a commit is pushed. But every result is not the same. When dealing with a source control system such as Git, we typically have two kinds of branches:

One main branch
Feature branches

They implement a particular feature or bugfix, which will be merged into the main branch when ready, as is shown in the following figure:

In this example, we see how the main branch (master) is branched to develop feature A. Feature A is introduced briefly after that. There is a feature B that hasn't been merged yet since it's not ready. With the extra information on what builds have been successful or not, we can know when it is safe to merge a feature branch into the main branch:

Breakage in a feature branch that is not yet merged is not great, but while it is work in progress, it is expected to happen. Meanwhile, a breakage in the main branch is an event that should be fixed as soon as possible. If the main branch is in good shape, that means that it is potentially releasable.

GitHub has a model for this: pull requests. We will configure pull requests to automatically check whether the build has passed and avoided merging or not. If we force any feature branch to also be up-to-date with the main branch before merging back, the main branch ends up being very stable.

For dealing with branches in Git to define releases, the most popular model is Git-flow, defined in this influential blog post ( https://nvie.com/posts/a-successful-git-branching-model/). The following CI practices allow simplify things a bit and don't deal with elements such as release branches. This blog post is a highly recommended read.

Having an uninterrupted line of successful builds in the main branch is also very helpful to develop a sense of stability and quality in the project. If main branch breakages are very rare, confidence in creating a new release with the latest main branch is very high.