GIT-Flow. We Need Megazord Power Now!



Teamwork has always given us the power that work alone can’t. Power Rangers knew it, and now we also know it. If the individual powers of each was impressive, when invoking the Megazord, the enemy had already lost the battle. And the Power Rangers also had a methodology to assemble their Zords, creating the Megazord, GIT-Flow is going to give us this routine to work, making our project created by assembling the different functionalities developed by each of the developers involved.

One important thing in the creation of any GIT project, is that the developers have clear their role in the game, will be the rules of our GIT-Flow. These rules will define how to create the branches, how to make commits, the reasons why we are creating a branch and the place we should create it, it helps the rest of the team to understand our movements with a glance to the repository.

As we mentioned in the previous post, we use SourceTree to handle our repositories. So let’s explain how to use GIT-Flow using SourceTree. If you are a terminal-lover developers, here you have a couple of tools that will help you to use GIT-Flow using command line:

If everything is clear, let’s talk about the “rules” that define GIT-Flow:

  1. Branches: there are two main branches
    • MASTER: this branch we will have our final code for a stable version of the project. We can’t upload here code with errors or unfinished. When we do a commit in this branch we get a new RELEASE of our project.
    • DEVELOP: here the developers will create all the new functionalities, and they will integrate this code with the code of other developers. This branch is created from the MASTER branch.
  2. Auxiliary branches:
    • FEATURE: this branch is generated and will be merged always with DEVELOP. This type of branch will be created when a new functionality is going to be developed. When it is finished, the branch will be merged with DEVELOP. The name desired for this branches will be feature-name_feature.
    • RELEASE: this branch borns in DEVELOP. When it closes, it merges with DEVELOP and MASTER. This branch is for making the last changes and prepare the new release of the code. The name for this branches will be like release-name_release.
    • HOTFIX: it will be created from MASTER. When they are finished, are merged with DEVELOP and MASTER.  These branches are useful to fix little bugs in the code of a release. The difference of this branches withe the RELEASE branches, is that the HOTFIX branches are not planned.

Following these guidelines, we can organize our team based on these standards and operate in a very efficient and effective way. The idea is that the development team work using this methodology, creating an orderly space where everyone knows that movement has been made in the repository and the reasons for these changes.

Ladies and gentleman….¡GIT-Flow using SourceTree!

Once we have our repository prepared with our project as we explain in the SourceTree tutorial. You have to press the GIT-Flow button in the upper right corner, and that set up our project using GIT-Flow, you can leave the defaults names or create your own.

GIT-Flow Button

After that, clicking the same button you can create features, hot-fixes or releases, as well as close them. We recommend not erase the branches because you never know when you’ll want to come back to them after a disaster.

No rules

If you think that this model of GIT-Flow does not suit you. No problem. You can create your own model of GIT-Flow.

For example we used our own simplified model of GIT-Flow.

We created our branches DEVELOP and MASTER. Then to work on a day to day, each person created a personal branch, with its name, coming out of DEVELOP. While developing new functionality in our branch staff, our colleagues did the same in his/hers. Later we merge with DEVELOP the changes and test the functionalities to know that everything is working fine.

Our model is much simpler than the GIT-Flow explained above. But then we had a small team and the projects were usually not too large, so complicate more the GIT-Flow of our repository would be harder. We also had to work much harder in the comments Commits in order to put them well identified changes that had been implemented in that commit.

With the experience we have learned that the order of a repository is important so we recommend the first model. Avoid problems making clean repositories. Hear our advice.


Old man


Bye drunkcoders!