GitFlow — How to start
How GitFlow can help you
Imagine this scene:
Are you working on a project, a pretty cool project, but you don’t know what a branch is, or you never know how to name it, or what to write as commit message?
Or maybe you would like to start using a standard, used by thousands of companies to manage projects with a continuous scheduled release.
So.. What is Git-Flow.
GitFlow is a robust framework for managing project defining a strict branching model design around the project release, where each branch is assigned a precise meaning and name.
This in theory, but in practice?
In practice, you won’t have to learn anything new, it’s more like learning a new habit. At first you won’t feel the difference, but you will see the difference in the long run!
Installation
On OSX systems, you can execute brew install git-flow
.
On windows you will need to download and install git-flow.
If you use any Linux distro, it certainly doesn’t need to tell you 😉.
Get Start
After installing git-flow you can use it in your project by executing git flow init
. Git-flow is a wrapper around Git.
The git flow init
command is an extension of the default git init command and doesn’t change anything in your repository other than creating branches for you.
How it work
Before I start, I’d like to explain what a branch is.
🐴 A parallel universe 🦄
Yes, really.
You can see a branch as a version of your code, where different things can happen, and where everything looks the same as the original, but it really isn’t.
In other words, you can think of a branch as a different version of your code.
Because?
Maybe you’re not the only one working on the project, and you don’t want your bugs to stop your teammates from working right?
Or maybe, you’re already in production, and you want to safeguard the code.
🧙♂ ️If it works, don’t touch if 🙏
Develop and Master Branches
Instead of a single master
branch, this workflow uses two branches to record the history of the project. The master
branch stores the official release history, and the develop
branch serves as an integration branch for features. It’s also convenient to tag all commits in the master
branch with a version number.
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.
Without the GitFlow extensions:
$ git branch develop
$ git push -u origin develop
When using the GitFlow extension library, executing git flow init
on an existing repo will create the develop
branch:
$ git flow init
Initialized empty Git repository in ~/project/.git/
No branches exist yet. Base branches must be created now.
Branch name for production releases: [master]
Branch name for “next release” development: [develop] How to name your supporting branch prefixes?
Feature branches? [feature/]
Release branches? [release/]
Hotfix branches? [hotfix/]
Support branches? [support/]
Version tag prefix? []$ git branch
* develop
master
Feature Branches
Each new feature should reside in its own branch, with can be pushed to the central repository, for backup (do you remember in case of 🔥?) or collaboration.
🚨 Features should never interact directly with master 🚨
Note that feature
branches combined with the develop
branch is, for all intents and purposes, the Feature Branch Workflow. But, the Gitflow Workflow doesn’t stop there.
Feature
branches are generally created off to the latest develop
branch.
Creating a feature branch
Without the git-flow extensions:
$ git checkout develop
$ git checkout -b feature_branch
When using the git-flow extension:
$ git flow feature start feature_branch
After this? Continue your work and use Git like you normally would.
Finishing a feature branch
When you’re done with the development work on the feature, the next step is to merge the feature_branch
into develop
.
Without the git-flow extensions:
$ git checkout develop
$ git merge feature_branch
Using the git-flow extensions:
$ git flow feature finish feature_branch
After months of intense work on your project, the day of the release finally arrived.
Release Branches
Once develop
has acquired enough features for a release (or a predetermined release date is approaching), you fork a release
branch off of develop
. Creating this branch starts the next release cycle.
Only bug fixes, documentation generation, and other release-oriented tasks should go in this branch. Once it’s ready to ship, the release
branch gets merged into master
and tagged with a version number.
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.
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'
Finishing a release branch
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.
To finish a release
branch, use the following methods:
Without the git-flow extensions:
$ git checkout master
$ git merge release/0.1.0
Or with the git-flow extension:
$ git flow release finish '0.1.0'
Hotfix Branches
There is nothing Hot about this branch, apart from the danger and urgency.
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.
You can think of maintenance branches as ad hoc release
branches that work directly with master
.
Having a dedicated line of development for bug fixes lets your team address issues without interrupting the rest of the workflow.
Creating a Hotfix branch
Without the git-flow extensions:
git checkout master
git checkout -b hotfix_branch
When using the git-flow extensions:
$ git flow hotfix start hotfix_branch
Finishing a release branch
Without the git-flow extensions:
$ git checkout master
$ git merge hotfix_branch$ git checkout develop
$ git merge hotfix_branch$ git branch -D hotfix_branch
When using the git-flow extensions (don’t work hard, work smart 🤓):
$ git flow hotfix finish hotfix_branch
https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow
I didn't write this article because I think I'm better at explaining git-flow. But I would have liked to add mine.
Hope you liked it 🙃