Git-Flow is a development workflow for keeping your branching consistent among your team. In this article I will explain the different branches and how to go about implementing this process into your workflow.

Branches

First before we get started, let’s go over a quick overview of what the naming conventions are for our branching. We have 2 primary branches.

• Master Branch
• Develop Branch

Our master branch can be looked at as our currently released branch, or what you’d find in production. The develop branch on the other hand would be our integration branch.

Apart from the primary 2 branches, we also have 3 others for maintenance, new features, and release hardening.

• Feature Branch
• Hotfix Branch
• Release Branch

Master Branch

The best way to get started with anything is by doing. So let’s get into some examples and work our way through using this within an actual code base.

The first thing we’ll want to do is it start our git project. Within your project’s directory we’ll run the following.

echo "# Git Flow Workflow Example" >> README.md
git init
git add README.md
git commit -m "Initial commit."
git remote add origin [email protected]:frankperez87/gitflow-example.git
git push -u origin master

Keep in mind that you will never be making changes directly on the master or develop branches. We’re only just setting up our project which is why I setup this initial commit on our master branch.

In the above example, I created a repository on GitHub, which is where we’ll store our data remotely.

Develop Branch

Next step is to really setup our develop branch, where we’ll be able to integrate our features. We also want to setup this branch so that it is also remotely tracked. We’ll do this by issuing the following commands within our terminal.

git branch develop
git push origin develop

Feature Branches

So now let’s create our first feature. Really every new thing that you do will be a feature, unless you’re having to quickly fix something in your production, which in that case it would be a hotfix.

Let’s say we want to create a new file for lipsum.md, which contains some lorem ipsum text in markdown format.

First we’d create our new feature branch called feature/lipsum.

git checkout -b feature/lipsum develop
echo "# Lipsum" > lipsum.md
git add lipsum.md
git commit -m 'Create lipsum file.'

You could have also prefixed the feature like so: feature-lipsum. Both methods are perfectly acceptable.

Now that we have our file setup, let’s go ahead and populate it with some information.

Here’s our lipsum.md file.

# Lipsum

Lorem markdownum atque miracula ora; sua vilibus dira silva erat nondum? Sit et
tibi hoc adversas nimia partem labitur terram. Te caput tenuique inde, remos
ceras nisi virtus lupi, ruit. Vimque quid; se mihi annum faciemque iamdudum.

1. Irascitur egesto cornua putet et chelydri exuit
2. Dum terras velint neutrumque amborum fore ducibusque
3. Ducit sonant siqua
4. Sed auras grandior siquis silentia facta
5. Dat meminisse
6. Fugiunt mea virus solidumque

## Vestigia excedere

Saltibus nequeunt studio *et resonabat Bacchiadae*. Inque *in mihi* in se nullam
deum utiliter, ad ipse; flet. Instabilis capiti ad grandaevumque quibus. Requies
hoc utinam timetque contudit. Rota pecudesque teneri.

Et mihi, tu Cyllenius iracundique iusta exasperat; sprevere discors, purpureum,
sequar in videt locis. Turba se clipeata pater Meropisque unda lacrimas herbas
obstabat Aeacides instat impetus procumbere urbem, verba. Agros necari, iam
bibuntur fratris dare dedit, inmurmurat caeli Herculeos quoque.

## Quin inplumes vota sunt Eleusin

**De tumulo**, et potest incandescit Minervae foliis glaebas iuncique: superest
qua tu Cupido haec. Viros cumque capillos unum, commentaque armaque vescitur,
dicebar? Ait partim, molire velant sub formae Rhodopen arte.

## Phoebus fugio

Stabat mole una: massae, aut **iam inque latarumque** ille; delphines litus:
status. **Causa** eripuit adhuc deque, et nec qui, sic unus quid simulacra
Alcathoen et.

Now let’s commit our change.

git add lipsum.md
git commit -m 'Add content to lipsum file.' 

So now assuming that all of our changes are completed, we can then go ahead and merge the new feature into our develop branch like so.

git checkout develop
git merge feature/lipsum
git branch -d feature/lipsum

After we merged the feature, we then went ahead and deleted that branch as it was no longer needed.

Release Branches

Next let’s set up our release branch for our changes. Release branches are typically prefixed with either release/ or release- followed by the version number. This essentially creates a frozen version of the develop branch, this way you can work on hardening the release before merging it into master.

Let’s look at how we would setup our release branch, merge any changes made for our release, and then merge it into master. This is similar to our feature branches, but instead dedicated to polishing up anything we need prior to merging into master.

git checkout -b release/0.1
git add lipsum.md
git commit -m 'Correct grammer in headers.'
git checkout master
git merge release/0.1
git push

We’ll also want to sync these changes into our develop branch.

git checkout develop
git merge release/0.1
git push

Finally we’ll want to delete our release branch and tag our current master to the version of changes implemented.

git checkout master
git branch -d release/0.1
git tag v0.1
git push origin v0.1

Hotfix Branches

Now let’s assume a user, or yourself, discover an issue that needs to be corrected. We’d create the hotfix based off of the master branch like so.

git checkout -b hotfix/grammer-mistake master

Next you’ll want to make your change and merge it into both master and develop.

git add lipsum.md
git commit -m 'Correct typo.'
git checkout master
git merge hotfix/grammer-mistake
git checkout develop
git merge hotfix/grammer-mistake

Lastly, we’ll want to push our changes to our remote repo, while also tagging our new version and deleting our hotfix branch.

git branch -d hotfix/grammer-mistake
git checkout master
git push
git checkout develop
git push origin develop
git checkout master
git tag v0.2
git push origin v0.2

And that’s all there really is to it. Getting yourself and your team in the habit of following some sort of convention, even if its not this one will improve your development workflow greatly for not only yourself but your team as well.