Using Git Flow for Android Development

Developing in a small team is pretty manageable as you generally see the code that is changing and can easily monitor these changes. Often teams don’t take full advantage of Git’s capabilities.

I have observed a couple of teams and their approaches to using git, and generally teams have two branches: master and develop. Everyone commits straight to develop. If a person is in mid-feature or testing something out, often they wouldn’t commit their work until they were done, keeping their code only on their local machines. This can be very problematic and losing code is easy to do. Releases were made by merging develop straight into master branch and tagging the commit with the release number.

This method of using git works ok for small sized teams of 2 – 3 developers. As soon as there are more developers on the team, things quickly become difficult to manage. Problems with this approach include: Branches stemming from different sources, branches created from other branches and not knowing what to do if there is a bug on production but there are new commits on the develop branch.

After getting burnt a couple of times, a colleague of mine introduced me to Git Flow.

I found a diagram which I think describes Git Flow really well.

 

Git Flow basically has the following different types of branches:

• master
• develop
• release
• feature
• hotfix

Master contains the last released version of your application, code that’s in a production ready state. It also contains all the tags for each release that was made.

Develop contains work that has recently been integrated from features. This contains work that will be delivered into the next release. This is where daily builds come from.

Feature branches are created every time a new story or bug is worked on. Feature branches are named after the relevant story number or equivalent feature name feature/feature_<story_number>. Feature branches are only created from develop.

Features get merged into develop once it solves a bug or complete a story. Using pull requests to ensure that the code has been peer reviewed before merging it into develop is also a great way to manage bigger teams.

Once a release is ready to be made, a branch named release/release_<version_number> is created from develop. This branch can then be used to make small changes. Quality Assurance and User testing then happens with the builds from this branch. Once QA has passed, the release branch gets merged into develop and into master, this is also when the commit gets tagged with the version number.

If there is an issue on production and we are in the process of adding extra features onto develop, we can easily create a hotfix branch (hotfix/hotfix_<hotfix_number>) from master. Complete the fix, merge the fix into master and create another tag for the version name.

I have found that this Branching Model is particularly useful for Android development (and probably useful for any other kind of app development) for the following reasons:

• When needing to test user upgrade processes (database upgrades etc), checking out old versions of the code and building them is really straightforward.
• Its very simple to debug issues happening on production that might not be happening on development, checking out the version of code that has the crashes and debugging from there is really simple.
• Pull requests help improve the quality of the code, things are picked up before they are merged into development. Bugs are also found quicker.
• Easy to understand method even for beginners.
• Everyone understands how to use the branches and where branches can be made from and incorporated into. There is no guess work with regards to where a branch came from and how to merge it in.
• Because we don’t release every single bug fix or feature into production, we decided using git flow is the best choice.

Not all Git clients provide support for Git flow. A list of a couple that do support Git Flow:

• Git Flow for command line 
• Android Studio Plugin for Git Flow
• Smart Git
• Source Tree
• Tower

Although some clients don’t seem to support it, you can quite easily implement Git Flow using command line, if you prefer that kind of control. 🙂

What branching model do you use? What other tools have made your development process easier?

Useful Links:

Git Flow Cheat Sheet

Learn Git Branching