Team Workflows: GitHub Flow, Git Flow and Trunk-Based
Compare the branching workflows real teams use — GitHub Flow, Git Flow and trunk-based development — plus commit conventions and branch protection rules.
On this page 11 sections
Introduction
Git does not tell a team how to use branches. A workflow is an agreement about it: which branches exist, where new work starts, how changes are reviewed and how releases happen. When you join a company or an open-source project, one of the first things to learn is which workflow they follow. Three are by far the most common.
- How GitHub Flow, Git Flow and trunk-based development work.
- Which kind of team each workflow suits.
- How to write Conventional Commits messages.
- How branch protection keeps main safe.
GitHub Flow
GitHub Flow is the simplest workflow and the one you have been practising. There is one long-lived branch, main, which is always ready to deploy. Every change happens on a short-lived branch and arrives through a pull request.
It suits web applications and services that deploy continuously, small and medium teams, and most personal projects. Its strength is simplicity; its weakness is that it assumes there is only one version in production at a time.
Put the steps of GitHub Flow in order.
- Open a pull request
- Commit and push your work
- Merge into main
- Get a review and passing checks
- Branch off main
- Deploy main
Git Flow
Git Flow, described by Vincent Driessen in 2010, uses several kinds of branches for projects with scheduled, numbered releases:
| Branch | Purpose |
|---|---|
| main | Only released code; every commit is a tagged release |
| develop | Where finished features are integrated for the next release |
| feature/* | One branch per feature, started from and merged back into develop |
| release/* | Prepares a release: final fixes and version numbers, then merged into main and develop |
| hotfix/* | Urgent fixes started from main, merged into main and develop |
It suits software that ships versions — mobile apps, desktop software, libraries — especially when several versions must be supported at once. For a website that deploys many times a day, it adds more ceremony than it is worth; even its author now recommends simpler workflows for continuously delivered software.
Trunk-Based Development
In trunk-based development, everyone integrates into the main branch (the “trunk”) at least once a day. Branches, if used at all, live for hours rather than weeks. Unfinished features are merged early but hidden behind feature flags — settings that switch a feature on only when it is ready.
It depends on a strong automated test suite and continuous integration, because every change reaches main quickly. Many large technology companies work this way, since tiny, frequent merges almost never conflict.
Comparing the Workflows
| GitHub Flow | Git Flow | Trunk-based | |
|---|---|---|---|
| Long-lived branches | main | main and develop | main (trunk) |
| Feature branch lifetime | Days | Days to weeks | Hours, or none |
| Release style | Continuous deployment | Scheduled, numbered releases | Continuous, with feature flags |
| Complexity | Low | High | Low process, high automation |
| Best for | Web apps, small teams, most projects | Versioned products, several supported versions | Experienced teams with strong CI |
A three-person startup deploys its web app several times a day. Which workflow fits best?
Conventional Commits
Many teams add a small prefix to commit messages so the history is easy to scan and tools can generate changelogs automatically. The Conventional Commits format is type(optional scope): description:
| Type | Meaning | Example |
|---|---|---|
| feat | A new feature | feat: add dark mode |
| fix | A bug fix | fix(contact): make email address clickable |
| docs | Documentation only | docs: explain local setup in README |
| style | Formatting, no code change | style: format CSS with Prettier |
| refactor | Code change that is neither a fix nor a feature | refactor: split nav into its own file |
| test | Adding or fixing tests | test: cover contact form validation |
| chore | Maintenance tasks | chore: update live-server to 1.2.2 |
Adding ! after the type (feat!: drop support for Internet Explorer) marks a breaking change, which maps neatly onto a MAJOR version bump from lesson 14.
You fixed a bug where the contact form accepted empty emails. Which commit message follows Conventional Commits?
Protecting the Main Branch
On GitHub, repository admins can protect important branches under Settings → Branches (or Rules → Rulesets). Typical rules for main:
- Require a pull request before merging, so nobody pushes directly.
- Require at least one approving review.
- Require status checks (such as automated tests) to pass.
- Block force pushes and branch deletion.
- Require branches to be up to date with main before merging.
Protection rules turn the workflow from a promise into something GitHub enforces — even for admins, if you choose.
Common Mistakes
- Adopting Git Flow for a simple website because it looks “professional”.
- Letting feature branches live for weeks in any workflow — integration pain grows every day.
- Mixing conventions within one repository; agree on one and write it in CONTRIBUTING.md.
- Leaving main unprotected on a team repository.
Frequently Asked Questions
GitHub Flow. Even alone, working on branches and merging through pull requests keeps main working and builds habits employers expect.
GitOps applies these ideas to infrastructure: the desired state of servers and deployments is stored in Git, and changes are made through pull requests that automated tools apply. You will meet it again in DevOps and cloud courses.
No — they are one popular convention. What matters is that a team agrees on a style and that every message clearly says what the commit does.
Key Takeaways
- GitHub Flow: short branches off main, pull requests, merge and deploy — the default choice for most teams.
- Git Flow: main, develop, feature, release and hotfix branches for versioned, scheduled releases.
- Trunk-based: everyone integrates into main daily, with feature flags and strong automated testing.
- Conventional Commits (feat:, fix:, docs: …) make history readable and enable automatic changelogs.
- Branch protection rules make GitHub enforce reviews and checks on main.
Summary
You now know how teams organise their work around Git. One lesson remains: what to do when things go seriously wrong — lost commits, deleted branches, and changes that need moving between branches.