Git ops

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 repo contains submodules or gitlinks:

• A 160000 entry is a parent-repo pointer, not normal file content.
• If submodule source changed, commit and push inside the submodule first, then commit the parent pointer.
• Branch switching can leave an untracked submodule working tree on disk. Inspect it as submodule state; do not delete it as noise without confirmation.

Finish

Always report the final Git state:

• current branch
• start point or target branch used
• commit hash / merge hash when created
• push result when pushed
• verification commands run
• whether git status --short --branch is clean
• skipped files, especially DontCommit / DoNotCommit