git-branch
Branch management for implementation. Use when you need to create a branch, switch branches, checkout, or verify branching strategy before implementing code. Do not use for commits (use git-commit), pull requests (use pull-request), or advanced git operations (rebase, merge).
- License 许可
- MIT
- 最近更新
- 2026-11-02
- Stars
- ★ 50
- Forks
- 12
01 前言 Front Matter
- name
- git-branch
- description
- Branch management for implementation. Use when you need to create a branch, switch branches, checkout, or verify branching strategy before implementing code. Do not use for commits (use git-commit), pull requests (use pull-request), or advanced git operations (rebase, merge).
03 SKILL.md 正文
Git Branch — Branch Management
Check Branching Strategy Config
cat .memory/git-config.md 2>/dev/null
If Branching Strategy is filled in, use the configured strategy. The detect-branching-strategy.sh hook automatically seeds on sessionStart.
If the config has Confidence: medium, confirm with the dev before using (see Detect Branching Strategy section).
Check Git State
Before starting implementation:
git branch --show-current
git status
git fetch origin
Remote Synchronization
If on main/master/develop, check synchronization:
git rev-list HEAD..origin/<branch> --count
| Situation | Action |
|---|---|
| Branch behind (commits behind remote) | Alert and suggest pull |
| Branch with uncommitted local changes | Alert about pending changes |
| Branch up to date and clean | Proceed normally |
If the main branch is behind:
Your branch [main] is [N] commits behind the remote.
I recommend updating before creating a new branch:
[P] Pull and continue
[I] Ignore and continue anyway (not recommended)
[A] Abort implementation
Evaluate Situation for Branch Creation
| Situation | Action |
|---|---|
| Already on a feature branch (not main/master/develop) | Use current branch |
| On main/master/develop without changes with work item | Create branch automatically (see below) |
| On main/master/develop without changes without work item | Ask if they want to create a branch |
| On main/master/develop with changes | Alert and ask how to proceed |
Automatic Creation (when there is a work item)
When the source of work is a GitHub issue or Azure DevOps work item, create the branch automatically.
Naming convention:
feature/<id>-<short-description>
Rules for <short-description>:
- Derived from the work item title
- Lowercase letters, numbers, and hyphens only
- Maximum 50 characters in the total branch name
- Remove articles, prepositions, and unnecessary words
Examples:
| Work Item | Branch |
|---|---|
| #42 "Implement user authentication" | feature/42-user-authentication |
| #108 "Add rate limiting to API endpoints" | feature/108-rate-limiting-api |
| WI 5678 "Create financial reports endpoint" | feature/5678-financial-reports-endpoint |
Action: Create branch and inform the user:
Branch created: feature/<id>-<short-description>
[C] Continue with this branch
[R] Rename branch: _
The user can rename, but the flow does not block waiting for confirmation to create.
Interactive Creation (without work item)
When the source is tasks.md (without issue/work item), ask the user:
You are on the main branch. Do you want me to create a branch for this implementation?
Suggestion: feature/<short-description>
[S] Yes, create suggested branch
[N] No, continue on current branch
[C] Create with another name: _
Existing Branch
If the user is already on a feature branch, use the current branch without additional questions.
Detect Branching Strategy
When .memory/git-config.md does not exist or does not have Branching Strategy, detect automatically:
# 1. Default branch
DEFAULT_BRANCH=$(git symbolic-ref refs/remotes/origin/HEAD 2>/dev/null | sed 's@^refs/remotes/origin/@@')
# 2. Does develop branch exist?
HAS_DEVELOP=$(git ls-remote --heads origin develop 2>/dev/null | grep -q develop && echo "yes" || echo "no")
# 3. Do release/* or hotfix/* branches exist? (GitFlow pattern)
HAS_GITFLOW_BRANCHES=$(git branch -r 2>/dev/null | grep -qE '(release|hotfix)/' && echo "yes" || echo "no")
Detection rules
develop |
release/* or hotfix/* |
Strategy | Confidence | Action |
|---|---|---|---|---|
| Yes | Yes | GitFlow | High | Save and inform |
| Yes | No | GitFlow | Medium | Ask to confirm |
| No | No | Trunk-Based | High | Save and inform |
High confidence — save automatically and inform:
Branching strategy detected: [trunk-based|gitflow]
Integration branch: [branch]
Saved to .memory/git-config.md. To change: edit the file or delete it.
Medium confidence — ask to confirm:
I detected a `develop` branch in the repository.
Which branching strategy does the project use?
[G] GitFlow (features → develop)
[T] Trunk-Based (features → main/master)
Save config
Save to .memory/git-config.md:
# Git Config
Branching Strategy: [trunk-based|gitflow]
Integration Branch: [main|master|develop]
Behavior by Strategy
| Action | Trunk-Based | GitFlow |
|---|---|---|
| Branch created from | Integration Branch | Integration Branch (develop) |
| PR target | Integration Branch | Integration Branch (develop) |
next-task returns to |
Integration Branch | Integration Branch (develop) |
04 同仓库更多 Skills
work-item-workflow
Work item workflow for implementation. Use when starting work on a GitHub issue or Azure DevOps work item to verify assignee, dependencies, priority, and capacity. Do not use for creating new work items (use work-item-creation), for suggesting the next task (use next-task), or when the work source is only tasks.md without an issue/work item.
work-item-creation
Rules and checklist for creating work items on GitHub Issues or Azure DevOps. Use when you need to create issues, user stories, tasks, epics, or features on the board. Do not use for platform configuration (use board-config), managing workflow of existing tasks (use work-item-workflow), or for comments on work items.
triage-workflow
Label-based state machine for triaging issues and work items. Manages state transitions, generates durable triage artifacts, and supports resumable sessions. Use when triaging GitHub issues or Azure DevOps work items. Do not use for creating new work items from scratch (use work-item-creation) or for managing implementation workflow of already-triaged items (use work-item-workflow).
test-discipline
Testing practices for behavior-focused, refactor-resistant tests. Use when implementing features, fixing bugs, refactoring, or adding or reviewing tests to ensure they verify intent through public interfaces and avoid tautological assertions. Also use when adding regression tests after bug fixes. Consulted by the implement agent during coding and by the review agent when validating test quality. Do not use for test strategy decisions (use complexity-analysis), for failure triage and root-cause analysis (use debugging-recovery, then after root cause is localized use test-discipline to add the reproducing regression test and fix), or for integration test infrastructure setup.
security-review
Security assessment workflow in two modes: architectural (design) and code (implementation). Use when a security trigger is detected during planning (architectural mode) or implementation/review (code mode). Covers STRIDE, OWASP, dependency scanning, Azure compliance, and GitHub security alerts. Do not use for general code quality (use devsquad.review), for threat modeling as a standalone activity, or for compliance audits.
reasoning
Record decisions and justifications during SDD agent execution, and pass structured context between agents via handoff envelope. Use when an agent needs to document decisions made (Reasoning Log) or perform a handoff to another agent. Do not use for architecture documentation (use ADRs), complexity analysis (use complexity-analysis), or debug logs.