Git Octo Cat

Git Workflow or GitFlow it’s a development model to work with code and git. We use extended in our code to make conflicts between developers less as possible. The reality is that Git Workflow is a branch management for organizing code and developers. There are many ways you can manage branches, we only use 2 or 3 at least, but you can combine them (we do) into more possibilities.

If you don’t know about Git or Branch you can read our previous post:


Basic Workflow

Actually, a lot of developers works alone and git give them the security of know that their code is well organized in a lot of commits. If you are a little bit organized you will do push for every functionality, for example, add a delete button to code, and you know every commit is a function. Sometimes no, simply you are developing and every time you remember to do a commit. This other way too, because you are in fast mode and can’t stop to think some details. Anyway, imagine that you need help and someone comes to help development tasks. You give them access to git and he/she clone code and begin te work. The most normal are both developers work in same branch, master.

Let we see what happens. Two developers, Barbara and Victor. One repository with one branch. Victor begins to work:

Then create a basic PHP with some HTML inside:

(yes, I forgot one p tag)

Now I add a file and commit push:

Then Barbara comes to work and Victor give access to her (we use same user in differents folders, that is similar):

Yeah! we have now same repo in two folders, it’s like Victor and Barbara works now. Then, Barbara begins to develop and add new line to index.php:

She commits and push:

And like a good coworker she tells to Victor and he pull changes:

Then Victor review changes editing index.php. Victor see p tag mistake and decide change the line and something else:

He commit and push:

And Barbara, see same mistake and make similar changes:

And …

.. Fail. What the hell!? both of them changes same lines and Barbara, second to push have a really problem. But isn’t the big problem, she tries to pull:

Git found a big conflict because changed lines are the same in two repositories. And Barbara decide to open index.php to see what happened:

Oh!! it’s terrible, a lot of awful code are new in file. Ok, let’s see what we can do. Git divides conflicts in two areas, this is the area corresponding to code in our own machine repository:

And the other part is corresponding to server repository:

Now Barbara needs to clean code deciding what part is correct and what isn’t (you can use some automatic tools, but isn’t the purpose of this article). Finally, Barbara cleans code:

And now we need to commit and push again:

The difficult isn’t to modify 2 lines and decide what line is correct. Imagine one file with thousands of code lines and three or four developers. Or Worst, ten files with thousands of modify code. The poor guy that gets merge problems have all loose day looking for the code problems.


Git Workflows Type

Now we saw the big problem working with same repository and one branch. We discuss now about different ways to avoid problems with different types of workflows.

Feature Branch Workflow

After the hell of Basic Workflow or Centralized Workflow it’s easy to think to leave this kind of work. It’s a hell, a really hell. I participate in a 4 members team, a lot of years ago, working with Centralized Workflow and was a really hell. Entire weeks looses merging code, it was a nightmare.

All of my problems could have been solved used this simple way of work. Making single Branchs for every feature. The idea is simple, you make a new branch for every feature you need to implement.

Let’s explain and continue the Barbara and Victor history :)

After Victor review code decide to move to Feature Branch Workflow then he decides to create two branchs, one for add code and another for add html:

With git checkout -b newbranch can create a new branch and change to them, the important is -b option thats means “create new branch. Now we are in feature-html and we need to add some html file to our index.php, Barbara begins their work:

We remove the commented php line and add a new one at the end. Now its time to commit and push.

Now time for Victor, he needs to add some code, first we change branch and begin codification:

We have actually 3 branch with different code and need this code all together. Like Victor is master developer, he controls now the merge ad code, first integrate feature-code branch:

See the process, first change branch to master: git checkout master
Then pull code from server, we need to have latest code: git pull origin master
Then pull feature-code branch: git pull origin feature-code
Now we have merged code, we could do the same with: git merge feature-code
After code merged we need to push: git push origin master

Now we can do the same process with the other branch:

It’s the same error than before, but here resides the difference: Victor, in this case, are Team Lead, nows what happens with code and how to resolve conflicts, in difference with Barbara that just arrives at the project. Too we introduce new command: git mergetool

Maybe you haven’t configured repository with any tool, but your system won’t let you alone:

I’m assuming that open diff is there and just hitting enter:

opendiff tool

This looks better than edit directly file in editor. The tool will be different depending of your Operating System, my case is Mac OS X then this is the default tool. Just arrange some lines and finish.


Yes, we have completed our Feature Branch Workflow. If you use Bitbucket web page or Github web page for make merges is more easy and intuitive. I will talk about merge with bitbucket or github in other post.

User Branch Workflow

User Branch development isn’t recommended for any. Just is to create a branch for every person in your team and all of them do merges to master. It’s also high recommended to merge from master te person branch. I worked before with this system in a big company with a little crazy Lead Developer. It’s not a bad idea if you are a small teams (two persons), but with big teams it’s insane.

No examples here, just wanted to commented the option.


GitFlow borns with nvie post

He explains a way to organize branches to work. It’s easy, it’s organized, it’s cool, it’s fantastic, terrific! Nvie divides work into two main branches and supporting branches. Let’s see how it works.

Main Branches

After you init your repository and add some code you need to add one branch called develop. You will have two main branches:

  • master: master branch will be production branch. The code here is the same will be on production server. Every time you merge code from develop to here means you need to upload code (or push-pull) to production.
  • develop: this is the main branch where code comes to test before production. No one uses this branch, the code only come from merges.

It’s easy to understand. Master branch is production, develop is where we test code. When you think the code is correct in develop it’s time to merge to master and upload to production.

Supporting Branches

Are three types of auxiliary branches:

  • Feature Branches: Every time you need to make new feature you can create a feature branch. You can name wherever you want, but in ebavs/ we name with feature-* convention:

Is important use –no-ff option. This means no fast forward. Fast Forward loses history when you do merge. Is important to maintain history.

  • Releases Branches: Releases Branches is where features go, you can prepare here a production release. They born in develop branch and You can name with minor or revision number. After you finish release, you can merge with master branch directly, create a tag with revision, merge release into develop and finally remove release branch:

  • Hotfix Branches: Hotfix branches are branches that born from master branch because code needs to fix urgently. After fixing the code you can merge again to master and develop. Naming is with revision number:



This tool is powerful, you can use it to organize your code or to ensure that you can develop in a quick and safe way. But if you use in a bad way could convert into a pain. GitFlow it’s a good workflow we can use actually. Maybe are others, but this one fits perfect in our day to day coding.