Lesson 1 - Branching Strategies

Welcome to Branching Strategies#

You already know how to make a branch. This lesson is about the bigger question a team has to answer: which branches should exist, and how does work flow into the line everyone ships from? That agreement is called a branching strategy, and choosing one is one of the first decisions a team makes — because without a shared convention, everyone invents their own, and the repository turns into a maze. The good news is that the industry has converged on a handful of well-understood strategies. Learn the three main ones and you’ll recognize almost any team’s setup on sight.

By the end of this lesson, you will be able to:

• Explain what a branching strategy is and why a team needs one
• Describe GitHub Flow, Git Flow, and trunk-based development
• Compare their trade-offs in complexity and release cadence
• Choose a strategy that fits a given team and project

This builds on branches (Module 3) and pull requests (Module 5). Let’s begin.

What a Branching Strategy Is#

A branching strategy is simply your team’s written agreement about three things: which branches are long-lived, where new work starts, and how it gets back into the line you release from. It’s a convention, not a Git feature — Git is happy to let you do anything, which is exactly why teams need rules.

A good strategy answers everyday questions before they cause arguments: Do we branch off main or off some develop branch? How long should a branch live before it’s merged? When and how do we cut a release? The three strategies below answer those questions differently, trading simplicity against control.

GitHub Flow: Simple and Continuous#

GitHub Flow is the lightest strategy, and the one this course has been quietly teaching all along. There is one long-lived branch — main — which is always deployable. To do any work, you:

1. Branch off main with a descriptive name.
2. Commit your work and push the branch.
3. Open a pull request and get it reviewed.
4. Merge into main and deploy.

That’s the whole model. Branches are short-lived — hours or days, not weeks — and main is the single source of truth. Because there’s only one long-lived branch, there’s very little to keep straight, which is why GitHub Flow suits the majority of teams, especially those practicing continuous delivery (shipping frequently).

Its one limitation: it assumes you can release from main whenever you want. If your project ships on a fixed schedule and must maintain several released versions at once, you may want more structure.

Git Flow: Structured Releases#

Git Flow adds structure for teams with scheduled, versioned releases. It keeps two long-lived branches:

• main — holds only released, production code. Every commit here is a shipped version.
• develop — the integration branch where finished features accumulate between releases.

Around those, it defines several short-lived support branches: feature/* branches start from develop, release/* branches prepare a version for shipping (final testing, version bumps) before merging into main, and hotfix/* branches patch production urgently by branching from main directly.

This gives you fine control — you can stabilize a release while new features keep landing on develop — but it’s noticeably more complex. There are more branches to track, more merges, and more rules to remember. Git Flow shines for software with distinct versioned releases (think installed applications or libraries with support windows) and is often overkill for a continuously deployed web service.

Trunk-Based Development: One Shared Line#

Trunk-based development goes the opposite direction from Git Flow: minimize branching entirely. Everyone integrates their work into a single shared branch (the “trunk”, usually main) at least daily, in small increments. Branches, if used at all, live only a few hours before merging.

The obvious worry — “how do you merge unfinished work?” — is solved with feature flags: code paths that are merged but switched off until they’re ready, so incomplete features can sit safely in main without affecting users. The payoff is that everyone is always working against the latest code, so the painful “big merge” at the end of a long-lived branch never happens.

Trunk-based development demands discipline and strong automated testing (a solid CI pipeline catching breakage immediately), which is why it’s popular with fast-moving teams and at large scale.

Practice Exercises#

Exercise 1: Match the strategy#

A small startup deploys its web app several times a day and has no concept of “version 2.0” — they just ship continuously. Which branching strategy fits best, and why?

Exercise 2: Why two long-lived branches?#

In Git Flow, what is the purpose of having both a main branch and a develop branch?

Exercise 3: The feature-flag question#

In trunk-based development, everyone merges into one branch daily — even unfinished work. How do teams avoid shipping half-built features to users?

Summary#

A branching strategy is your team’s agreement about which branches exist and how work flows into the line you ship from — a convention, not a Git feature. GitHub Flow keeps one always-deployable main with short-lived feature branches and pull requests; it’s the simplest and fits most teams. Git Flow adds long-lived main and develop branches plus feature, release, and hotfix support branches, giving structured control for scheduled, versioned releases at the cost of complexity. Trunk-based development has everyone integrate into one shared line daily in small increments, hiding unfinished work behind feature flags; it needs strong automation but avoids painful big merges. Start simple and add structure only when a real problem demands it.

Key Concepts#

• Branching strategy — a team’s convention for organizing branches and merges.
• GitHub Flow — one deployable main + short-lived feature branches and PRs.
• Git Flow — main + develop + feature/release/hotfix branches for versioned releases.
• Trunk-based development — daily integration into one shared line, with feature flags.

Why This Matters#

The branching strategy is the single most visible workflow decision a team makes — it shapes how you start work, how you review it, and how you ship. Recognizing these three patterns means you can join almost any team and immediately understand their setup, and contribute to choosing the right one rather than cargo-culting a heavier process than the project needs. With the structure of branches settled, the next lesson tackles the content that flows through them: writing commit messages a team can actually rely on.

Next Steps#

Continue Building Your Skills#

You can now recognize the three branching strategies teams use and reason about which fits a given project. Next you’ll make the work that flows through those branches legible to everyone — by writing commit messages with a shared, professional format.