Git Workflow Guide

Master Git workflows for effective team collaboration.

Usage

1. Choose a branching strategy that fits your team size and release cadence
2. Set up branch protection rules and required reviews
3. Write meaningful commit messages that explain WHY, not just what
4. Handle merge conflicts systematically without losing changes
5. Use Git tools effectively: stash, rebase, cherry-pick, bisect

Examples

• Trunk-based development (recommended for most teams): Main branch is always deployable. Developers create short-lived feature branches (1-2 days max). PR review, merge to main, delete branch. Deploy from main continuously. Feature flags for incomplete features. Benefits: fewer merge conflicts, faster feedback, simpler mental model. Works best with: CI/CD, automated tests, feature flags
• Commit message convention: Format: type(scope): description. Types: feat, fix, docs, refactor, test, chore. Examples: feat(auth): add Google OAuth login, fix(api): handle null response from payment provider, refactor(db): extract query builder into shared utility. Why: consistent messages enable auto-generated changelogs, easy git log scanning, and meaningful git blame
• Conflict resolution workflow: Step 1: git fetch origin main. Step 2: git rebase origin/main (prefer rebase over merge for cleaner history). Step 3: For each conflict, open the file, understand BOTH changes, choose the correct resolution (not just "accept current"). Step 4: git add resolved_file && git rebase --continue. Step 5: Force push to your feature branch (only your branch, never main)
• Git bisect for debugging: Bug introduced somewhere in last 50 commits. git bisect start, git bisect bad (current), git bisect good abc123 (last known good). Git checks out middle commit — test if bug exists. Mark good/bad. Binary search finds the exact commit in ~6 steps instead of 50. Automate with: git bisect run npm test

Guidelines

• Keep feature branches short-lived (1-3 days). Long-lived branches accumulate merge conflicts and delay feedback
• Commit early and often. Each commit should be a logical, self-contained change that doesn't break the build
• Never commit secrets, credentials, or large binary files. Use .gitignore and git-secrets to prevent accidental commits
• Rebase for local branch cleanup (squash, reorder), merge for integrating into main. Never rebase shared/public branches
• Set up pre-commit hooks: linting, formatting, type checking. Catch issues before they reach code review
• git stash is temporary — stashed changes are easy to forget. Prefer committing WIP to a branch instead