Git Flow - What is it and how it works?
Tags: git, management
Published: 2020-07-22 01:25:04

## Introduction

Git Flow is a Git workflow that defines different types of branches, with their responsabilities and the interaction between them. 

It defines a way of using Git and its purpose is to organize the work team so that they can successfully manage the functionalities, bugfixes and releases of their projects. This workflow works great with teams of any size and with teams that have to make releases periodically. 

First, I will explain the main concepts of the workflow and then the tools that help us to implement the workflow more easily.

## **Git Flow concepts**

The workflow has two main branches: `master` and `develop`. 

In the `master` branch, we have all the production code.

In the `develop` branch, we have all the development code.

Nothing unusual up to now. But Git-Flow also introduces 3 types of support branches to manage our workflow in a much more orderly way:

- Feature Branch
- Hotfix Branch
- Release Branch

I will explain each one in more detail → 

### **Feature Branch**

A Feature Branch is a branch that only contains one functionality. If we have ten functionalities to be developed in our development stage, we will create ten independent Feature Branches. 

What is interesting about Feature Branches is that they have to be created from the `develop` branch and they are also merged into it. In other words, the Feature Branches have no interaction with the `master` branch, they only have interaction with the `develop` branch.

### **Hotfix Branch**

A Hotfix Branch is a branch that contains a hotfix. A hotfix is a fix to a production bug. It is called **hot**fix because when we make the fix it is directly merged to the `master` branch without going through the development stage.

We have a Hotfix Branch for each hotfix that we have to implement. The big difference with Feature Branches is that Hotfix Branches are created from the `master` branch and when we finished them they are merged to both `master` and `develop` branches. This is because the bug is in both environments.

Also, when we close a Hotfix Branch, we have to create a tag with the new version of the project. That is because each change we make in `master` branch needs a tag that represents it.

### **Release Branch**

Once the development stage is finished we will have in our `develop` branch all the Feature Branches and Hotfix Branches merged. 

So, if we want to have all these new functionalities in the `master` branch, we have to create a Release Branch.

The Release Branch is created from the `develop` branch. In the Release Branch, we have to make all the necessary changes to upload the release version and then we should have a testing stage before merging it into the `master` branch. If we find any bug as a result of the testing stage, we could fix it in the Release Branch before we close it.

Once the release version is uploaded and the testing stage is completed, the Release Branch has to be merged into both `master` and `develop` branches.
Finally, when we close the Release Branch, we have to create a tag with the new release version.

**And conceptually, that is all!**

![Celebration](https://dev-to-uploads.s3.amazonaws.com/i/2oy62qfc46b9esnyj6tu.jpg)


The conceptual bases of the workflow are simple. So now, we will talk about how this workflow can be implemented in the real life.

## **Git Flow implementation**

We have two ways to implement this workflow:

1-  *Using Git commands:* create, remove and merge the branches with the well-known Git commands.

2- *Using the git-flow CLI tool.*

I will show you how to do it in both ways, but I recommend using the git-flow CLI tool to avoid making mistakes.

To install git-flow CLI tool, we have to run the following command:

- OSX: `brew install git-flow`
- Linux: `apt install git-flow`
- Windows: [https://git-scm.com/download/win](https://git-scm.com/download/win) → It is already included into Git from the version 2.5.3.

### **Git Flow Initialization**

*Basic Git commands:*

The only thing we have to do is create a `develop` branch from the `master` branch.

```bash
git checkout -b develop
```

*Git-flow CLI:*

```bash
git flow init
```

The execution of this command will ask us several questions. We will answer everything in the affirmative. The interesting thing with this execution is that it creates our `develop` branch.

With this initialization, we are ready to start with the Git Flow workflow in our project!

### **Feature Branch**

**Creating Feature Branch**

*Basic Git commands:*

```bash
git checkout develop
git checkout -b name-feature
```

*Git-flow CLI:*

```bash
git flow feature start name-feature
```

**Finishing Feature Branch**

*Basic Git commands:*

```bash
git checkout develop
git merge name-feature
```

*Git-flow CLI:*

```bash
git flow feature finish name-feature
```

### **Hotfix Branch**

**Creating Hotfix Branch**

*Basic Git commands:*

```bash
git checkout master
git checkout -b name-hotfix
```

*Git-flow CLI:*

```bash
git flow hotfix start name-hotfix
```

**Finishing Hotfix Branch**

*Basic Git commands:*

```bash
git checkout master
git merge name-hotfix
git checkout develop
git merge name-hotfix
git tag name-hotfix
```

*Git-Flow CLI:*

```bash
git flow hotfix finish name-hotfix
```

Here we can see how useful is the Git-flow CLI since it helps us not to make mistakes.

The name-hotfix should be the next patch version for our project. For example, if our project has the version 3.1.2 and we have to create a Hotfix, the name-hotfix should be: 3.1.3. You can see more about project versions in [https://semver.org/](https://semver.org/)

### **Release Branch**

Once the development stage is finished, we have to make a release with the new functionalities. Here, we have to create a Release Branch.

**Creating Release Branch**

*Basic Git commands:*

```bash
git checkout develop
git checkout -b release/1.0.0

```

*Git-Flow CLI:*

```bash
git flow release start 1.0.0
```

**Finishing Release Branch**

*Basic Git commands*

```bash
git checkout master
git merge release/1.0.0
git checkout develop
git merge release/1.0.0
git tag 1.0.0
```

*Git-Flow CLI*

```bash
git flow release finish 1.0.0
```

And that is all you have to know about Git Flow!

## Things to consider:

In this section I will mention some good practices to consider when you use Git Flow workflow.

- We should push every Feature, Hotfix and Release branches to remote repository. It will allow you and your team to work collaboratively and have a tracking about the status of the different implementations.
- We should create a Pull Request for each branch before we finish and merge them.
- The Release Branch should pass a testing stage before finish and merge it.
- We should clean up the remote repository of the branches that have already been merged. A tool like *[git-flow-avh](https://github.com/nvie/gitflow)* does it for us.

## Conclusion

In this post we have seen the concepts of the Git Flow workflow and how to implement it in our projects. This workflow works great with teams of any size and with teams that have to make releases periodically.

Git Flow is not the the only workflow for Git. There are others Git workflows that fit with different types of projects and different sizes of teams. You can see some of them in [https://www.atlassian.com/es/git/tutorials/comparing-workflows](https://www.atlassian.com/es/git/tutorials/comparing-workflows)

## Resources

- [https://nvie.com/posts/a-successful-git-branching-model/](https://nvie.com/posts/a-successful-git-branching-model/)
- [https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow](https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow)

Thanks for reading! Let me know your thoughts in the comments.