Git Workflows

Overview

A Git workflow is an agreed-upon convention for how a team creates branches, integrates changes, and releases code. There is no single correct choice—the right workflow depends on team size, release cadence, and deployment model. The most common patterns are feature branching, GitFlow, trunk-based development, and forking.

Syntax / Usage

Most workflows are built from the same core commands; the workflow is really the policy around them.

# Feature branch workflow: branch off main, integrate via PR
git switch main
git pull origin main
git switch -c feature/checkout-page

# ...commit work...
git push -u origin feature/checkout-page
# open a pull request, review, then merge into main

Examples

Trunk-based development keeps short-lived branches and merges to main frequently:

git switch -c fix/typo main
git commit -am "Fix pricing typo"
git switch main
git merge --no-ff fix/typo
git push origin main

GitFlow separates ongoing work (develop) from released code (main) and uses dedicated release branches:

git switch develop
git switch -c release/1.4.0
# stabilize, then merge into both main and develop
git switch main
git merge --no-ff release/1.4.0
git tag -a v1.4.0 -m "Release 1.4.0"

The forking workflow adds a personal remote for contributors without push access:

git remote add upstream https://github.com/org/project.git
git fetch upstream
git switch -c feature/docs upstream/main

Common Mistakes

• Adopting heavyweight GitFlow for a small team that ships continuously
• Letting feature branches live for weeks, causing painful merge conflicts
• Committing directly to main when the team relies on pull-request review
• Mixing long-lived and trunk-based conventions without documenting the rules
• Forgetting to sync with upstream in a forking workflow, drifting out of date

See Also

branch merge rebase