Git, GitHub & GitHub Actions
by Sergey Okinchuk
Ch. 8Choosing a Branching Model

Chapter Nine

Team Workflows

The team agreements that turn Git from a personal tool into a shared one — branching models, pull request habits, commit conventions, repository shape, and the etiquette of contributing to projects you do not own.

5 topics

Git's mechanics are the same whether you work alone or on a team of fifty, but the decisions that matter change completely. Once more than one person touches a repository, the questions are no longer "how do I commit" but "how do branches map to releases, how big should a PR be, and what does a version number promise" — conventions, not commands.

This chapter covers those agreements: choosing a branching model by deploy cadence, keeping pull requests small enough to review, encoding intent in commit messages so tooling can version for you, deciding between a monorepo and many repos, and contributing to open-source projects whose maintainers you have never met.

Pick a branching model by release cadence
Many supported versions (SDK, on-prem)→Git Flow
Continuous deploy to one production→GitHub Flow
Many deploys/day + feature flags→Trunk-Based

Topics in This Chapter

Topic 42
Choosing a Branching Model
Git Flow, GitHub Flow, and trunk-based development compared — how to pick by deploy frequency and how many released versions you maintain at once.
Workflow
Topic 43
Pull Request Practices
Why PR size is the biggest lever on review quality, plus descriptions, turnaround norms, stacked PRs, and self-review before requesting a human.
Workflow
Topic 44
Conventional Commits and SemVer
A parseable commit format and a version-numbering contract that together let tooling derive the next version and changelog from your commit history automatically.
Workflow
Topic 45
Monorepos vs Polyrepos
One repository for many projects versus one each — trading atomic cross-project changes and shared tooling against CI complexity and blast radius.
Workflow
Topic 46
Open-Source Contribution
The social protocol of contributing to projects you do not own — scope agreement, the fork-and-PR flow, CLA versus DCO sign-off, and maintainer etiquette.
Workflow