#Gitflow #Release train #Git

Gitflow


Introduction

Often we use Git to manage our versions. And in every jobs I did, the process was different. Sometimes we only had master and work in different branches that we merged after. Sometimes we had a development branch, etc… Everyone use it differently.

A great process that I learned and appreciate is Gitflow.


Everything is a branch

In gitflow everything you need is defined. If you need a new feature, there is a branch for it. If you need a new release, a branch and a tag will be created. Let me explain by showing each branches.

As you can see we have two branches Master and Develop

Master

The first branch is master. It’s the main branch and it’s the one that is by default when you create a repository. The master branch is defined to be the most recent version that is in production. We never work in this branch, the only way to alter it is with a release or a bug fix.

Develop

The second branch is develop. This branch is the most recent version that you have in your development team. Like master, no one have to work on it. If you already worked in a team, you might now that it’s better to use pull requests to merge your work with the teams one than commit and push in development directly.

Feature

When you want to work on a feature, you can create a feature branch. It is created from develop and will be merged in develop. Usually I use this kind of branch when I’m in a team where we work in different features or if we work in a feature that will not go in production soon. The most common case is a new feature that needs more than one sprint of work. In other case we work directly in a branch created from develop and create a pull request to develop at the end.

A feature is created from develop and will be merge in develop

Release

When you are ready to create a release, you create a release branch that start from develop. You can make changes, like the version of your app. And when the app is accepted by Apple and released, you can merge the branch to master and develop. To keep the branch open during the validation process give you the opportunity to make small changes and fixes while your testers use it via testflight. When the branch is merged to master we create a tag with the version. It helps to find bugs if it occurs in specific versions or simply to keep the code for each versions.

Release starts from develop and will end in master and develop

Bugfix

A Bugfix is a branch that is created from master and will be merged to develop and master. I use this branch only for a very urgent bugfix like for example an error on login. A new tag will also be created when the branch will be merged.

A hotfix begins in master and like release will be merged in master and develop


Train Release

A great concept I learned during a CocoaHeads Paris conference is the Train Release. The goal is to only release what is ready and release often. During a job I had, I set this with a release every 2 weeks. Even if there is only a small bug fix I released this. This way, you have some kind of routine, and you can work easier with your product team. They know when to create the release note and it fits perfectly in a Scrum sprint. You only had to release what is in develop and voilĂ  !


GitKraken

Now I’ll talk about a great tool named GitKraken. It’s a Git GUI particularly efficient for Gitflow. Every screenshots I show in this article is from this tool.

Gitkraken