Git Workflow
Pick a branching model, write consistent commits and PRs, and resolve merge conflicts while shipping as a solo dev or tiny team.
Overview
Git Workflow is a journey-wide agent skill that defines branching, commit, PR, and conflict-resolution practices—usable whenever a solo builder needs to standardize Git before committing to a collaboration model.
Install
npx skills add https://github.com/affaan-m/everything-claude-code --skill git-workflowWhat is this skill?
- GitHub Flow, trunk-based, and GitFlow patterns with when-to-use guidance
- Protected main, short-lived branches, and PR-first merge rules
- Commit message and PR description conventions for reviewable history
- Merge vs rebase and structured merge-conflict resolution
- Release tagging and onboarding checklist for new contributors
Adoption & trust: 3.7k installs on skills.sh; 210k GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
Your repo has inconsistent branches, vague commits, and painful merges because nobody agreed on a Git workflow.
Who is it for?
New projects, first hires or open-source contributors, and teams moving from solo hacking to PR-based ship.
Skip if: Repos that already have enforced org-wide Git policy in enterprise tooling—duplicate only if you need agent-readable summaries.
When should I use this skill?
Setting up Git for a new project, deciding branching strategy, writing commits and PRs, resolving merge conflicts, managing release tags, or onboarding teammates to Git practices.
What do I get? / Deliverables
You adopt a documented branching strategy, PR and commit conventions, and conflict playbook your agent can follow on every change.
- Documented branching strategy and branch naming rules
- Commit and PR templates aligned to chosen flow
- Conflict-resolution and release-tag playbook
Recommended Skills
Journey fit
Useful at every journey phase - explore requirements and options before committing to a direction.
Where it fits
Fork a template repo and define main-branch protection before prototyping.
Choose GitHub Flow and branch naming before the agent opens the first feature PR.
Standardize PR descriptions and rebase policy so review stays fast pre-release.
Tag a public release and document hotfix branch rules for post-launch patches.
Onboard a contractor with the same short-lived branch rules you use for production fixes.
How it compares
Use instead of ad-hoc chat advice on rebase vs merge; skill package, not a Git hosting MCP.
Common Questions / FAQ
Who is git-workflow for?
Solo builders and small teams using Claude Code, Cursor, or similar agents who want consistent Git habits from first commit through releases.
When should I use git-workflow?
When starting a repo, choosing GitHub Flow vs trunk-based, writing commit/PR text, resolving conflicts, tagging releases, or onboarding collaborators—across Build, Ship review, and Operate iteration.
Is git-workflow safe to install?
It is documentation-style guidance; review the Security Audits panel on this page—agents may still run git commands in your repo when you pair it with shell-enabled workflows.
SKILL.md
READMESKILL.md - Git Workflow
# Git Workflow Patterns Best practices for Git version control, branching strategies, and collaborative development. ## When to Activate - Setting up Git workflow for a new project - Deciding on branching strategy (GitFlow, trunk-based, GitHub flow) - Writing commit messages and PR descriptions - Resolving merge conflicts - Managing releases and version tags - Onboarding new team members to Git practices ## Branching Strategies ### GitHub Flow (Simple, Recommended for Most) Best for continuous deployment and small-to-medium teams. ``` main (protected, always deployable) │ ├── feature/user-auth → PR → merge to main ├── feature/payment-flow → PR → merge to main └── fix/login-bug → PR → merge to main ``` **Rules:** - `main` is always deployable - Create feature branches from `main` - Open Pull Request when ready for review - After approval and CI passes, merge to `main` - Deploy immediately after merge ### Trunk-Based Development (High-Velocity Teams) Best for teams with strong CI/CD and feature flags. ``` main (trunk) │ ├── short-lived feature (1-2 days max) ├── short-lived feature └── short-lived feature ``` **Rules:** - Everyone commits to `main` or very short-lived branches - Feature flags hide incomplete work - CI must pass before merge - Deploy multiple times per day ### GitFlow (Complex, Release-Cycle Driven) Best for scheduled releases and enterprise projects. ``` main (production releases) │ └── develop (integration branch) │ ├── feature/user-auth ├── feature/payment │ ├── release/1.0.0 → merge to main and develop │ └── hotfix/critical → merge to main and develop ``` **Rules:** - `main` contains production-ready code only - `develop` is the integration branch - Feature branches from `develop`, merge back to `develop` - Release branches from `develop`, merge to `main` and `develop` - Hotfix branches from `main`, merge to both `main` and `develop` ### When to Use Which | Strategy | Team Size | Release Cadence | Best For | |----------|-----------|-----------------|----------| | GitHub Flow | Any | Continuous | SaaS, web apps, startups | | Trunk-Based | 5+ experienced | Multiple/day | High-velocity teams, feature flags | | GitFlow | 10+ | Scheduled | Enterprise, regulated industries | ## Commit Messages ### Conventional Commits Format ``` <type>(<scope>): <subject> [optional body] [optional footer(s)] ``` ### Types | Type | Use For | Example | |------|---------|---------| | `feat` | New feature | `feat(auth): add OAuth2 login` | | `fix` | Bug fix | `fix(api): handle null response in user endpoint` | | `docs` | Documentation | `docs(readme): update installation instructions` | | `style` | Formatting, no code change | `style: fix indentation in login component` | | `refactor` | Code refactoring | `refactor(db): extract connection pool to module` | | `test` | Adding/updating tests | `test(auth): add unit tests for token validation` | | `chore` | Maintenance tasks | `chore(deps): update dependencies` | | `perf` | Performance improvement | `perf(query): add index to users table` | | `ci` | CI/CD changes | `ci: add PostgreSQL service to test workflow` | | `revert` | Revert previous commit | `revert: revert "feat(auth): add OAuth2 login"` | ### Good vs Bad Examples ``` # BAD: Vague, no context git commit -m "fixed stuff" git commit -m "updates" git commit -m "WIP" # GOOD: Clear, specific, explains why git commit -m "fix(api): retry requests on 503 Service Unavailable The external API occasionally returns 503 errors during peak hours. Added exponential backoff retry logic with max 3 attempts. Closes #123" ``` ### Commit Message Template Create `.gitmessage` in repo root: ``` #