Skip to main content

Git-Flow and its changing way of cooperation amongst developers

Have you ever experienced a feeling while building new fascinating project, where all the new features are completed, tested and ready to show to your client? You’re about to start the meeting and you immediately see that something is wrong. Big red error screams in front of your screen on the page which is a glory of your weekly work. You may think - what went wrong? The most common reason is that your teammate just pushed totally unrelated feature to main branch and mistakenly broke whole app. Those things really happen. Fortunately, there’s a solution for that - you can avoid many of such situations by using Git-Flow.

What Git-Flow is?

Git-flow is a set of git extensions to provide high-level repository operations for Vincent Driessen's branching model. Basically it’s a command line helper for git which starts with git flow. It’s good to say it works on OSX, Linux and Windows.

The difference between its branches

Before I’ll go to the coding stuff I’ll introduce to you the branching model. You always start with two branches. These are:

  • Master

  • Develop

Purpose of those branches are to provide high quality bugless code. The difference between them is master branch must contain stable production code with verified business logic. Develop is for the team of programmers working together to provide new functions or features.

How it exactly works

As you probably guess the most used branch when you start a project is develop. That’s why setting it as a main branch at bitbucket or github during development process is a good idea. Each feature and bugfix should be placed in separate branch always outgoing from develop branch.

  • Those branches should be named feature/{task-id} or bugfix/{task-id} depends of the task type accordingly. This means a lot of branches but exactly this is a good approach. After feature or bugfix is finished it should be merged back to develop. For that action pull request must be created.

  • After pull request is reviewed and approved by responsible person it should be merged back into develop. If a milestone is reached it’s a good moment to create release branch. This branch should be named release/{version-number}. Version naming conventions mainly depends of the scale of the project. In big projects probably you’ll need more detailed versioning than in smaller ones.

  • The main rule for release branches is to not add any new features. Team should be focused on fixing release bugs and delivering already agreed goals. It’s good time to pass release for functional testing. Testing teams should check if:

    • features are developed according to specification

    • project works as expected on different environments and devices

Sometimes it takes few iterations to make bugless version. All bug fixes should be created form release branch and then merged back via pull request. After release is accepted by client it can be merged to master.

Visualisation of branching model

Easier collaboration?

Git-Flow is more convenient way of building rich applications. It’s very well suited to collaboration. It solves many parallel development issues and help you scale team if needed. Gives more control about what happens during all development phases. Additionally is well documented.

Releases improvement

Using Git-Flow improved our approach of software releasing. Now we are able to send smaller portions of more reliable code. Smaller releases are easier to verify. Client’s feedback is more accurate and project potential risks are easier to detect. We can improve whatever is needed at the early stage.

Additionally JIRA and Bitbucket has really good integration thanks to the naming conventions required by git flow. You’ll be able to see how many branches, commits and pull request are related to task in JIRA. Cool, right?

Some useful Git-Flow commands

# initialize git flow in existing repository
$ git flow init

# create new feature branch from develop
$ git flow feature start {task-id}

# push branch or changes made on branch to remote repository
$ git flow feature publish

# merge feature branch into develop and remove remote feature branch
$ git flow feature finish

# start new bugfix from develop branch
$ git flow bugfix start

# create new release from develop branch
$ git flow release start {version-number}


And how do you deal with similiar problems? I hope you found something interesting for you above. Are you curious about other technologies we use? Do not hesitate to contact us!

If you have any reflections on the article, catch me at ;)

Where should we send price of that project?