f7ab6dbbb8
All checks were successful
Push & PR Check / check (push) Successful in 50s
批量分发实调反噬实锤：分支策略表/Agent 按钮清单/降级约定/启动协议 第 4 条曾写在 MANAGED 托管块内，v1.6.0/1.11.0 块升级原位覆盖时被抹。 全部恢复至块外「炼境自身约定」区，教训入决策记录（本地定制严禁写 进托管块）。顺带：块外与块内重复的通用约束去重（单一事实来源）、 lefthook 补齐 blueprint-gate/conventional/feature-confirmed 检查段 （verify_onboarding 复验 7/7）、收编 envoy/blueprint-gate 接入产物。 Rules-Applied: R13
103 lines
3.6 KiB
Markdown
103 lines
3.6 KiB
Markdown
# Git 工作流 — AI Agent 操作指南
|
||
|
||
> 把此文件粘贴给任何 AI Agent，让它了解本项目的 git 工作方式。由炼境接入包分发。
|
||
> `ONBOARDING_MANAGED` 标记块由炼境版本化管理（重跑接入包可原位升级），块外可自由补充项目特有约定。
|
||
|
||
<!-- ONBOARDING_MANAGED_START version="1.5.0" -->
|
||
|
||
## 分支策略（复杂度感知）
|
||
|
||
```
|
||
main/master ← 主分支，保持稳定
|
||
↑
|
||
├── 简单改动 → 直接 push main/master
|
||
└── 功能性改动 → feat/<name> 分支 → PR → main/master
|
||
```
|
||
|
||
**简单改动（直接推主分支）**：bug fix、chore、docs、style、单文件小改，行为对外无变化。
|
||
|
||
**功能性改动（开 feat/* 分支 + PR）**：新功能、重构、涉及多模块的 refactor。由 agent 根据改动文件数和性质自判，无需蓝图标签。
|
||
|
||
分支命名：`feat/<功能简述>`，如 `feat/login-sms`、`feat/order-pagination`。
|
||
|
||
## Commit 规范（lefthook 强制）
|
||
|
||
格式：`<type>(<scope>): <描述>`
|
||
|
||
| type | 用途 |
|
||
|------|------|
|
||
| `feat` | 新功能 |
|
||
| `fix` | Bug 修复 |
|
||
| `chore` | 配置、依赖、脚本 |
|
||
| `docs` | 文档 |
|
||
| `refactor` | 重构（不改功能） |
|
||
| `ci` | CI 配置 |
|
||
| `perf` | 性能优化 |
|
||
| `style` | 代码格式 |
|
||
| `test` | 测试 |
|
||
|
||
`scope` 用「模块/子模块」二级结构（如 `auth/login`、`api/user`、`db/order`），对应项目功能模块。
|
||
|
||
```bash
|
||
git commit -m "feat(auth/login): 新增手机号登录"
|
||
git commit -m "fix(api/user): 修正分页 off-by-one"
|
||
```
|
||
|
||
> 炼境会解析这些 commit 的 type/scope 作为飞轮数据：`fix` 计入返工率、`scope` 归到模块。
|
||
> **commit 写得越规范，飞轮数据越准。**
|
||
|
||
## Rules-Applied trailer（规则命中回传）
|
||
|
||
若本次任务中触发过项目约定规则（见项目 CONVENTIONS.md 或 `.blueprint/CONVENTIONS.md`），
|
||
在 commit message 末尾追加一行 trailer（与正文空行分隔）：
|
||
|
||
```
|
||
feat(auth/login): 新增手机号登录
|
||
|
||
Rules-Applied: R01,R05
|
||
```
|
||
|
||
- 只记录**真实触发**（主动检查或执行）的规则，未触发则整行省略
|
||
- 炼境自动解析此 trailer 做「规则命中 × 返工」交叉统计，是 CONVENTIONS 置信度进化的数据来源
|
||
- 凭空罗列会污染数据——宁缺毋滥
|
||
|
||
## 一个 commit = 一件独立的事
|
||
|
||
不要 `git add -A` 一次提交所有。按功能分批：
|
||
|
||
```bash
|
||
git add <相关文件>
|
||
git commit -m "feat(模块): 一件事"
|
||
```
|
||
|
||
## PR 大小控制
|
||
|
||
PR 别攒太大（建议每 3~5 个 commit 或几百行内就开一次），否则 CI code review 易超时失效。
|
||
「所有检测通过」≠ 代码被审查过——大 PR 即使 CI 全绿，review 可能已静默失效。
|
||
|
||
## PR 创建（炼境托管项目）
|
||
|
||
本项目由炼境管理，MCP 已注入且 `.claude/liangjing.json` 含 `project_id`。
|
||
炼境 MCP 是单一全局服务器 `lian-jing`，所有工具显式传 `project_id` 寻址，无需 group_id。
|
||
|
||
**推送分支后，通过炼境 MCP 创建 PR，禁止用 curl + git credential fill 提取 token：**
|
||
|
||
```
|
||
1. Read .claude/liangjing.json → 取出 project_id
|
||
2. 调用 MCP 工具 create_pull_request：
|
||
{ "project_id": "<id>", "head": "feat/<name>", "base": "main",
|
||
"title": "<Conventional Commits 格式>", "body": "<变更摘要>" }
|
||
3. 炼境内部用存储的 Gitea 凭证调 API，返回 pr_url
|
||
```
|
||
|
||
若炼境未运行（MCP 不可用），降级方案：去 Gitea 网页手动创建 PR。
|
||
|
||
## 常用命令
|
||
|
||
```bash
|
||
git status --short
|
||
git log --oneline -10
|
||
git reset --soft HEAD~1 # 撤销最后一次 commit（保留改动）
|
||
```
|
||
<!-- ONBOARDING_MANAGED_END -->
|