sdlc.dev

Git path · Working with others · Topic 11 of 13

Workflows: trunk-based, GitFlow and pull requests

Not started

Git doesn't care how many branches you have or what they mean; a workflow is the team's agreement about that. The two ends of the range are trunk-based development, where everyone integrates small changes into one main branch at least once a day, and GitFlow, which keeps several long-lived branches for development, releases and hotfixes. Most teams today work close to the trunk-based end and use pull requests on a hosting service to review each change before it merges.

Why it matters: Git allows any branching scheme. The one a team picks decides how often people hit conflicts, how fast changes reach users and how releases are cut.

  1. 1Trunk-based keeps one main line

    Everyone merges small changes into main at least daily, behind feature flags when unfinished. Releases come from main.

  2. 2GitFlow keeps several long-lived lines

    develop, release/* and hotfix/* branches around main suit software with versioned releases to support.

  3. 3A pull request is a proposal to merge

    It is a hosting feature, not a Git one: a branch, a diff, review comments and CI checks before the merge.

  4. 4Short branches, fewer conflicts

    The longer a branch lives, the further it drifts from main and the harder it is to merge.

1

How it works

The explanation, with examples you can run.

Trunk-based development

There is one long-lived branch, main. Work happens on short-lived branches (hours to a day or two) or directly on main in small commits, and each change merges as soon as it passes review and CI. Unfinished features are merged too, switched off behind a feature flag or hidden behind an abstraction, so integration never waits for a feature to be complete. Releases are cut from main, either continuously or by tagging, with a short release branch only if a fix has to be backported.

Why teams choose it: conflicts stay small because nobody drifts far from main, CI tests what will actually ship, and deploying becomes routine. What it demands: a fast, reliable test suite, review that keeps up, and the discipline to keep main releasable at every commit.

GitFlow

GitFlow, described by Vincent Driessen in 2010, has main holding only released versions and develop collecting finished features. Features branch from develop, a release/1.4 branch is cut for stabilisation and merged into both main and develop, and hotfix/* branches start from main for urgent fixes. Releases are tagged on main.

It fits products with explicit version numbers where several versions are supported at once: installed software, libraries, firmware. For a web app that deploys continuously it is mostly overhead, and in 2020 its author added a note saying exactly that and suggesting a simpler flow such as GitHub flow (branch from main, open a pull request, merge, deploy).

Pull requests

A pull request (GitLab says merge request) is a hosting-service feature: a proposal to merge a source branch into a target branch, with a diff, line comments, approvals and status checks. Git only provides the branches; the host adds the review. Habits that make them work:

  • Keep them small. A few hundred lines get a real review; a few thousand get a skim.
  • Let machines check first. Required CI checks, branch protection on main and code owners for sensitive paths.
  • Pick a merge method on purpose. A merge commit keeps the branch's commits and records the join; squash merging turns the pull request into one commit on main; rebase merging replays each commit with no merge commit.
  • Open early as a draft to share direction before the work is ready.

To try someone's pull request locally on GitHub, fetch the ref the host keeps for it:

git fetch origin pull/123/head:pr-123git switch pr-123

Whatever the workflow, the same rule from the force-push topic applies: rewrite your own branch freely, never a shared one.

2

Check yourself

3 questions. Get them all right to finish this topic.

  1. 1.What lets trunk-based teams merge unfinished features into main without users seeing them?
  2. 2.Which kind of project is GitFlow still a reasonable fit for, according to its author?
  3. 3.Where does a pull request live?

0 of 3 right so far. Get all three to finish this topic.

Go deeper