Git Flow Introduction 🌲
Tags: github, git, productivity
Published: 2020-09-23 09:08:01

When I started learning development a couple month ago, I was introduced to Git and GitHub pretty early in the process.

At first, I didn't understand how it works but I kept working on and at some point, I was able to manage commits and branching.

To be honest, as I self-taught developer working 100% of the time alone in my basement, commit and push directly on the master branch was enough for my dummy projects.

Now, as I am currently attempting an intensive coding training with 10 other people, and we are supposed to work together I finally understand why Git is important and how powerful it is.

I am diving deeper into Git and different Git workflows and I will humbly share the little knowledge I gathered on this topic.

#Why do we need a Git workflow ?

Git itself is powerful and prevent most mistakes we could possibly make. However, merge conflict is a thing, data leak, ...

Without an established bullet-proof methodology, working on larger project with your team could end up being a mess.

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/eugbgaqcr83zv7b96sq8.jpg)

In fact, it works perfectly to push on your master branch directly when working alone on simple projects (as I did for a while) but it is probably not good practice.

#How does it work ?

I would like to speak about [Vincent Driessen](https://nvie.com/posts/a-successful-git-branching-model/) branching model. As the author say, this model is already 10 years old and might not be optimal for every modern projects. However, this well finished model has been a reference for years and it is a great starting point.

##1. Main branches

We have two main branches with an infinite lifetime, **master** and **develop** and developers should never write code directly on those.

➡️**master** is always ready to be deployed, it is a stable version of our product.

➡️**develop** is the latest version of our product, there we merge new features.

## 2. Supporting branches 

Since we are not supposed to write code on main branches directly, we need supporting branches to work on.

➡️**feature** branches off from **develop** and may only merge to **develop**. 

Every new feature should have its own branch with a specific purpose.

➡️**release** branches off from **develop** and may merge to **master**. 

We create a new release branch whenever the current state of **develop** represent a satisfying version of the next product update. 

After the release branch is created, its state is polished until it is ready to be merged to master.

➡️**hotfix** branches off from **master** and must merge to **master** and **develop**.

As soon as a bug show up on the production build, a **hotfix** branch is created to fix it. 

Of course, this branch should always represent a production ready state since it is meant to merge back to **master**.

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/uyz1jbn0wd0f5yzwswmo.png)

#Conclusion

It might sound scary or overkill to adopt this branching system but in the end, there is no doubt that improving your organization will boost your products quality.

That is something I am going to work on for my next projects ! 🔥

Let me know what you think about it, I did my best to stick to the original methodology introduced by [Vincent Driessen](https://nvie.com/posts/a-successful-git-branching-model/).

Thank you for reading!


Source:

- https://nvie.com/posts/a-successful-git-branching-model/

- https://blog.nathanaelcherrier.com/fr/gitflow-la-methodologie-et-la-pratique/

- https://chrisbeams.com/posts/git-commit/