Git Workflow

Git 工作流助手

核心原则

• 只执行用户明确要求的 Git 动作。生成提交信息不等于暂存或提交；提交不等于推送；创建 PR 不等于合并 PR、关闭 Issue 或发布 Release。
• 把工作树中已有、未跟踪和无关的修改视为用户资产，不覆盖、不回退、不混入本轮提交。
• 优先使用非交互命令。涉及历史重写、冲突选择或远程覆盖时降低自动化程度。

工作流程

1. 读取仓库规则与状态

先阅读适用的 AGENTS.md、CONTRIBUTING.md、README、提交规范和 CI 说明，再检查：

git status --short --branch
git diff
git diff --cached
git log --oneline -10
git remote -v
git branch -vv

同时识别未跟踪文件、当前分支、upstream、远程差异和已有失败。不得只看 staged diff。

2. 明确动作与文件范围

把用户请求拆成独立授权：

动作	默认权限
分析状态、生成 commit message 或 PR 文案	只读
暂存、commit	仅用户要求后执行，只选本轮相关文件
创建或切换分支	仅用户明确要求时执行；实现流程需要但未获授权时，先说明原因并取得同意
fetch、push、创建 PR	分别确认在请求范围内，不互相推导
merge、关闭 Issue、发布 Release	必须有明确授权
rebase、修改已发布历史、强制更新远程	高风险，必须明确授权并满足额外条件

存在无关改动时不得使用 git add . 或 git add -A。逐个暂存目标文件，并用 git diff --cached 复核。

3. 规划原子提交

• 根据真实 diff 判断 feat、fix、docs、refactor、test、perf 或 chore。
• 沿用仓库近期提交的语言、scope 和格式。
• 一个提交只表达一项可独立理解和验证的改动。
• Closes #123 仅在对应 Issue 确实应由该提交自动关闭时使用。

提交信息遵循：

<type>(<scope>): <简短描述>

<必要时说明原因、关键实现和兼容性>

<关联 Issue 或 Breaking Change>

4. 验证后执行