The Art of Designing Gitlab Flow for a Team Project

Workflows can help streamline and automate repeatable business tasks, minimizing room for errors and increasing overall efficiency. — Jamie Johnson

After years of being a lone wolf, learning to create computer programs all by yourself, you finally get to work in a team. Hooray! After gathering with your teammates and breaking down all the task that you guys have to do, you finally decide that it is the best if your team use a version control system to manage the collaboration between you and all your teammates. Because after all, the version control system is a system that records changes to a file or set of files over time so that you can recall specific versions later.” (Scott Chacon, 2016).

Sometime later, you and your team have chosen to use the git version control to help you develop your software. A little about git: Git thinks of its data more like snapshots of a miniature filesystem. Every time a user commits, Git will take a picture of how the whole files look at the moment and then store the reference to that snapshot. If the files haven’t changed, Git will not store those files again, they will just link the files to the previous identical files that it has already stored (https://git-scm.com).

However, there is still a problem. Your team doesn’t have a workflow！ Everyone pushes to the master branch, causing a bunch of merge conflicts and hard to track codes. You start to wonder, is there any better way to manage your team’s git-flow? How and why should you follow the existing git-flow? Is there any best practice?

Well, turn out there are some suggestions, this is one of them, created by Vincent Driessen team in 2010.

Source: https://docs.gitlab.com/ee/workflow/gitlab_flow.html

This is one of the first proposals on how the Gitlab flow should be. It suggests a masterbranch and a separate developbranch, as well as supporting branches for features, releases, and hotfixes. The development happens on the develop branch, moves to a release branch, and is finally merged into the master branch.

However, there are two problems that occur: first, the developers have to switch to another branch all the time, since Git automatically use the master branch as the default. Second, the hotfix and release branches can cause some overkill. Nowadays, most organizations practice continuous delivery, which means that your default branch can be deployed.

To be honest, this kind of flow also looks a bit too excessive. In the real world, usually, developers just stop at the developbranch. Hence, the master branch and thehotfix branch are barely used. Some developers also make mistakes like merging changes only into master and not into the develop branch. The reason for these errors is that Git flow is too complicated for most use cases. For example, many projects do releases but don’t need to do hotfixes.

This is some alternative Git flow that I’ve created to fix some of the problems mentioned before.

My Version of an Alternative Git Flow

How does this work?

• First, create the default masterbranch in your repository. You should make it protected so that the developers can’t accidentally push their work to the master branch. The masterbranch can only be merged from the development branch. Themasterbranch contains Tag to determine which version is it.
• The development branch is pulled from the master branch. This branch is also protected. The developers can only merge into this branch. However, there are 2 ways to merge into this branch, by taskbranches and hotfix branches.
• There are many taskbranches and it should not be per features. It should be as small as a task. For example, “login page front end” branch should be separated from “login page back end” branch. You should only merge taskbranches to development branch if it has passed all the test. And before you merge, you should remember to pull everything from the development branch. Maybe some of your peers have already pushed something to thedevelopment branch.
• The hotfix branches should only be used when your development branch contains minor errors from multiple taskbranches. If those errors can be done by just 1 person, it should be done in the hotfix branch.

Advantages

• This flow ensures a clean state of branches at any given moment in the life cycle of the project
• It defines how to make Continuous Integration and Continuous Delivery
• It is quite flexible according to team decisions

Disadvantages

• It can become complex when it needs to maintain multiple version in production
• The Git history becomes unreadable

References:

1. Gitlab Website: https://docs.gitlab.com/ee/workflow/gitlab_flow.html
2. Flow Canon: https://flowcanon.com/software/choosing-the-best-git-branching-strategy-for-your-team/