Every Sunday I write an email newsletter with some thoughts, life lessons and links to articles / books I enjoyed that week. I’d love for you to join.

Git is a powerful tool that help you to manage and version properly your code and to evolve your code without lost anything. Unfortunately as every powerful tool, you have to know how to use it, otherwise you will end to create monsters.

My favorite approach to Git is called GitFlow. There are tons of guides about how to configure it so I’ll focus only on how it works.

⚙️ Disclaimer: to understand this article is supposed that you’re an intermediate developer and you already know Git.

The GitFlow approach uses mainly two branches: develop and master. Master contains the exact code that is actually in production. Develop contains all the changes you want to publish in production.

Every time we need to develop to a new feature means that you have to open a new branch. This branch is called feature/feature_name. All this branches have to be opened from develop. Every time we will finish a feature we will merge them always on develop. So forget about master!!

⚙️ The Flow has always to be: open feature from develop, merge feature on develop. Never merge develop on a feature or neither merge/open feature on/from master.

When is the moment to release a new set of feature – for release I mean send to production – we can create a new branch starting from develop. This branch is called release/x.x (where x.x. is the version number).

When release will be consolidated in production we can merge it both on master and develop. We have to merge it on master because it contains the exact code that is actually in production.

This approach allows us to work and finalize a release meanwhile other people work on other function that there are not ready for release (feature/). The other benefits is the ease manage of the hole project using a formal, shared and common “version control structure”.

⚙️ But sometimes we could get trouble like our best friends bugs ????. How do we handle it with GitFlow?

When a bug comes up in production we can open a new branch called hotfix. This type of branches are created starting from master and merged on master/develop/release. They have a faster life cycle compared to features branches because they purpose is fix immediately bugs or potentially security issues in production.

⚙️ That’s amazing but with all this branches we’ll end to have an huge and impossible tree to handle!

No, actually not. A good practice when you open the door and walk in/out is to close the door. It’s the same on GitFlow. Every time you close a feature/release/hotfix (and for close I mean merge on develop/master) you can delete that branch. In this way you have to handle only two main branches (master/develop) and few features branches.

⚙️ TL;DR – Too long; didn’t read

1. Create a master branch that contains the exact same code that is in production
2. Create a develop branch starting from master
3. Create a new feature branch starting from develop every time you have to develop a new functionality
4. When you done close the feature – merge on develop – delete the feature
5. When you are ready for production start a new release/version_number branch from develop
6. Once published merge release on develop and master and delete it
7. Bugs in production? No problem, start a new hotfix branch from master
8. Once finished and published to production – close the hotfix, merge it on develop and master, delete it.

That’s it. Let me know in the comment if you would like to know all the terminal commands to initialize and handle Git with GitFlow approach. Otherwise you can also send me an email or a direct message on Instagram.

This is the (code) way! ✌️????

Every Sunday I write an email newsletter with some thoughts, life lessons and links to articles / books I enjoyed that week. I’d love for you to join.