Git and GitFlow Best Practice

Introduction

A version control system, or VCS, monitors the history of changes when individuals and teams work on projects. As developers make modifications to the project, any previous version can be retrieved at any time. Nowadays Git is the most popular VCS, so let's talk a bit about it.

Workflows for Git

Git gives us the opportunity to conveniently organize our work, it can be adjusted to any work process.

For beginners, however, this can be a challenge. Lack of experience can lead to excessive complications in work processes. Repositories quickly become clogged with redundant branches.

If part of the code is placed in long-lived branches, it becomes difficult for colleagues to find the current version and determine what to deploy on the production server. Therefore, it may be a good idea to use one of the ready-made workflows.

Git Flow

Let's start with Git flow. It is a well-defined set of best practices, time-tested, simple and effective. It was first proposed by Vincent Driessen in his article A successful Git branching model in 2010. If you wish, familiarize yourself with it, the link will be under the video. Let's figure out together how this process works.

The idea of the model is to always have two permanent branches - main (main) and develop (development branch), as well as to additionally create temporary branches for separate functionality (feature), supplies (release) and corrections (hotfix).

The development process is always conducted on develop. Changes ready for a planned release are moved to a branch called release -* (with a corresponding number). When the code from the release is tested, we add these changes to the main branch. This process of merging release to main is essentially the release of our code, because it is the code in the main branch that is the working version of the product.

We made changes to it by adding changes from the release branch - that means we made changes to the product.So, main is a permanent branch for the finished product, develop is a permanent branch for current work on the project, release is temporary, for those changes that will be in the next release. The feature and hotfix remained. What are they needed for?

Feature branches, or we can call them thematic or functional, are needed to work on individual changes. These changes should be integrated into the main code altogether if the new "feature" is liked, or removed from it in the same way in the opposite case.    Such branches are branched from development, and upon completion of the development of this new functionality, merge with it.     

The hotfix branch is branched off from the main one in case there is an urgent problem to be solved in the main version of the code. When the fix is ready, it is merged with the main branch and also with development.

Disadvantages of Git Flow

Git flow is convenient, well-thought-out, and understandable, but it also has its drawbacks.
The first is that developers should use develop, not main. main is reserved for the main version of the code. And since most tools automatically use the main branch as the default, it's annoying to have to switch to another branch.

The second disadvantage is the excessive complexity created by hotfix and release branches. Currently, most projects have organized continuous delivery. So your current branch can be deployed on the server. Therefore, there is no need for separate branches for hotfixes and releases. Developers often forget to add fixes to develop, they only add them to main and not to the develop branch. And it's also because Git flow is redundant for most use cases.

GitHub flow as a simpler alternative

GitHub has created a simpler version of the workflow. Let's examine it.

The basic idea is to have only function branches and main:

This workflow is simple and clear, so many companies have switched to it.
Consolidating everything into the main branch and deploying frequently means you minimize the amount of unreleased code. This approach is consistent with continuous delivery best practices.

There are also other alternative workflows, such as, for example, Gitlab Flow. You can always choose the one that best suits your project workflows.