One of our development principles is that everything we do should be Repeatable and Reviewable.

The tool we use to accomplish this is the Git version control system. Git provides repeatability and reviewability, but it still allows the user to establish what their workflow looks like.

Git Flow: A Comprehensive Approach to Version Control

One well-known workflow methodology is called Git Flow, as described by Vincent Driessen. Git Flow describes how feature branches, release branches, mainline or development branches, and hotfixes are interrelated. This approach works very well for packaged software that is downloaded by users, such as libraries and desktop applications.

For many websites, however, Git Flow is overkill. Sometimes there is not a big enough difference between your mainline development and release branches to make the distinction worthwhile. Alternatively, your workflow for hotfixes and feature branches might be identical.

GitHub Flow: A Simplified Alternative

GitHub proposes an alternate workflow called GitHub Flow. GitHub Flow has some of the same elements as Git Flow, such as feature branches. But unlike Git Flow, GitHub Flow combines the mainline and release branches into a “master” and treats hotfixes just like feature branches.

This simplified model is better suited to continuous delivery models where changes can be quickly made and easily deployed, sometimes multiple times a day.

When is Git Flow Worth the Additional Complexity?

We’ve found that the additional complexity inherent to Git Flow is necessary in certain situations, such as:

• When you have discrete named or numbered releases
• When you need to freeze development on a release candidate while still continuing to develop and integrate features for a subsequent release. This may happen, for example, when a release candidate needs to be reviewed, accepted with bug fixes, or approved before being released. Development continues on a subsequent release simultaneously
• When multiple versions of the software need to be supported and maintained independently

If any of these scenarios apply, then you might benefit from Git Flow. If they don’t, you might be better served by GitHub Flow.

Conclusion

We use GitHub Flow for most of our projects. It provides almost all the functionality that Git Flow does, but is scaled back for a more adaptable workflow with less overhead.

Some of our more complex web applications call for a more complex workflow. For those project, we use Git Flow.

What workflow do you like to use for your development projects? Let us know in the comments section, or give us a call if you’d like to discuss the best approach for your project!