The purpose of this post is to describe the workflow model of Git "GitFlow". In this model, there are three environments that need to consider such as development, testing, and production. In each environment, we will explain in detail how GitFlow helps your product development better in a very precious way. Furthermore, we will explain the connection flow between each environment to make sure the development and deployment process running smoothly without blocking developers.

You may decide to select GitFlow as a workflow model to control the version of source code in your development pipeline.

PROBLEMS

In software development, it is a major issue in developing with many teams and developers. If there is no precious way for them to follow, they will do their own way from experiences they have and it will make problems during the product development process. Therefore, most of the company have to set up their own process of software development for developers to follow in order to prevent messiness development.

QUESTIONS

Below are the questions that come up first when you want to solve the above problems

1. We want to define a good process in the product development cycle of each environment setup. How to achieve this process?
2. We want to have a workflow model of Git to be a management rule of source code version and also workflow which enable easier deployment with the continuous delivery model. How do we achieve this?

GitFlow

GitFlow is a workflow model of Git source code version control introduced by Vincent Driessen in 2010 and it was a successful model ever and easy to use with Git. GitFlow characterizes a strict branching model designed around the project release. While somewhat more complicated and provide a robust framework for managing bigger projects. It assigns very specific roles to different branches and defines how and when they should interact. GitFlow still uses a central repository as the communication hub for all developers like the other workflows. The only difference is the branch structure of the project.

There are two main branches in GitFlow, the Master and Develop branches. The Master branch is a production-ready state (Origin/Master) branch and Develop branch is the latest delivered development changes for release (Origin/Develop) branch. Furthermore. There are three supporting branches, Feature, Release, and Hotfix branch.

• Feature is a branch off from Develop and must merge back into Develop
• Release is a branch off from Develop and must merge back to Develop and Master
• Hotfix is a branch off from Master and must merge back into Develop and Master

We must follow the naming convention of each branch in GitFlow and the rule of naming version in production release or production hotfix as shown in the figure above.

MAIN BRANCHES

At the core, the development model is greatly inspired by existing models out there. The central repo holds two main branches with an infinite lifetime: Master and Develop.

The master branch at origin should be familiar to every Git user. Parallel to the master branch, another branch exists called develop. We consider origin/master to be the main branch where the source code of HEAD always reflects a production-ready state and origin/develop to be the main branch where the source code of HEAD always reflects a state with the latest delivered development changes for the next release.

When the source code in the develop branch reaches a stable point and is ready to be released, all of the changes should be merged back into master somehow and then tagged with a release number. Therefore, each time when changes are merged back into master, there is a new production release. We could use a Git hook script to automatically build and roll out our software to our production servers every time there was a commit on master.

FEATURE BRANCHES

Feature branches are used to develop new features for the upcoming future release. When starting the development of a feature, the target release in which this feature will be incorporated may well be unknown at the point. The essence of a feature branch is that it exists as long as the feature is in development, but will eventually be merged back into develop (to definitely add the new feature to the upcoming release) or discarded (in case of a disappointing experiment). Feature branches typically exist in developer repos only, not in origin. The below is the flowchart of the feature branch

RELEASE BRANCHES

Release branches support the preparation of a new production release. They allow for minor bug fixes and preparing meta-data for a release (version number, build dates, etc.). By doing all of this work on a release branch, the develop branch is cleared to receive features for the next release. The below is the flowchart of the release branch

HOTFIX BRANCHES

Hotfix branches are very much like release branches in that they are also meant to prepare for a new production release. When a critical bug in a production version must be resolved immediately, a hotfix branch may be branched off from the corresponding tag on the master branch that marks the production version. The below is the flowchart of the hotfix branch

THANK YOU AND HOPE THIS WILL HELP YOUR DEVELOPMENT PROCESS !!!

Find Us @
Facebook
Telegram
Twitter
LinkedIn