/git-ops

name: git-ops
description: Use when Sam asks Claude Code to create, rename, compare, commit, push, merge, promote, or clean up Git branches. Covers Sam's feature branch naming convention, safe Git pre-checks, JetBrains DontCommit handling, commit-message defaults, push and release promotion verification, branch rename upstream cleanup, branch sync comparison, and submodule/gitlink handling.

Git Ops

Scope

Use this skill for Git operation tasks. Keep project-specific runtime, build, API, environment, and release-policy details in the repo's `AGENTS.md`; keep reusable Git behavior here.

Do not expand scope silently. If Sam only asks to inspect, report findings. If Sam asks to commit/push/merge, carry that operation through verification unless blocked.

Safety Rules

Before any Git write operation:

git status --short --branch

Rules:

• Treat existing uncommitted changes as user work unless proven otherwise.
• Do not run destructive commands such as `git reset --hard`, `git checkout -- <file>`, `git clean -fd`, `git push --delete`, or force-push without explicit written confirmation.
• Use `git clean -fdn` before any real clean operation and report what would be removed.
• Prefer `rg`, `git diff`, `git status`, `git branch -vv`, `git log`, and `git show-ref` for inspection before acting.
• For remote cleanup wording, say `stale local remote-tracking refs` or `本地 origin/* 缓存`; `git fetch --prune origin` does not delete remote branches.

Feature Branch Naming

When Sam says "功能分支" or asks to create a feature branch, use:

feature/<YYYYMMDD>/<需求编码>_<功能简介>

Example:

feature/20260521/MR2026052182911_xiaomei

Rules:

• The first path segment is always `feature`.
• The second segment is the date as `YYYYMMDD`.
• Sam usually provides the date. If the date is missing, ask before creating the branch.
• If Sam provides `MMDD` only, normalize it to `YYYYMMDD` using the clearly applicable year from the task context. If the year is ambiguous, ask.
• The third segment is `<需求编码>_<功能简介>`.
• Do not invent a requirement code. If missing, ask.
• Keep `功能简介` short and branch-safe. Prefer lowercase ASCII slugs such as `hyde`, `xiaomei`, `rrl_auth`.

Given:

需求编码: MR2026051590006
date: 0528
功能简介: hyde

Create:

feature/20260528/MR2026051590006_hyde

Create Branch

Before creating a branch:

1. Run `git status --short --branch`. 2. Check whether the base branch and target branch exist. 3. If the worktree has unrelated changes, ask whether to use a separate worktree, stash, or keep the current state. 4. Refresh the remote base when network access is available.

Preferred feature-from-master flow:

git fetch origin master
git switch --no-track -c feature/YYYYMMDD/MRxxxx_short_desc origin/master
git status --short --branch

Use `--no-track` so a new feature branch does not accidentally track `origin/master`.

If Sam explicitly says to use local `master`, create from local `master`:

git switch --no-track -c feature/YYYYMMDD/MRxxxx_short_desc master

JetBrains DontCommit

Before `git add` / `git commit`, inspect `.idea/workspace.xml` if it exists:

rg -n "ChangeListManager|DontCommit|DoNotCommit" .idea/workspace.xml

Rules:

• Files in `DontCommit` / `DoNotCommit` changelists must not be committed.
• If such files are already staged, unstage only those files.
• Override only if Sam explicitly asks to include them.
• If the main worktree has DontCommit or unrelated local files, prefer a temporary `git worktree` for release promotion.

Commit And Push

When Sam says "提交推送吧" after implementation, treat commit and push as part of the task.

Before commit:

git status --short --branch
git diff --check

Rules:

• Stage only intended files.
• Keep unrelated user changes unstaged.
• Default `git commit` messages to Chinese. Code identifiers, module names, commands, paths, and proper nouns may stay in English.
• If independent topics are mixed and Sam says "拆两个", split commits by topic.
• After push, verify branch state with `git status --short --branch` and, when useful, `git branch -vv --list <branch>`.

Release Promotion

When Sam explicitly asks to merge/push into `release/sit`, `release/uat`, or a dated release branch, perform the full requested merge and push path unless blocked.

Default flow:

git fetch origin <target-branch>
git switch <target-branch>
git merge --ff-only <feature-branch>
git push origin <target-branch>

If `--ff-only` fails:

• Inspect divergence first.
• Explain why fast-forward is impossible.
• Use `git merge --no-ff -m "<中文合并信息>" <feature-branch>` only when that matches the requested promotion.

For multi-branch promotion:

• Keep the sequence explicit.
• Verify each local and remote branch tip.
• Use temporary `git worktree` when the main workspace has unrelated local changes.

Rename Branch

For branch rename requests, change the visible branch identifier exactly. Do not add code edits or content merges.

Reliable flow:

git branch -m <old> <new>
git branch --unset-upstream <new>
git push -u origin <new>
git branch -vv --list <new>
git ls-remote --heads origin <new> <old>

Rules:

• After `git branch -m`, always check for stale upstream metadata.
• Do not delete the old remote branch unless Sam explicitly asks.
• If deleting a remote branch is requested, verify the old and new refs point to the expected content first.

Compare Branches

Do not judge sync from commit message shape alone. Compare content and ancestry:

git rev-list --left-right --count <left>...<right>
git rev-parse <ref>^{tree}
git diff --name-status <left>..<right>
git log --oneline --ancestry-path <left>..<right>

Notes:

• `release/sit` may carry extra merge history while still being content-identical to `release/uat` or a feature branch.
• Tree hash plus `git diff --name-status` is the most direct content-sync check.

Submodules

When a rep