#5: Git and its branches

Git Workflow, Git and its branches

Good. This time, let's take a little height. An essential aspect of using Git is how to manage branches. A good Git "Workflow" allows you to frame the development of the project, clarify the project management methodology and facilitate the use of DevOps methods. This is why the choice of a relevant workflow is very important. If he does not determine them directly, he will strongly influence the versioning strategy of the project, the phases of deliveries, the method of contribution, the use of CI/CD tools, the success of the project, the salary of the developers, global warming and the geopolitical situation of the Juras. “You are exaggerating” you will say to me, to which I will answer perhaps.

Why use branches in Git?

Let's start with the beginning : why use branches in Git? A branch allows you to make a set of modifications, consistent with each other, without disturbing the current version of the project. Once the work on this branch is stable and tested, it can be checked back In one time on the main branch. Thanks to this principle, all phases of development (often unstable) are done separately, in a pocket universe (I will not get tired of this metaphor, you will have to deal with it). As a result, when this work is integrated into the stable version of the project, it is in a way atomic (or transactional = we apply all at once). The stability of the project is thus guaranteed!

We therefore see two types of branches emerging: “permanent” branches as master (recently renamed main in the git convention) carrying a persistent version of the project, and “ephemeral” branches which only live the time of a development, like the branches of feature, bug fixing, etc. This difference has no technical reality, it is only a convention of use. Ephemeral branches are deleted once merged into a permanent branch, and do not must not be reused. The main branches carry the successive versions of the project, remaining present throughout its life.

What is a workflow?

A workflow is a recommendation on how to organize your work, essentially based on the use of branches. It allows to manage software development by offering a methodology adapted to the team. The workflow defines which "permanent" branches are to be created, when, why and how to create new branches, and how to merge these branches.

The first and best known Git Workflow is GitFlow, appeared 10 years ago. It is a very complete workflow (if not the most complete), which solves many scenarios: management of a production environment et preproduction, management of releases in dedicated branches, resolution of bugs in production or on old versions of the project, maintainability of the different versions of the project... And here is a small overview of the workflow:

 

GitFlow Workflow

Here is a workflow that is beautiful!

At first glance, no need to look any further. GitFlow meets all expectations and can adapt to all situations. Branch master represents the stable production version, the branch develop represents the pre-production, the release branches allow to manage the correction, the QA and the resolution of bug before delivery, etc.

So finally no need for other workflows? Month.

The different Git Workflows

Since the publication of GitFlow, several alternatives have been proposed, more or less based on the original workflow. But if Git Flow is so complete, why use another workflow? In the same way that burning down your house because you found a spider is a bit Overkill (although quite sensible), Git Flow is a bit Overkill for many projects. The use of an oversized workflow will slow down productivity all the time, without any contribution to the project… What are the alternatives to consider? Here are a few !

NoFlow

Sometimes you have to go simple. One branch, one version, one history. But a history all the same, and that is indeed the first use of Git: versioning. Even if it is very limited, this workflow is sufficient for projects where you simply want to keep track of the progress, without managing delivery, parallel development or release.

 

Quickly overcome, the "no Flow" is not really not suitable for project management. Everything is committed on the same branch, so everything is immediately “in production”…

Github Flow

In order to offer a minimalist but functional alternative to GitFlow, Github proposed its own workflow, the (oh surprise) Github Flow.

Branch develop disappears and master resumed its central role in the development of the project. No commits are made directly in master, and branching any changes to the project allows code to be tested before it is merged into master.

Workflow Github Flow

More accessible than GitFlow, GithubFlow is a very good alternative when it comes to follow a project without the need to manage a production environment or a release. The use of feature branches provides stability and collaborative work, without adding heaviness to development.

Gitlab Flow

When Github Flow is not sufficient, the version offered by Gitlab is the next option to consider. very similar, Gitlab Flow uses the same basis (master + features branches), adding the ability to manage one or more deployment environments through dedicated branches.

Gitlab Flow Workflow

In the event of a bug detected directly in production, a branch is pulled from production, the bug is fixed and the branch is then both merged on master And on production. To deliver a new version of the project, simply merge master in production and voila. We thus keep a simple workflow but this time allowing to manage the management of environments.

Good but suddenly I take which Git Workflow?

You know, I don't think there is a good or bad workflow...

The important thing in choosing the solution adapted to the needs of the project. No need to fetch a GitFlow from the dead for a POC without putting it into production. Even more important, a workflow must evolve with the needs of the project. Choosing Github Flow as the basis for launching the project is pragmatic. Need to manage a pre-prod? Let's switch to Gitlab Flow by adding a branch preprod, which can carry the version of the project to be tested for the next release, and some time later a branch prod for production deployment.

You have to keep in mind that a workflow is not an immutable law to be followed scrupulously... adapts, it changes, to stick to the project et to the team. The workflows are only presented here on the surface (we are not talking about version tags for example), the important thing is to have the main lines in mind to choose your workflow. You can then dig into the variations to integrate to get your workflow right!

Marine

Check all
Career area
Subscribe to the newsletter :
These articles may interest you