From Individual Git to Team Git
The Git basics covered in the Programming section of Vol. 2 — committing, pushing, pulling, and basic branching — are adequate for individual projects but become insufficient when teams of multiple developers work on the same codebase simultaneously. The questions that arise in team Git usage: When should a developer create a new branch? When should branches be merged? How do teams coordinate to avoid conflicting changes? What happens when two developers need to make changes to the same file?
Team Git workflows are the conventions — the agreed rules about how branches are named, when merges happen, what the merge process looks like, and what protections exist on specific branches — that coordinate multiple developers working on the same codebase without producing constant conflicts and confusion. Understanding the major workflow patterns and their trade-offs helps evaluate which is appropriate for a specific team’s size, release cadence, and collaboration style.
Trunk-Based Development: The Simplicity Approach
Trunk-based development (TBD) is the simplest Git workflow: everyone on the team commits directly to the main branch (the trunk) or works on very short-lived branches (typically less than a day) before merging back. Large features are developed behind feature flags rather than long-lived feature branches. Continuous integration tests run on every commit, and the main branch is always in a deployable state.
TBD’s strengths: it eliminates the complex merge conflicts that long-lived branches create, makes integration testing continuous rather than at merge time, and maintains the simplicity of a single always-deployable branch. Its requirements: a comprehensive test suite that catches regressions quickly (you can’t merge frequently to main without reliable tests), a culture of small commits and frequent integration rather than large batches of work merged after days or weeks, and feature flag infrastructure for partially-complete features that need to be deployed but not yet activated.
Gitflow: The Structured Alternative
Gitflow defines a branching model with specific branch types for specific purposes: main (production code only), develop (integration branch for next release), feature branches (individual features developed off develop and merged back to develop when complete), release branches (created from develop when a release is being prepared, allowing bugfixes without merging new features), and hotfix branches (created from main for urgent production bug fixes that need to skip the normal release cycle).
Gitflow’s strengths: it provides clear structure that teams can follow consistently, it explicitly handles the common scenarios (feature development, release preparation, production hotfixes) with defined processes, and it separates production code (main) from development code (develop) in a way that reduces the risk of accidentally deploying partially-complete work. Its weaknesses: it’s complex (multiple long-lived branches to manage), the long-lived develop branch creates large merge conflicts that infrequent integration exacerbates, and it’s more process than small teams typically need.
GitHub Flow: The Middle Ground
GitHub Flow is simpler than Gitflow but more structured than trunk-based development: developers create feature branches off main, work on the branch, open a pull request for code review when the work is ready, and merge to main after review approval. Main is always deployable. There are no develop or release branches; deployment happens from main on a continuous or scheduled basis.
GitHub Flow suits teams that deploy frequently (multiple times per week or continuously), have a code review process they want to enforce, and want the simplicity of a single main branch without the complexity of Gitflow’s multiple long-lived branches. Most small to medium teams doing web development use GitHub Flow or a close variant. The pull request process it creates is a natural point for automated testing, code review, and discussion before changes enter the main branch.
The Conventions That Matter Beyond the Model
Regardless of which branching strategy a team uses, the conventions that most consistently improve team Git experience: clear, consistent branch naming (feature/user-authentication, fix/login-timeout, chore/update-dependencies tells more than branch1 or johns-work), descriptive commit messages that explain why the change was made (not just what — the diff shows what, the commit message should explain why), small commits that represent coherent changes (easier to understand, easier to revert if needed, easier to cherry-pick to another branch), and protected main branches that require pull request approval before merging (preventing accidental pushes to production and ensuring all changes go through review).
The team that has a consistent, documented Git workflow — even a simple one — has fewer coordination problems than the team that’s making ad hoc decisions about when and where to commit. The documentation doesn’t need to be elaborate; a one-page team guide that answers ‘how do I start a new feature?’ and ‘how do I merge my work into the main codebase?’ is sufficient to onboard new developers consistently.