Chapter 14. Recommended team workflows
This chapter covers
- Using GitHub Flow to manage an untagged project
- Using Git Flow to manage a tagged project
- Using Mike Flow Single to manage a single-release project
- Using Mike Flow Multiple to manage a multiple-release project
You saw in sections 13.1 and 13.2 that two teams can both use Git as a version control system to manage a software project but handle branches, merging, and rebasing very differently. The different strategies for deciding how and when to branch, merge, or rebase as part of a team are called team workflows. These workflows allow for different ways of handling (or not handling) stable releases, tags, and bug fixing of previous releases. In this chapter, you’ll learn about the two most popular Git workflows and two of my personal workflows.
GitHub Flow is so named because it’s the Git workflow that came out of the GitHub organization. It was first formally described in a blog post by Scott Chacon in 2011 at http://scottchacon.com/2011/08/31/github-flow.html.
GitHub Flow is simple because it essentially involves only two types of branches: the default master branch and feature branches. A feature branch is one that is used only for the development of a single feature (or sometimes bug fix) and then deleted after being merged into another branch.
In GitHub Flow