Branching Workflows

Git lets you branch any way you like, which is exactly why teams need an agreement. Without one, some people commit straight to main, others keep branches alive for months, and releases become a guessing game. A branching workflow is that agreement: which branches exist, where new work starts, how it gets reviewed and how it reaches users.

This lesson explains the workflows you will meet at work, from the simplest to the most structured, and how to choose.

Feature branch workflow

The foundation of every modern workflow is simple: main always works, and every change happens on its own branch. One branch per feature, bug fix or experiment, named after the work:

git switch main
git pull
git switch -c feature/delivery-areas
git commit -am "List delivery areas on contact page"
git push -u origin feature/delivery-areas

Already on 'main'
Your branch is up to date with 'origin/main'.
Already up to date.
Switched to a new branch 'feature/delivery-areas'
[feature/delivery-areas ea6f392] List delivery areas on contact page
 1 file changed, 1 insertion(+)
To github.com:priya-sharma/sweet-shop.git
 * [new branch]      feature/delivery-areas -> feature/delivery-areas
branch 'feature/delivery-areas' set up to track 'origin/feature/delivery-areas'.

Starting from a freshly pulled main matters: your branch begins from the latest code, so it will merge back with fewer conflicts. Prefixes such as feature/, fix/ and docs/ are a naming convention many teams use; Git treats the / as part of the name.

GitHub flow

GitHub flow adds pull requests and deployment to the feature branch idea. It is lightweight and the most common choice for websites and apps that deploy often:

1. Create a branch from main.
2. Commit and push your work to the branch.
3. Open a pull request early, even as a draft, to start the discussion.
4. Automated checks run and teammates review.
5. Merge into main when approved and green.
6. Deploy main (often automatically), and delete the branch.

There is only one long-lived branch, main, and it is always deployable. A bug fix is just another short branch and PR. This is the flow you practised in Pull Requests & Code Review and GitHub Actions.

Trunk-based development

Trunk-based development pushes the same idea further: everyone integrates into the main branch (the "trunk") at least once a day. Branches, if used at all, live for hours, not weeks. It is used by many large engineering teams because it avoids the painful merges that long-lived branches cause.

Two practices make it possible:

• Strong CI. Every change runs the full test suite, so a broken trunk is noticed in minutes.
• Feature flags. Unfinished features are merged but hidden behind a switch, so code can reach main before the feature is ready for users.

A feature flag can be as simple as a setting that the code checks. Here the new online-payment button is merged to main but only shown when the flag is on:

const flags = {
  onlinePayment: false, // turn on when the payment gateway is approved
};

function renderCheckout(order) {
  const parts = [`Total: ₹${order.total}`];
  if (flags.onlinePayment) {
    parts.push("[Pay online]");
  }
  parts.push("[Pay at the counter]");
  return parts.join(" ");
}

console.log(renderCheckout({ total: 1299 }));

Total: ₹1299 [Pay at the counter]

Real projects keep flags in configuration or a flag service so they can be switched without a new deployment, and they delete each flag once the feature is fully live.

Release branches

Some software cannot deploy continuously: mobile apps go through app-store review, and installed products need supported old versions. These teams cut a release branch such as release-2.4 from main when a version is feature-complete. Only bug fixes go into it, it is tagged (v2.4.0, v2.4.1), and fixes are copied back to main (or from main to the release branch) with git cherry-pick. New features continue on main meanwhile.

Git Flow: the older, heavier model

You will still meet Git Flow, a model published in 2010. It uses two long-lived branches, main (only released code) and develop (integration), plus three kinds of short-lived branches:

Git Flow suits products with planned, versioned releases, but it adds many merges and a branch (develop) that drifts from what users run. Its own author later noted that teams doing continuous delivery of web apps should prefer a simpler flow such as GitHub flow. If you join a team that uses Git Flow, follow it; for a new web project, start simpler.

Choosing a workflow

Whichever you pick, write it down in CONTRIBUTING.md, protect main with branch rules, and keep branches short-lived.

Common mistakes

• Long-lived feature branches. A branch open for a month collects huge conflicts. Merge small pieces often, hiding unfinished parts behind a flag.
• Committing directly to main "just this once". It skips review and CI. Protect main so it cannot happen.
• Copying a heavy workflow you do not need. Git Flow on a two-person website adds ceremony without benefit.
• Never deleting merged branches. A list of 200 stale branches hides the five that matter.

Key points

• A branching workflow is a team agreement about branches, reviews and releases.
• Feature branch workflow: main always works and every change lives on its own short branch.
• GitHub flow: branch, pull request, review and checks, merge, deploy; main is always deployable.
• Trunk-based development integrates into main at least daily, relying on CI and feature flags.
• Release branches and the older Git Flow suit versioned products; most web projects should start with GitHub flow.

git switch main
git pull
git switch -c feature/schedule-page
git add schedule.html
git commit -m "Add fest schedule page"
git push -u origin feature/schedule-page
git switch main
git pull
git branch -d feature/schedule-page