git-branch-strategy

Git Branch Strategy

Mission

Choose, explain, and document a Git branching strategy for a generic software project.

Startup

1. Read .git-workflow.yml if present.
2. Resolve shared resources from ${CLAUDE_PLUGIN_ROOT}/shared; if running outside Claude Code, use the nearest ancestor containing git-workflow-skills.yml.
3. Inspect Git state with git status --short --branch, git branch -vv, and git remote -v.
4. Do not mutate files or branches until the user confirms the strategy.

Inputs

• Team size and release frequency.
• Default branch and integration branch.
• Whether old versions must be maintained.
• Whether CI and protected branches are available.

Workflow

1. Infer the current repository state.
2. Compare the project against simple-dev-main, release-branch, and trunk-based.
3. Recommend one model with branch rules and merge paths.
4. Produce a .git-workflow.yml snippet.
5. Optionally produce a branch policy document from shared/templates/branch-policy.md.

Safety Gates

Creating branches, modifying .git-workflow.yml, or changing branch protection requires explicit user confirmation.

Template Override

See shared/references/template-override.md for the standard override mechanism.

Shared Resources

• shared/references/branch-models.md
• shared/references/safety-rules.md
• shared/references/template-override.md
• shared/templates/branch-policy.md (use resolve_template("branch-policy.md") to respect overrides)
• shared/scripts/check_branch_name.py

Handoff

• Start normal development: use git-feature-workflow.
• Define commit rules: use git-commit-discipline.
• Publish a version: use git-release-workflow.

Output

Return the recommended model, branch rules, protection suggestions, config snippet, and next step.