DEV Community

Cover image for Git Flow Introduction 🌲
Killian Frappart
Killian Frappart

Posted on • Edited on

Git Flow Introduction 🌲

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

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 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

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.

Thank you for reading!

Source:

Top comments (1)

Collapse
 
rajmohanpdy profile image
rajmohan s

well explained. Thanks