DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports
Events Video Library
Refcards
Trend Reports

Events

View Events Video Library

Related

  • Developer Git Commit Hygiene
  • Understanding Git
  • AWS CodeCommit and GitKraken Basics: Essential Skills for Every Developer
  • 7 Great Terminal/CLI Tools Not Everyone Knows

Trending

  • How to Parse Large XML Files in PHP Without Running Out of Memory
  • Spring AI Advisors: Chat Memory, Token Tracking, and Message Logging
  • Dear Micromanager: Your Distrust Has a Job; It’s Just Not the One You’re Doing
  • What Is Lambda Architecture? Ultimate Guide to Getting Started
  1. DZone
  2. Testing, Deployment, and Maintenance
  3. Deployment
  4. Introduction to Git Flow

Introduction to Git Flow

Git Flow is an abstract idea of a Git workflow. It is an ideal workflow for release-based software and to maintain multiple versions in production.

By 
Mansi Babbar user avatar
Mansi Babbar
·
Jun. 04, 21 · Tutorial
Likes (21)
Comment
Save
Tweet
Share
13.2K Views

Join the DZone community and get the full member experience.

Join For Free

Overview

Git Flow is an abstract idea of a Git workflow. It helps with continuous software development and implementing DevOps practices. The Git Flow Workflow defines a strict branching model designed around the project release. This provides a robust framework for managing larger projects.  

Git Flow is ideally suited for projects that have a scheduled release cycle and for the DevOps best practice of continuous delivery. It assigns very specific roles to different branches and defines how and when they should interact. It uses individual branches for preparing, maintaining, and recording releases.

Working of Git Flow

1. Develop and Master Branches

Instead of a single master branch, Git Flow uses two branches to record the history of the project. It is based on two main branches with infinite lifetime namely master and develop.

  • Master Branch: The master branch contains the production code and stores the official release history.
  • Develop Branch: The develop branch contains pre-production code and serves as an integration branch for features.

Master and develop branch workflow is demonstrated in the given diagram:

It’s also convenient to tag all commits in the master branch with a version number.

Assuming we have a repo set up with a master branch. The first step is to complement the default master with a develop branch. A simple way to do this is for one developer to create an empty develop branch locally and push it to the server. This branch will contain the complete history of the project. Other developers should now clone the central repository and create a tracking branch for develop.

1.1. Creating a Develop Branch

  • Without the git-flow extensions:
    • git branch develop
    • git push -u origin develop
  • When using the git-flow extensions:
    • git flow init

When using the git-flow extension library, executing git flow init on an existing repo will create the develop branch.

2. Feature Branch

Each new feature should reside in its branch, which can be pushed to the central repository for backup/collaboration. Feature branches use the latest develop as their parent branch. When a feature is complete, it gets merged back into develop. Features should never interact directly with the master branch.

Feature branch workflow is demonstrated in the given diagram:

2.1. Creating a Feature Branch

  • Without git-flow extensions:
    • git checkout develop
    • git checkout -b feature_branch
  • With git-flow extensions:
    • git flow feature start feature_branch

2.2. Finishing a Feature Branch

  • Without git-flow extensions:
    • git checkout develop
    • git merge feature_branch
  • With git-flow extensions:
    • git flow feature finish feature_branch

3. Release Branch

Once develop has acquired enough features for a release (or a predetermined release date is approaching), we 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. Release branch may branch off from develop and must merge into both master and develop.

Release branch workflow is demonstrated in the given diagram:

Once the release branch is ready to ship, it gets merged into master and tagged with a version number. In addition, it should be merged back into develop because critical updates may have been added to the release branch and they need to be accessible to new features. So, once the release is ready to ship, it will get merged into master and develop, then the release branch will be deleted.

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.

3.1. Creating a Release Branch

  • Without the git-flow extensions:
    • git checkout develop
    • git checkout -b release/0.1.0
  • When using the git-flow extensions:
    • git flow release start 0.1.0
    • Switched to a new branch 'release/0.1.0'

3.2. Finishing a Release Branch

  • Without git-flow extensions:
    • git checkout master
    • git merge release/0.1.0
  • With git-flow extensions:
    • git flow release finish 0.1.0

4. Hotfix Branch

Maintenance or “hotfix” branches are used to quickly patch production releases. Hotfix branches are necessary to act immediately upon an undesired status of master. 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 the master branch should be tagged with an updated version number.

Hotfix branch workflow is demonstrated in the given diagram:

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.

4.1. Creating a Hotfix Branch

  • Without git-flow extensions:
    • git checkout master
    • git checkout -b hotfix_branch
  • With git-flow extensions: 
    • git flow hotfix start hotfix_branch

4.2. Finishing a Hotfix Branch

  • Without git-flow extensions:
    • git checkout master
    • git merge hotfix_branch
    • git checkout develop
    • git merge hotfix_branch
  • With git-flow extensions:
    • git branch -D hotfix_branch
    • git flow hotfix finish hotfix_branch

Advantages of Git Flow

Now let’s talk summarize the major advantages provided by Git flow:

  • Ensures a clean state of branches at any given moment in the life cycle of a project
  • The naming convention of branches follows a systematic pattern making it easier to comprehend
  • Has extensions and support on most used git tools
  • Ideal in case of maintaining multiple versions in production
  • Great for a release-based software workflow.
  • Offers a dedicated channel for hotfixes to production.

Disadvantages of Git Flow

Well nothing is ideal, so Git Flow holds some disadvantage as well like:

  • Git history becomes unreadable
  • The master/develop branch split is considered redundant and makes the Continuous Delivery/Integration harder
  • Not recommended in case of maintaining a single version in production

Summary

Here we discussed the Git Flow Workflow. Git Flow is one of the many styles of Git workflows you and your team can utilize. Let’s summarize the whole workflow of Git Flow:

  • A develop branch is created from master
  • Feature branches are created from develop
  • When a feature is complete it is merged into the develop branch
  • A release branch is created from develop
  • When the release branch is done it is merged into develop and master
  • If an issue in the master is detected a hotfix branch is created from master
  • Once the hotfix is complete it is merged to both develop and master
Git Branch (computer science) Flow (web browser) Release (computing) master

Published at DZone with permission of Mansi Babbar. See the original article here.

Opinions expressed by DZone contributors are their own.

Related

  • Developer Git Commit Hygiene
  • Understanding Git
  • AWS CodeCommit and GitKraken Basics: Essential Skills for Every Developer
  • 7 Great Terminal/CLI Tools Not Everyone Knows

Partner Resources

×

Comments

The likes didn't load as expected. Please refresh the page and try again.

  • RSS
  • X
  • Facebook

ABOUT US

  • About DZone
  • Support and feedback
  • Community research

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Core Program
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 3343 Perimeter Hill Drive
  • Suite 215
  • Nashville, TN 37211
  • [email protected]

Let's be friends:

  • RSS
  • X
  • Facebook