How to use Git for continuous delivery

Agile development demands shorter cycles and better source control. Here's a quick primer on using Git and the Git-flow method of handling branches, commits, and merges

delivery person carrying boxes 82775200
Thinkstock

Software delivery used to be easy. You’d write your code, team leads would add it to a build, and eventually it’d be thrown over the transom to operations, at which point you could forget about it. You might have to fix the odd bug, but it was onto the next project and the next big thing.

That’s all changed. Developers are no longer isolated from the business. They’re now part of a process that brings together everyone involved with an application’s design, development, and operation for its entire lifetime. When combined with the shift in development models, away from the age-old waterfall process to modern agile sprints, the result is a big change in the way code is delivered.

The big bang is gone. We’re now in a world where continuous integration and continuous delivery demand a change in the contents of the software engineering tool chest.

A key element of that tool chest is source control, with Git as one of the more popular tools. There’s Git integration with popular IDEs (including Eclipse and Visual Studio) and with proprietary version control platforms like Perforce. There’s even the option of local and cloud instances, so you use Git as a collaboration tool for shared and for open development, as well as letting developers take a clone of the code repository on their laptops.

Choosing a tool doesn’t solve your continuous development problems overnight, and you’re going to need to implement an appropriate workflow to accommodate new ways of writing and building code -- and to take advantage of the way Git handles code branching. Branches are a key feature of Git, making it easy to quickly take source code, modify it, add new features, and merge them back. They’re so easy to create and use that a typical Git repository can appear to be the software equivalent of a tangled ball of wool, waiting to be wound.

That’s where Git-flow comes in. Initially proposed by Vincent Driessen, it’s a way of formalizing how you use branches, as well as how your development team handles commits and merges. It’s a technique that’s rapidly become popular, and now various source control tools that use Git as a repository provide tooling for implementing Git-flow in your development teams.

Git-flow takes a logical approach to managing Git’s branches, using them to handle both feature development and software releases -- as well as to manage repositories for all your developers and your operations team. You’re not throwing away the advantages of using Git; instead, you’re streamlining what could have been a complex process.

Drilling down into Driessen’s original paper, it’s clear that the Git-flow model is designed to replicate the structure of a modern, blended devops team. At the heart of the model are two core branches: master and develop. Master is the code that’s currently deployed, with sub-branches for each release. The develop branch is the code that the development team is working from, handling merges from the various feature branches, and merging down to the release branch when ready for release. A separate hotfix branch is used for critical bug fixes that don’t depend on new features, which can be deployed as soon as they’re tested.

With centrally managed release and master branches, there’s always one point of truth for the application, and developers can build their own replica repositories with the bits they need to build their part of an app. For example, a service that has both iOS and Android mobile apps might have branches for features on both platforms, but an Android developer will only synchronize with the Android-specific branches.

This approach works well with familiar source control tools. As soon as you make a copy of a repository, it’s classed as a feature branch, and you can start to write and test code. Once a feature is ready, that branch can be merged back into the development branch, ready for release and integration back into the master branch. Tools like Atlassian’s SourceTree make it as easy as clicking a button -- then choosing the action you want.

Tools can simplify operations by offering defaults based on what you’re currently doing. If you’re in the development branch, you’ll be prompted to create a feature; if you’re in a feature, you’ll be offered the option of merging with development branch. Roles can help here, too, so a build manager would be able to access the release and production branches, while devops engineers would get access to the hotfix branch, as well as the development branch.

Git-flow makes a lot of sense as a way of managing modern software development. Feature branches can be tied to sprints and used to control burndown, giving sprint leads a view not only of what code is being developed, but also of how it’s written. Once a sprint is over, feature branches can be merged with the development branch and so on down to release.

There’s also the option of using Git-flow as a way of managing hypothesis-driven development, with multiple development and release branches, used to handle A/B tests and delivery to separate build and deployment chains. While Git-flow formalizes how you use Git, it doesn’t change why you’re using it or even what you build with it. It’s still a tool for creating as many branches as you need and handling as many merges as there are branches.

Continuous delivery needs a continuous development model (and the associated integration and deployment tooling). With Git-flow as the foundation, you can use your source code repository as the hub of a continuous delivery process, managing feature development at the same time as handling bug fixes. The same developer can be working on several branches, merging code back into the master branches when it’s ready for delivery to users as part of a new release.

Once you've set up a Git-flow repository, you’re ready to start delivering code. It’s a process that can be as slow or as fast as you want, giving you the option of monthly, weekly, daily, or even hourly build cycles. Start slow, and as your team gains experience, you can quickly increase cadence -- giving your users the best possible application at all times.

Copyright © 2015 IDG Communications, Inc.