---
description: >-
  GitFlow is a branching model for Git, created by Vincent Driessen. It has
  attracted a lot of attention because it is very well suited to collaboration
  and scaling the development team.
---

# Development workflow

* [Key benefits of GitFlow](#key-benefits-of-gitflow)
  * [Parallel development](#parallel-development)
  * [Collaboration](#collaboration)
  * [Release staging area](#release-staging-area)
  * [Support for emergency fixes](#support-for-emergency-fixes)
* [Change requests](#change-requests)
* [Feature development workflow](#feature-development-workflow)
* [Hotfix development workflow](#hotfix-development-workflow)

## Key benefits of GitFlow

#### Parallel development <a href="#parallel-development" id="parallel-development"></a>

GitFlow makes parallel development very easy by isolating new development from finished work. New development (such as features and non-emergency bug fixes) is done in **feature branches**, and is only merged back into main body of code when the developer(s) is happy that the code is ready for release.

If you are asked to switch from one task to another, all you need to do is commit your changes and then create a new feature branch for your new task. When that task is done, just checkout your original feature branch and you can continue where you left off.

#### Collaboration <a href="#collaboration" id="collaboration"></a>

Feature branches make it easier for two or more developers to collaborate on the same feature, because each feature branch is a sandbox where the only changes are the changes necessary to get the new feature working. That makes it very easy to see and follow what each collaborator is doing.

#### Release staging area <a href="#release-staging-area" id="release-staging-area"></a>

As new development is completed, it gets merged back into the **develop branch**, which is a staging area for all completed features that have yet to be released. So when the next release is branched off of **develop**, it will automatically contain all of the new development that has been finished.

#### Support for emergency fixes <a href="#support-for-emergency-fixes" id="support-for-emergency-fixes"></a>

GitFlow supports **hotfix branches** - branches made from a tagged release. You can use these to make an emergency change, safe in the knowledge that the hotfix will only contain your emergency fix. There’s no risk that you’ll accidentally merge in new development at the same time.

## Change requests

A change request is a proposal from a stakeholder in the software development process to change something in a product or in a product process. Common change requests include defects and requests for product enhancements or new features.

JIRA is a popular development workflow management solution. For enterprises at scale, it is common for teams to be comprised of stakeholders that oversee specific product domains.

For example, an ecommerce application may have teams responsible for one or more of these domains: Home, Product details, Product search, User accounts, Purchase, and others.

Change requests then come through as tickets. Tickets names should reflect the team making the request and an incremented number.&#x20;

Example ticket name: purchase-23

Example hotfix ticket name: HOTFIX-purchase-23

## Feature development workflow

New development (new features, non-emergency bug fixes) are built in **feature branches**. Feature branches are branched off of the **develop branch**, and finished features and fixes are merged back into the **develop branch** when they’re ready for release.

1. Verify you are on **develop branch** and it is updated to latest
2. Create a branch off of **develop branch**
   1. The new feature branch should be named the same as the ticket making the change request - i.e. purchase-23
3. When development is complete, create a **pull request** into the **develop branch**
4. A pull request review should be conducted to ensure all best practices are followed and the change request requirements are satisfied
5. Finished features are then merged back into the **develop branch** and are ready for next release

## Hotfix development workflow

1. Verify you are on **master branch** and it is updated to latest
2. Create a branch off of **master branch**
   1. The new feature branch should be prefixed by 'HOTFIX' and named the same as the ticket making the change request - i.e. HOTFIX-purchase-23
3. When development is complete, create a **pull request** into the **develop branch** and **master branch**
4. A pull request review should be conducted to ensure all best practices are followed and the hotfix request requirements are satisfied
5. Finished hotfixes are then merged into the **develop branch** and are verified as working properly
6. Finished hotfixes are then merged back into the **master branch** and are verified as working properly in production
