Manage Mobile App Development and Release with Git-flow

Git is an amazingly powerful version control system, and git-flow helps you use that power in a coherent and safe fashion.

I am a huge fan and proponent of git. It offers an incredible mix of flexibility, speed, tools and widespread adoption.

Here’s a rundown of how it works in a running project: 

Only two long-running branches: master and develop

Git-flow provides the ability to always know you can get the latest stable, test-hardened code by pulling the master branch. This is all of the code that made it into the last App Store release and it’s been thoroughly tested prior to release.

Nothing should make it to master without being hardened and ready for real world use.

To enforce the rule that master is only production-ready code, changes are always made in develop. Develop is the current state of what will be in the next release, where all individual developers will integrate their code and create the next set of features. While features may still need integration testing, nothing should make it to develop unless the developer has tested it locally and feels it is ready for more thorough QA.

Feature branches: where developers do their work

Now you might ask, if develop is supposed to only be code that’s ready for release pending testing, where do developers put what they’re working on? This is critical for features that might require a considerable amount of work. The whole point of source control is to check things in regularly, after all. The answer is feature branches.

You can create a feature branch locally at any time. Using the git flow defaults, the branch will be named something like feature/new_shiny. Once that’s safely separated out from develop, developers are free to commit as often as necessary. When a feature reaches a releasable state, the feature branch is then folded down into develop and removed. Half-finished code never touched develop, and the developer was free to commit as often as necessary.

Release branches: managing rollout of the next version

When the develop branch has reached a state where the features are in develop and ready for release, a release branch is created from develop. Builds are created for testers and developers will commit any fixes for bugs discovered directly to the release branch.

As your team processes the release, fixes bugs, and iterates this version into a releasable state, ongoing development for new features can resume in both feature branches and develop, because this release’s code is safely separated out in the release branch. When a release is ready to be shipped to the App Store, it is clearly tagged with the release number and then folded into both master and develop. Again, only code that is tested and approved for production release goes into master. Folding it back down into develop means that any bugs present in code before testing get fixed when it merges back down.

Hotfix branches: how to fix problems in production

What happens when you miss something and a bug makes it to production? Fear not, hotfix branches have you covered. Unlike release branches they will be created from master, not from develop. Developers can then commit the specific fixes for the bug directly to the hotfix branch. Testing builds are created from hotfix and the team validates that the bug is gone. The hotfix is clearly tagged with the version and folded back into master and develop. This is another way of ensuring that only tested and production-ready code makes it into master.

One last pro-tip: Get the command line tools, or use a tool like Source Tree with them built in. It’s much easier to understand the principles outlined above, but automate the individual steps via tools.