GitGit Workflows Overview

Git Workflows: Overview

Git is a tool, not a process. The same set of commands can be organised into radically different collaboration patterns. A Git workflow is an agreed-upon strategy for how a team creates branches, integrates code, deploys, and handles hotfixes. Choosing the right workflow for your team is one of the highest-leverage decisions you will make in a project — the wrong choice creates merge nightmares, delayed releases, and developer frustration; the right choice makes shipping feel effortless.

Why workflows matter

  • Team coordination — everyone knows where to branch from, where to merge, and when.

  • Release quality — a good workflow enforces code review and testing gates before code reaches production.

  • Conflict reduction — clear branch conventions reduce the number of developers accidentally working on the same thing at the same time.

  • Deployment confidence — when the workflow defines which branch represents production, any deployment mistake becomes immediately obvious.

  • Onboarding speed — a documented workflow means new team members can contribute on day one without asking "where do I branch from?".

  • Audit trail — release tags, merge commits, and branch naming conventions form a navigable history of when and why things changed.

Workflows covered in this section

  1. Centralized Workflow — one branch, everyone commits to it. Simple but fragile.

  2. Feature Branch Workflow — each feature or fix lives on its own branch; merges happen via Pull Requests.

  3. Git Flow — structured branching model with dedicated branches for features, releases, and hotfixes.

  4. GitHub Flow — lightweight: main + feature branches + pull requests + deploy before merge.

  5. GitLab Flow — adds environment promotion branches on top of GitHub Flow.

  6. Trunk-Based Development — everyone commits to main frequently, hiding incomplete work behind feature flags.

  7. Forking Workflow — each contributor has their own server-side fork; primary model for open-source.

How to choose a workflow

No single workflow is universally correct. The right choice depends on your team's size, release cadence, deployment frequency, and maturity. Use the questions below as a filter.

  • How often do you deploy? Multiple times per day → GitHub Flow or Trunk-Based. Weekly/monthly → Git Flow or GitLab Flow.

  • How large is the team? 1–3 people → Centralized or GitHub Flow. 5–20 → Feature Branch or GitHub Flow. 20+ → Git Flow, GitLab Flow, or Trunk-Based.

  • Do you support multiple versions simultaneously? Yes → Git Flow (release branches). No → GitHub Flow or Trunk-Based.

  • Is it open source? Yes → Forking Workflow (contributors cannot push directly). No → any of the others.

  • How strong is your CI/CD? Strong automated testing → Trunk-Based is safe. Weak CI/CD → Git Flow provides a safety net.

  • Do you use feature flags? Yes → Trunk-Based becomes viable even for large, complex features.

Comprehensive comparison of all major workflows

Workflow

Main branches

Deployment trigger

Best team size

Release cadence

Complexity

Centralized

main only

Manual, from main

1–3

Any

Very low

Feature Branch

main + feature/*

After merge to main

2–15

Regular

Low

Git Flow

main, develop, feature/, release/, hotfix/*

From main (tagged)

5–30

Scheduled (weekly+)

High

GitHub Flow

main + feature/*

Before merging to main

1–50

Continuous

Low

GitLab Flow

main, pre-production, production

Promotion between env branches

5–50

Continuous or scheduled

Medium

Trunk-Based

main (trunk) + optional short-lived branches

Continuously from main

5–1000+

Continuous (multiple/day)

Low rules, high discipline

Forking

upstream main + personal forks

After merge to upstream main

Any (open source)

Variable

Medium

Core concepts shared by all workflows

Before diving into specific workflows, make sure you are comfortable with the fundamental Git operations each workflow relies on.

Common operations across all workflows

Bash
# Create and switch to a branch
git switch -c feature/my-work

# Stage and commit
git add -p        # review changes interactively
git commit -m "feat: add search functionality"

# Synchronize with remote
git fetch origin
git pull --rebase origin main   # keep history linear

# Merge a branch
git switch main
git merge --no-ff feature/my-work   # preserve branch topology

# Tag a release
git tag -a v1.0.0 -m "Release 1.0.0"
git push origin v1.0.0

# Delete a merged branch
git branch -d feature/my-work
git push origin --delete feature/my-work
The role of Pull Requests (PRs)

Pull Requests (or Merge Requests in GitLab) are a social and technical mechanism built on top of Git. They are not a Git feature themselves but a feature of hosting platforms (GitHub, GitLab, Bitbucket). PRs serve multiple purposes in a workflow:

  • Code review gate — team members review changes before they land on shared branches.

  • CI/CD trigger — automated tests run on the branch before merge, preventing regressions.

  • Discussion thread — comments, suggestions, and approval records are tied to the specific change.

  • Documentation — the PR title and description explain the "why" behind a change, long after the context is gone.

  • Access control — protected branches require a PR to merge, preventing accidental direct pushes.

Protected branches and merge policies

Common branch protection rules (GitHub/GitLab)

Text
main / production branch protection:
  ✓ Require pull request before merging
  ✓ Require at least 1 (or 2) approvals
  ✓ Dismiss stale reviews on new push
  ✓ Require status checks to pass (CI/CD)
  ✓ Require branches to be up to date before merging
  ✓ Restrict who can push directly
  ✗ Allow force pushes  (disabled)
  ✗ Allow deletion      (disabled)
No workflow is sacred
Teams adapt workflows to their needs. Most real-world teams use a hybrid — for example, GitHub Flow with release branches for versioned products, or Git Flow simplified to remove the develop branch. Start with the closest fit and evolve it as your team grows.
Document your workflow in a CONTRIBUTING.md file
A CONTRIBUTING.md file at the root of your repository should describe your branch naming conventions, commit message format, PR process, and release procedure. This single document eliminates 80% of workflow-related questions from new contributors.
Workflow evolution path for growing teams

Typical workflow progression as teams grow

Text
Solo developer / very small team:
  → Centralized (just push to main)

Small team, occasional collaboration:
  → Feature Branch Workflow (branches + PRs)

Growing team, multiple features in flight:
  → GitHub Flow (feature branches + continuous deploy)

Large team, scheduled releases, multiple versions:
  → Git Flow or GitLab Flow

High-discipline team, continuous deployment, strong CI/CD:
  → Trunk-Based Development

Open-source project with external contributors:
  → Forking Workflow (on top of any of the above)