Free lesson · Git Mastery

Git Workflows Overview

Medium7 min readgit

Git Workflows Overview

A note from Brandon Carter, Principal SDE at AWS S3 and Head of Curriculum.

The Social Layer on Top of Git

Modules 1 through 10 have covered the mechanical operations of Git - commits, branches, merges, rebases, remotes, tags. These are the primitives. They tell you what Git can do; they don't tell you what a team should do.

A workflow is a convention for how a team uses Git's primitives together. Same commands, different patterns for combining them. Two teams running identical Git versions can have radically different daily experiences depending on which workflow they follow. The differences play out in code review pace, release cadence, integration pain, history readability, and how new engineers ramp up.

After sixteen years across IBM, Oracle, Stripe, and AWS, I've watched dozens of workflows in action - some that worked beautifully, some that produced constant pain, several that worked for one team and were disasters for another. The pattern: workflows aren't right or wrong absolutely. They're appropriate or inappropriate for specific contexts. A workflow that works for a five-person startup will break under the weight of a fifty-person service team. A workflow built for a service team will be overkill for a small project.

This module covers the workflows you'll encounter and how to choose between them. This topic is the framing - what workflows are, what dimensions they vary along, and what questions to ask before adopting one.

The Dimensions Workflows Vary On

Five dimensions distinguish workflows from each other:

Where does the canonical branch live? Some workflows have one canonical branch (often called main or master or trunk). Others have multiple canonical branches with different roles (main for production, develop for ongoing work, release/* for stabilization).

How is work integrated? Some workflows merge feature branches directly. Some require rebasing first. Some use merge commits as the integration record; others squash everything into single commits.

How long do branches live? Some workflows favor very short-lived branches (hours to a day). Others tolerate or expect long-lived branches (days to weeks).

How does code review fit in? Some workflows require code review before merging to canonical branches. Others trust the commit and review afterward. Module 12 covers pull requests and code review in depth.

How are releases produced? Some workflows have explicit release branches with their own stabilization periods. Others release directly from the canonical branch on a regular cadence.

Every workflow makes choices on each dimension. The choices interact - a workflow with long-lived branches usually needs explicit release branches; a workflow with short-lived branches usually doesn't.

The Workflows This Module Covers

Centralized Workflow (Topic 11.2). Everyone commits to a single shared branch. Closest to traditional centralized version control (SVN, Perforce). Simplest to start with, doesn't scale beyond very small teams.

Feature Branch Workflow (Topic 11.3). Each unit of work happens on a dedicated branch, merged back to the canonical branch when complete. The default for most modern teams.

GitFlow (Topic 11.4). A structured workflow with explicit develop, release/*, hotfix/*, and feature/* branches. Highly prescriptive; works for teams with formal release cycles.

GitHub Flow (Topic 11.5). Simplified workflow built around continuous deployment - branch, commit, PR, merge, deploy. The default for many web service teams.

Trunk-Based Development (Topic 11.6). Everyone commits to the canonical branch with very short-lived branches (hours, not days). Relies heavily on feature flags and rigorous CI. Used by some large-scale engineering organizations.

Forking Workflow (Topic 11.7). Each contributor works from their personal fork; integration happens via pull requests across forks. The standard for open source projects and for some highly-distributed enterprise teams.

Choosing a Workflow (Topic 11.8) covers the decision framework - questions to ask before adopting any specific workflow.

A Common Misconception

A pattern I've seen at IBM and Oracle especially: teams treating their workflow as "the right way to use Git." It isn't. Workflows are tools. Different contexts justify different tools.

When I joined the AWS S3 team as a Principal Engineer, the team's workflow was a particular flavor of trunk-based development with feature flags. It worked extraordinarily well for our context - large team, high-stakes service, mature feature flag infrastructure. The same workflow would have been wrong for a five-person startup; the overhead of feature flag plumbing wasn't justified at that scale.

The conversion goes both ways. A startup workflow that ships fast with minimal process won't scale to a team of fifty. A enterprise workflow with heavy process will choke a startup.

The principle: match the workflow to the context. The workflow is not your identity.

When Workflows Fail

Workflows fail in patterns. The failures are predictable once you know them:

Too much process for the team size. Five engineers running GitFlow burn time on ceremony that doesn't produce value at their scale. The release branch coordination overhead would be appropriate for fifty engineers; for five, it's friction.

Too little process for the team size. Fifty engineers running pure trunk-based without feature flags get into constant trouble - broken builds, half-shipped features, hard-to-revert incidents. The structure that would have prevented the chaos is missing.

Inconsistent application. Half the team follows the workflow, half doesn't. The half that doesn't creates problems for the half that does. Even a flawed workflow consistently applied is better than a perfect workflow applied inconsistently.

Workflow built for the wrong stage. A workflow that worked at the previous company size doesn't get updated as the company grows. The team outgrows it but doesn't adapt.

Workflow adopted because it's prestigious. GitFlow at a company that doesn't need it because "real companies use GitFlow." Trunk-based at a company that doesn't have the infrastructure because "Google uses trunk-based." Adoption-by-imitation rather than by analysis.

I've seen each of these. They're all preventable. The prevention requires honest analysis of the team's actual situation rather than aspiration.

A Specific Story From Stripe

When I joined Stripe in 2018, the team was running a hybrid workflow - feature branches for most work, direct trunk commits for hotfixes, no formal release branches. It worked because the team was small (low hundreds of engineers at the time), the infrastructure was mature (excellent CI, rapid rollback), and the culture supported it (engineers held responsibility for what they shipped).

Two years later, the company had grown substantially. The same workflow started creaking. Direct trunk commits were producing surprises. Feature branches were lingering longer because integration was harder. The team made adjustments - stricter PR requirements, automated checks before merge, branch protection rules.

The workflow evolved with the company. The principle remained: match process to current reality, not to historical convenience or future aspiration.

The Question to Ask First

Before adopting any specific workflow, ask: what problem are we trying to solve?

Common answers and what they suggest:

• "Integration is painful and we're stepping on each other" - usually points toward shorter-lived branches and more frequent integration
• "We're shipping bugs to production" - usually points toward more review, more testing, more staging
• "Releases are stressful" - usually points toward release branches or release trains
• "New engineers can't figure out our process" - usually points toward simpler workflow with better documentation
• "We can't ship hotfixes quickly" - usually points toward explicit hotfix paths
• "Code review takes forever" - usually points toward smaller PRs, better review tooling

The workflow is downstream of the problem. Adopting a workflow without identifying the problem first usually means the workflow doesn't address what actually hurts.

A Pattern at AWS S3

The S3 team's workflow has evolved over the years. The current shape:

• Trunk-based development for most work
• Short-lived feature branches (hours to days)
• Heavy use of feature flags for risky changes
• Required code review for every change
• Automated CI gates before merge
• Continuous deployment to staging
• Multi-stage rollout to production with monitoring
• Explicit release tagging for tracking

The combination matches the team's context - large team, very high-stakes service, mature infrastructure, strong code review culture. A different team with different stakes would justify a different combination. The pattern is not "this is the right workflow" but "this is the workflow that matches our context."

What Comes Next

The remaining topics in this module cover specific workflows in detail. Topic 11.2 starts with the simplest - the centralized workflow. The progression moves through more elaborate patterns to the structured GitFlow and the lightweight modern alternatives. Topic 11.8 closes the module with the choice framework.

What Goes Wrong

Warning: Common workflow-level mistakes:

Adopting a workflow without identifying the problem it solves. Process for process's sake creates friction without benefit.

Treating the workflow as immutable. Workflows should evolve as the team and project evolve.

Adopting a workflow because of prestige rather than fit. "Google uses X" isn't a reason for your team to use X.

Inconsistent application across the team. Even a flawed workflow consistently applied beats a perfect workflow inconsistently applied.

Confusing workflow opinions with Git mechanics. Git supports many workflows; the workflow is a choice, not a Git constraint.

Not documenting the workflow. New engineers can't follow what isn't written down.

Try It

Exercise: Reflect on workflows:

1. Identify the workflow your current team uses. Write it down in 3-5 sentences. If you can't, the workflow probably isn't well-documented.
2. Identify three pain points in your current workflow. Be specific about what hurts.
3. For each pain point, hypothesize which dimension of the workflow contributes. Branch lifetime? Integration frequency? Release cadence? Review requirements?
4. Read about one workflow your team doesn't use. Identify what it does better and worse than your current workflow.
5. Talk with one colleague about workflow improvements. Compare your perspectives.
6. Don't change the workflow yet. Observation first; intervention later.

Back to Git Mastery