How To Developer : Git

GitFlow - What is it ?

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

As explained in his blog2, Vincent Driessen mades GitFlow about two families of branches :

  • The main branches with an infinite lifetime are master and develop branches.
    • The master branch is the main branch where the source code of HEAD always reflects a production-ready state.
    • The develop branch is 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”. This is where any automatic nightly builds are built from.
  • Supporting branches with a limited lifetime are feature, release and hotfix branches.
    • The feature branches (or sometimes called topic branches) are used to develop new features for the upcoming or a distant future release. When starting development of a feature, the target release in which this feature will be incorporated may well be unknown at that point.
    • The release branches support preparation of a new production release. They allow for minor bug fixes discovered in test phase and preparing meta-data for a release (version number, build dates, etc.).
    • The 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.

GitFlow - Key Benefits

Parallel Development

One of the great things about GitFlow is that it 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(are) happy that the code is ready for release.

Although interruptions are a BadThing(tm), 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

Feature branches also 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

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

Support For Emergency Fixes

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.

GitFlow - Install

https://github.com/petervanderdoes/gitflow-avh/wiki/Installation

GitFlow - How It Works

https://datasift.github.io/gitflow/IntroducingGitFlow.html

1. "Vincent Drissen a software engineer", nvie, http://nvie.com/about ↩
2. "A successful Git branching model", Vincent Driessen, http://nvie.com/posts/a-successful-git-branching-model ↩

results matching ""

    No results matching ""