Git Workflows

Feature Branch

One branch per feature, cut from main. Work in isolation, push when ready, merge after review. The safe default for any team. Works with any release cadence and enforces code review without added process overhead.

git done                           # sync with latest main first
git cb feature/user-auth           # create & switch
git ap && git cm "feat(auth): add OAuth flow"
git publish                        # push & track → open PR

• Branch lives only as long as the feature — delete after merge
• main stays deployable at all times
• PR review is built naturally into the flow
• Combine with conventional commits for readable merge history

GitHub Flow

A deployment-first variant of Feature Branch. main is always production-ready. Branch → commit → deploy to staging → review → merge → auto-deploy. Simpler than Gitflow; great for products shipping multiple times per day.

git cb feature/dark-mode
# develop, commit, push
git publish
# → deploy branch to staging → PR review → merge → CI deploys main

• No develop branch — main is the single integration point
• Every PR gets a preview deploy before it touches main
• Requires a reliable CI/CD pipeline to be safe
• Best for SaaS products and APIs with frequent deploys

Gitflow

Two permanent branches: main (production) and develop (integration). Features branch from develop; release branches stabilize before tagging main; hotfixes go straight to main and back to develop.

# feature work — branches off develop
git cb feature/payment develop
git cm "feat(payment): stripe integration"
# → PR to develop when done

# prepare release
git cb release/2.1.0 develop
# bump version, final fixes → merge to main + tag + back-merge to develop

# urgent production fix
git cb hotfix/2.0.1 main
# → merge to main + develop

• Use for apps with defined release windows or versioned libraries
• Supports parallel work on multiple releases simultaneously
• More overhead — branches: feature/*, release/*, hotfix/*
• Not ideal for continuous delivery — adds friction on every ship

Trunk-Based Development

Everyone commits to main (trunk) frequently — ideally multiple times per day. Feature branches are optional and short-lived (hours, not weeks). Incomplete work is hidden behind feature flags, not long-lived branches.

# short-lived branch — same-day merge target
git cb feat/quick-change
git cm "feat: add tooltip on hover"
git publish
# → fast review → merge same day → branch deleted

# direct commit with feature flag guard
git cm "feat: scaffold [FF: new-checkout] skeleton"
git ps

• Branches live ≤ 2 days — anything longer is a code smell here
• Requires fast, reliable automated tests on every commit
• Feature flags manage incomplete work already in production
• Reduces merge conflicts drastically on large teams

At a Glance

Daily Commands

These git-devkit aliases work with any workflow. Adapt branch names to your chosen model.

git done                      # sync with latest main (fetch + rebase)
git cb feature/name           # create & switch to branch
git s                         # quick status check
git ap                        # stage intentional hunks, not whole files
git ds                        # review staged diff before committing
git cm "feat(scope): message" # conventional commit
git lg                        # inspect local history
git publish                   # push & set upstream tracking
git cleanup                   # delete all merged branches