While this section touches on a number of guidelines regarding source control, the only requirement for this chapter is a computer with any OS. Git is optional.

If you don’t have Git installed, you can download and install it at the following URL:

https://git-scm.com/

We have used mermaid-js to visually show the branching strategies. As of February 2022, GitHub pages now support Mermaid-js. Some of the sections will include mermaid diagrams to demonstrate the different branching hierarchies.

For more information on Mermaid-js, navigate to the following URL:

https://mermaid-js.github.io

In this section, we’ll explore various branching strategies, explaining how each one works, and highlighting the differences between them.

While every company has its unique workflow, we’ll focus on some commonly used strategies in the industry.

With GitFlow being the initial workflow, everyone is familiar with it in the industry and its successors have improved by making minor changes to the workflow.

In the next sections, we’ll discuss each workflow, but first, we have to understand the fundamentals of GitFlow.

GitFlow

One of the most common and most mature workflows in the industry is GitFlow. It was created by Vincent Driessen in 2010.

A minimal Git repository should have the following branches:

• main/master/trunk (referred to as main from this point on)
• develop

The main branch is what you start with when creating a new repository. The purpose of this branch is to always have stable and production-ready...

Once you have initialized your repository and created your first branch, you can start writing code for your feature.

While this is exciting, this guideline is meant more for teams as opposed to an individual building a side project. The larger the team, the more critical this becomes to your workflow.

Let’s look at an example using multiple feature branches in Figure 1.6.

Figure 1.6: Long-lived feature branch (feature/settings)

Everyone is assigned their respective feature branches, which are created for them. As you can see, the developers are completing their features and checking them into develop.

However, the developer working on the settings feature (feature/settings) is behind. Their branch is becoming stale since they haven’t updated their code over the week. It only contains their feature from when they first created their branch.

What do you think will happen if they decide to commit their...

Technically, knowing how to use source control is only half the battle. The other half is working as a team player while using source control. The ability to keep your fellow teammates in mind will take you further in your career as you become a considerate and trusted developer.

The following sections are meant as guidelines to help you succeed in working in a team environment. If you work as an individual developer on an open source project, it doesn’t hurt to implement these practices as well.

Rebase when Private, Merge when Public

When working on a feature branch privately, there may be times where multiple commits are necessary. These commits add unnecessary noise to the main/master branch.

Rebasing your code takes a number of local commits and updates another branch with a single commit. It essentially rewrites the commit history. Of course, this differs from a merge. Merging is the process of taking all of the commits from one...

In this chapter, you learned about the different types of branching workflows available, including GitFlow, GitHub Flow, and GitLab Flow, and how each one works. Along with the workflows, you learned the industry-standard branch names, such as main/trunk/master, develop, features, release, and hotfix branches, and how they work in each workflow. You also learned the proper way to work with source control, such as always getting the latest code, when to rebase your code versus merging, allowing your branches to have a short lifespan, compiling and testing your code before committing, never checking in assemblies, and the proper use of tagging.

In the next chapter, we’ll take the source code in our repository and create an automated build to create artifacts. We’ll also cover how to automatically deploy it to a server.