Skip to content

Workflows

Professional Git workflows

How real teams keep main stable and ship with confidence — an opinionated default, plus the common alternatives.

The recommended team workflow

  1. 1

    Protect main

    Keep main deployable at all times. Require pull requests, checks, and review.

  2. 2

    Sync main

    Start from the latest main before branching.

    git switch main
git pull origin main
  3. 3

    Branch per task

    Create one focused branch for each feature, fix, or task with a descriptive name.

    git switch -c feat/git-graph-zoom
  4. 4

    Small commits

    Make small, logical commits with clear messages.

    git add .
git commit -m "feat: add graph zoom controls"
  5. 5

    Push the branch

    Publish your branch and set the upstream.

    git push -u origin feat/git-graph-zoom
  6. 6

    Open a pull request

    Describe the change, link the issue, and request review.

  7. 7

    Automated checks

    Let CI run tests, linting, and builds on the branch.

  8. 8

    Address review

    Respond to feedback and push follow-up commits.

  9. 9

    Choose a merge strategy

    Squash for most small features; merge to preserve history; rebase to keep a private branch current.

  10. 10

    Merge and clean up

    Merge into main, delete the branch, and sync your local main.

    git switch main
git pull origin main
AWorkflow models

Feature branch workflow

One branch per unit of work, merged back through review.

Best for most teams and projects of any size.

GitHub flow

Lightweight: branch, PR, deploy from main.

Best for teams that deploy continuously from main.

Trunk-based development

Very short-lived branches merged into trunk many times a day.

Best for high-velocity teams with strong ci and feature flags.

Release flow

Feature branches plus dedicated release branches.

Best for products with scheduled releases and long-term support.
BMerge strategy comparison

Squash and merge

The best default for most small pull requests.

squashes

Advantages

  • Clean, readable main history
  • One commit per feature
  • Easy to revert a whole feature

Tradeoffs

  • Loses individual commit structure on main
  • Original commits stay only on the branch

Merge commit

When preserving the full story of a branch is valuable.

preserves commits

Advantages

  • Preserves complete branch history
  • Records exactly when integration happened
  • No history rewriting

Tradeoffs

  • Busier main history
  • Merge commits can clutter git log

Rebase and merge

When you want every commit preserved but a straight-line history.

preserves commitsrewrites history

Advantages

  • Linear, bisect-friendly history
  • Keeps individual commits
  • No merge commits

Tradeoffs

  • Rewrites commit hashes
  • Risky if the branch was shared

No strategy is universally correct. Choose based on branch length, team preferences, and how much history you want on main.