Gitflow

@DanielLlanoB

A successful Git branching model

https://nvie.com/posts/a-successful-git-branching-model/

Vincent Driessen

Is really just an abstract idea of a Git workflow"

Gitflow Workflow is a Git workflow design that was first published and made popular by Vincent Driessen. The Gitflow Workflow defines a strict branching model designed around the project release. This provides a robust framework for managing larger projects.  
  • Is ideally suited for projects that have a scheduled release cycle.
  • Assigns very specific roles to different branches and defines how and when they should interact.
  • Uses individual branches for preparing, maintaining, and recording release.

How it works

Develop and Master Branches

The main branches

We consider origin/master to be the main branch where the source code of HEAD always reflects a production-ready state.
We consider 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. Some would call this the “integration branch”. 
Therefore, each time when changes are merged back into master, this is a new production release by definition. We tend to be very strict at this, so that theoretically, we could use a Git hook script to automatically build and roll-out our software to our production servers everytime there was a commit on master.
git branch develop
git push -u origin develop

Creating a develop branch

Supporting branches

  • Feature branches
  • Release branches
  • Hotfix branches

Feature branches

  • May branch off from:  develop
  • Must merge back into: develop
  • Branch naming convention: anything except master, develop, release-*, or hotfix-*
Feature branches are used to develop new features for the upcoming or a distant future release.

Creating a feature branch

$ git checkout -b myfeature develop
// Switched to a new branch "myfeature"

Finishing a feature branch

git checkout develop
git merge feature_branch
git push origin develop

git push origin feature_branch
Create PR from feature_branch to develop

Result

Release branches

Release branches support preparation of a new production release. They allow for last-minute dotting of i’s and crossing t’s. Furthermore, 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 big release.
  • May branch off from:  develop
  • Must merge back into: develop and master
  • Branch naming convention: release-*

Creating a release branch 

$ git checkout -b release-1.2 develop
//* Switched to a new branch "release-1.2"

$ ./bump-version.sh 1.2
// Files modified successfully, version bumped to 1.2.

$ git commit -a -m "Bumped version number to 1.2"

// [release-1.2 74d9424] Bumped version number to 1.2
// 1 files changed, 1 insertions(+), 1 deletions(-)

Finishing a release branch

$ git checkout master
// Switched to branch 'master'

$ git merge --no-ff release-1.2
/*Merge made by recursive.
(Summary of changes)*/

$ git tag -a 1.2
$ git checkout develop
//Switched to branch 'develop'

$ git merge --no-ff release-1.2
/*Merge made by recursive.
(Summary of changes)*/
$ git push origin release-1.2
Create PR from release-1.2 to master & develop
$ git branch -d release-1.2
// Deleted branch release-1.2 (was ff452fe).

Hotfix branches

Hotfix branches are very much like release branches in that they are also meant to prepare for a new production release, albeit unplanned. They arise from the necessity to act immediately upon an undesired state of a live production version. 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.
  • May branch off from:  master
  • Must merge back into: develop & master
  • Branch naming convention: hotfix-*

Creating a hotfix branch 

$ git checkout -b hotfix-1.2.1
// Switched to a new branch "hotfix-1.2.1"

$ ./bump-version.sh 1.2.1
// Files modified successfully, version bumped to 1.2.1.

$ git commit -a -m "Bumped version number to 1.2.1"
// [hotfix-1.2.1 41e61bb] Bumped version number to 1.2.1
// 1 files changed, 1 insertions(+), 1 deletions(-)

... Then, fix the bug(s)

 

$ git commit -m "Fixed severe production problem"

/* [hotfix-1.2.1 abbe5d6] Fixed severe production problem
5 files changed, 32 insertions(+), 17 deletions(-) */

Finishing a hotfix branch

$ git checkout master
//Switched to branch 'master'

$ git merge --no-ff hotfix-1.2.1
/*Merge made by recursive.
(Summary of changes)*/

$ git tag -a 1.2.1
$ git checkout develop
//Switched to branch 'develop'

$ git merge --no-ff hotfix-1.2.1
/*Merge made by recursive.
(Summary of changes)*/
$ git push origin hotfix-1.2.1
Create PR from hotfix-1.2.1 to master & develop
$ git branch -d hotfix-1.2.1
//Deleted branch hotfix-1.2.1 (was abbe5d6).

Summary

  • The workflow is great for a release-based software workflow.
  • Gitflow offers a dedicated channel for hotfixes to production.

Some key takeaways to know about Gitflow are:

  •  
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 develop and 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 developand master

The overall flow of Gitflow is:

References

Gitflow

By Daniel Llano Bermúdez

Made with Slides.com

Gitflow

Gitflow Workflow is a Git workflow design that was first published and made popular by Vincent Driessen at nvie. The Gitflow Workflow defines a strict branching model designed around the project release. This provides a robust framework for managing larger projects.

  • 972

More from Daniel Llano Bermúdez