Learn complete Gitflow Workflow basics how to — from start to finish

The Gitflow Workflow defines a strict branching model designed around the project release.

— Atlassian docs

TL;DR

The overall flow of Gitflow is:

1. A develop branch is created from master
2. A release branch is created from develop
3. Feature branches are created from develop
4. When a feature is complete it is merged into the develop branch
5. When the release branch is done it is merged into developand master
6. If an issue in master is detected a hotfix branch is created from master
7. Once the hotfix is complete it is merged to both develop and master

Installation

Windows — download here.

Mac*— brew install git-flow
*(you’ll need to have Homebrew installed on your system)

Breakdown

Step 1: Create new directory and initialize gitflow

mkdir gitflow-test
cd gitflow-test
git flow init

*I leave all the prompted options as default when initializing gitflow.

Step 1

Understanding the reasoning

At this point if you do a git branch you’ll see two branches initialized — master and develop

This is by choice.

The master branch stores the official release history, and the develop branch serves as an integration branch for features — meaning all your developers will be creating feature branches from the develop branch — more on this in the following step.

Step 2: Feature branches

Starting a feature

git flow feature start feature1

Step 2.1

Finishing a feature

git flow feature finish feature1

Step 2.2

Understanding the reasoning

The ideology of gitflow workflow dictates that each new feature reside in its own branch, which can be pushed to the central repository(GitHub, Bitbucket etc.) for backup/collaboration. But, instead of branching off of master, feature branches use develop as their parent branch. When a feature is complete, it gets merged back into develop. Features should never interact directly with master.

Step 3: Release branches

Starting a release branch

git flow release start 0.1.0

Step 3.1

Understanding the reasoning

Once develop has acquired enough features for a release, you fork a release branch off of develop. Creating this branch starts the next release cycle, so no new features can be added after this point—only bug fixes, documentation generation, and other release-oriented tasks should go in this branch.

Using a dedicated branch to prepare releases makes it possible for one team to polish the current release while another team continues working on features for the next release. It also creates well-defined phases of development.

Finishing a release branch

git checkout master 
git merge release/0.1.0 
git flow release finish '0.1.0'

Step 3.2.1

//--you'll enter vim text editor--
Press i to enter insert mode
Type in your message (e.g. v0.1.0)
press ESC to exit insert mode
press ZZ(should be in caps) to save and exit
// Alternatively, for the last step you can type in :wq and hit ENTER

Step 3.2.2

Understanding the reasoning

Once the release is ready to ship, it will get merged it into master and develop, then the release branch will be deleted. It’s important to merge back into develop because critical updates may have been added to the release branch and they need to be accessible to new features. If your organization stresses code review, this would be an ideal place for a pull request.

Step 3: Hotfix branches

Starting a hotfix branch

git flow hotfix start v1

Step 4.1

Finishing a hotfix branch

git checkout master 
git merge hotfix/v1
git flow hotfix finish v1

Same as Release

//--you'll enter vim text editor--
Press i to enter insert mode
Type in your message (e.g. v0.1.0)
press ESC to exit insert mode
press ZZ(should be in caps) to save and exit
// Alternatively, for the last step you can type in :wq and hit ENTER

Step 4.2

Understanding the reasoning

Maintenance or “hotfix” branches are used to quickly patch production releases. Hotfix branches are a lot like release branches and feature branches except they're based on master instead of develop. This is the only branch that should fork directly off of master. As soon as the fix is complete, it should be merged into both master and develop (or the current release branch), and master should be tagged with an updated version number.

Having a dedicated line of development for bug fixes lets your team address issues without interrupting the rest of the workflow or waiting for the next release cycle. You can think of maintenance branches as ad hoc release branches that work directly with master.

Summary

Gitflow is one of many styles of Git workflows available out there — Gitflow however in particular stands out as it’s great for a release-based software workflow.

**Source: Atlassian’s git tutorial : Gitflow Workflow
***With all the steps I have included a screenshot of terminal to help understand the context better.

Hope this guide helped you. Cheers!