Chapter 17. Workflows and branching conventions

 

Over the past 16 chapters, you’ve learned a great deal about Git. You now know how to create and update your local repository, and you also know the fundamentals of collaborating. The various Git mechanisms (branches, tags, commit messages) are just that: mechanisms. They don’t impose any kind of policy or convention.

In this chapter, you’ll discuss matters of policy and convention. It’s important to at least get a feel for some of these, because when you collaborate with others, knowing the common conventions will prevent you from making mistakes with the code base. Your code base will be examined not just by other developers but also by automated testing systems, QA, support, and possibly even documentation. Conventions help all these audiences.

You’ll first look at the common Git features that require good conventions. These open-ended commands don’t impose any rules, so it’s up to you to figure out how to use them sensibly and consistently. What’s needed is a workflow, a sequence of steps you can follow for common source-code control tasks.

You’ll then survey two popular workflows: git-flow and GitHub flow. These common workflows appear whenever you search the Internet about Git workflows. You’ll use the appropriate Git commands to implement these flows, so you’ll get a taste for which might suit your group, or how to adapt them for your specific needs.

17.1. The need for Git conventions

17.2. Two Git workflows

17.3. git-flow

17.4. GitHub’s flow

17.5. Lab

17.6. Further exploration

17.7. Commands in this chapter

sitemap