# 仓库提交与合并规范（多用户与 AI 开发必读）

本规范适用于所有开发者及其使用的 AI 编程工具。目标是保留他人的提交和业务行为，让每次修改都可审核、可追溯、可回退。开始修改前必须阅读本文件与根目录 `AGENTS.md`。

公开仓库允许所有人 Fork、修改并提交 Pull Request（PR）；直接写入本仓库仍需要协作者权限。每名开发者使用自己的账号和凭据，禁止多人共用管理员账号或把账号、密码、令牌写入代码、文档、提交信息及 PR。

## 1. 必须遵守的规则

1. **一个任务一个分支、一个独立工作目录。** 默认分支名为 `codex/<开发者>-<任务>-<唯一编号>`。不同 AI 会话不得同时修改同一工作目录，也不得共用任务分支。
2. **通过 PR 合并到 `main`。** 禁止直接向 `main` 推送；由有合并权限的维护者在审核及验证通过后合并。
3. **禁止强制推送。** 不得使用 `--force`、`-f`、`--force-with-lease`、带 `+` 的推送 refspec 或 `--mirror` 绕过拒绝。不得删除他人分支、重建仓库或替换历史来解决冲突。
4. **保留他人工作。** 未确认归属的修改、未跟踪文件、提交和业务逻辑都不能删除或覆盖。禁止为得到“干净目录”执行 `git reset --hard`、`git clean -fd/-fdx` 或全量恢复文件。
5. **先同步，再验证，再推送。** 推送成功、没有文本冲突、测试通过，都不能单独证明没有覆盖他人的业务行为；必须审核最终差异。
6. **不能把冲突处理交给一条批量命令。** 禁止对整批冲突使用 `ours` / `theirs`，或把旧版本目录复制到新版本上。意图不明时停止该部分合并，交由相关开发者或维护者确认。
7. **已推送的提交不得改写。** 共享分支和已发布的任务分支不要 rebase、amend 或 squash 后重新推送；用新的修正提交及 merge 保留历史。维护者在 PR 页面使用平台的 squash 合并功能不属于强推，但必须满足审核要求。
8. **不夹带任务之外的改动。** 不顺手重构、恢复已删除功能、修改权限或部署配置；确有依赖变更时，在 PR 中说明必要性。

普通 Git 推送会拒绝非快进更新，但无法防止“基于最新提交，却把文件内容改回旧实现”的正常提交。因此，防止覆盖既需要保留历史，也需要检查代码含义和回归行为。

## 2. 开工前：确认仓库、基线与隔离目录

先检查当前位置、远端、分支及现有修改，不要直接执行复制来的修改命令：

```bash
pwd
git remote -v
git branch --show-current
git status --short
git fetch origin
git log -5 --oneline origin/main
git rev-parse origin/main
```

记录 `origin/main` 的完整 SHA，作为本任务起始基线。确认远端确实是本项目；Fork 开发者还需核对上游仓库。浏览已有 PR，确认有没有人正在改同一模块。

如果当前目录有他人的修改，不要暂存、提交、stash、清理或覆盖它们。新建独立克隆，或在仓库内创建独立 worktree。下面的分支名和目录名仅是示例，执行前必须换成自己的唯一名称；若已经存在，换名而不是删除：

```bash
git worktree add -b codex/alice-login-001 ../cangku-alice-login-001 origin/main
cd ../cangku-alice-login-001
git status --short
```

只有已经确认由自己独占且干净的工作目录，才可直接使用 `git switch -c <任务分支> origin/main`。开始编辑前再次确认实际所在目录和分支。多个独立克隆通常更便于隔离；worktree 仍共享 Git 对象和部分仓库配置，不得随意修改全局或共享配置。

## 3. 修改与提交：仅纳入自己的任务

- 修改前阅读最新代码、调用方及相关测试，不凭历史对话或旧文件恢复整个模块。
- 共享接口、权限、数据库迁移、依赖锁文件、路由和配置是容易互相影响的区域；涉及它们时，在 PR 中标明影响范围，必要时先协调接口约定。
- 保留锁文件中其他开发者的依赖，用项目规定的包管理器生成自己的变更；不要以“重新生成”为由丢弃他人的依赖。
- 数据库迁移使用不重复的名称，兼容已有数据，不能修改已经执行的历史迁移来代替新增迁移。
- 不提交 `.env`、私钥、令牌、真实业务数据、数据库备份、`node_modules` 或无关构建产物。示例配置只使用占位值。

提交前逐项检查，并显式暂存文件；文件中混有不同任务时使用 `git add -p` 选择自己的改动。不要盲目使用 `git add .` 或 `git add -A`：

```bash
git status --short
git diff --stat
git diff
git add <本任务文件路径>
git diff --cached --check
git diff --cached
git commit -m "docs: 说明本次变更目的"
```

尖括号内容是需要替换的占位符，不要原样执行。提交信息说明修改目的，每个提交保持逻辑完整。使用自己的真实开发身份，不冒用其他开发者身份。

## 4. 推送前：同步远端并处理并行修改

先把自己的工作整理为提交，确认没有未知的未提交修改，再执行同步。以下命令应当在自己的任务分支中执行：

```bash
git fetch origin
git branch --show-current
git status --short
git log --left-right --oneline HEAD...origin/main
git merge origin/main
```

如果远端已经有同名任务分支，还必须检查 `HEAD...origin/<任务分支>`。远端出现本地没有的提交时，先查明来源，再用 `git merge origin/<任务分支>` 合入；不允许用本地版本覆盖它。不要把新分支第一次推送时不存在的远端引用当成错误而强推。

发生冲突时：

1. 使用 `git status` 和 `git diff --name-only --diff-filter=U` 定位冲突。
2. 阅读共同基线、双方提交及调用关系，弄清楚双方改动要实现的行为。
3. 逐处整合并保留双方有效意图，同时检查相关文件中未产生文本冲突的逻辑兼容性。
4. 意图或取舍不明确时，停止处理相关冲突并请负责人确认；不得自动选择“自己的版本”。
5. 解决后显式暂存已解决的文件，确认没有未解决冲突，检查暂存差异，再完成 merge 提交。
6. 对合并后的结果重新验证，并在 PR 中说明冲突位置及处理理由。

同步完成后审核整个任务相对最新主分支的差异：

```bash
git diff --check origin/main...HEAD
git diff --stat origin/main...HEAD
git diff origin/main...HEAD
git status --short
```

完成下节验证后才可推送：

```bash
git push -u origin HEAD
```

若推送被拒绝，重新 fetch、查看新增提交、合并、审核及验证。**拒绝不是强推授权。** 不通过修改 push 配置或反复重试危险命令绕过保护。

Fork 开发者约定 `origin` 为自己的 Fork、`upstream` 为本项目：从 `upstream/main` 创建任务分支，同步时合并 `upstream/main`，并检查自己 `origin/<任务分支>` 的更新；推送至自己的 Fork 后向本项目 `main` 发起 PR。不要将自己的 Fork 主分支误认成项目最新主分支。

## 5. 验证要求

按改动范围执行仓库现有检查：

```bash
npm --prefix backend run check
npm --prefix frontend run check
```

- 后端改动运行后端检查；前端改动运行前端检查；跨端接口或共享行为改动需要两侧检查。
- 功能修复补充能检出原问题的测试；影响页面交互时验证实际操作路径；涉及接口、权限或数据迁移时验证受影响场景及已有行为。
- 仅文档变更可检查内容、链接、示例命令和 `git diff --check`，说明未运行应用测试的原因。
- 使用隔离的测试环境和数据，不为了检查连接生产数据库或执行生产迁移。
- 记录实际命令、结果和被验证的提交 SHA。失败要如实报告；无法运行的检查标记“未运行/受阻”，不能写成“通过”。
- 同步或冲突解决改变了待合并内容后，重新运行受影响的验证。旧提交上的成功结果不能证明新提交正确。

## 6. PR 与安全合并

每个 PR 只对应一个明确任务，目标为 `main`，描述至少包含：

```markdown
## 目的与范围
- 解决的问题：
- 修改的模块/文件：
- 是否使用 AI 及负责开发者：

## 同步与兼容性
- 起始基线 SHA：
- 最近同步的 main SHA：
- 待审核任务分支 SHA：
- 并行 PR、共享接口、迁移/配置影响：
- 冲突及处理理由（无冲突也应说明）：
- 如何确认保留了其他开发者的已有行为：

## 验证
- 实际执行的命令及结果：
- 未运行或失败的检查及原因：
- 人工验证路径（如适用）：

## 风险与回退
- 已知风险：
- 回退方式和数据兼容性：
```

合并要求：

1. 至少一名非提交者的维护者或开发者审核最终差异；AI 自我复查可以辅助，但不代替独立审核。提交 AI 不得用另一个会话或共享账号冒充独立审核者。
2. 审核需关注是否撤销他人逻辑、丢失配置/依赖、改变接口与权限、破坏已上线功能，不能只看有无冲突或测试绿灯。
3. 审核和检查必须对应最终待合并提交；后续新提交或冲突解决后需要重新确认，不能沿用失效的批准。
4. 合并前再次确认最新 `main` 已被纳入任务分支，并验证组合后的行为。其他 PR 先合并导致主分支前进时，更新本 PR、重新检查并确认审核后再合并。
5. 由维护者通过仓库 PR 合并功能依次处理；同时有多个待合并 PR 时串行合并。有合并队列时使用针对最新组合提交的检查，避免两份旧验证同时放行。
6. 未解决冲突、必需检查失败、尚未审核或同步状态不清楚时不得合并。缺少独立审核者时保持 PR 待审核，不自行批准。
7. 合并后核对主分支结果。删除任务分支前确认已合并且无人继续使用，不删除其他开发者的分支。

## 7. 发现误合并或代码被覆盖

先保留当前状态、记录相关提交 SHA 和影响，暂停自己受影响的后续提交，交由维护者定位问题。使用新的修复 PR 或 `git revert` 生成撤销提交，让历史可追溯。撤销 merge 提交需要维护者先确认正确的主父提交，不要盲目套用 `-m` 参数。

禁止将 `main` reset 回旧版本再强推。代码回退不会自动恢复数据库和外部状态；涉及迁移或数据变更时，需要单独验证兼容性与恢复方案。部署只能使用已合并、已验证的明确提交，并遵守实际部署授权；提交或合并代码本身不代表获准操作生产服务器。

## 8. AI 交付前检查清单

- [ ] 已阅读本规范；当前仓库、目录、账号、任务分支和基线正确。
- [ ] 没有覆盖、清理、暂存或提交他人的未提交修改。
- [ ] 提交仅包含本任务内容，没有秘密信息、真实业务数据或无关产物。
- [ ] 已同步最新主分支及远端任务分支，未强推、未改写已发布历史。
- [ ] 已逐项审核最终差异；冲突处理保留双方有效行为，疑点已确认。
- [ ] 已完成受影响的验证，记录准确结果和提交 SHA。
- [ ] PR 已说明范围、兼容性、验证、风险和回退方法。
- [ ] 已明确报告当前状态：本地提交 / 已推送 / PR 待审核 / 已合并；没有把推送成功说成合并或部署成功。

## 9. 文档要求与服务端强制保护的区别

本文件规定协作流程，`AGENTS.md` 提供 AI 读取入口；它们不是权限控制，不能保证每个 AI 工具自动读取或遵守。使用不自动读取这些文件的工具时，开发者必须主动提供规则。

仓库管理员应在服务端落实以下保护，并以实际设置为准：保护 `main`、禁止直接及强制推送和删除、要求 PR 与独立审核、使过期审核失效、绑定真实运行的必需检查、限制合并权限、按个人发放最小权限凭据。没有真正运行的检查不能仅凭同名状态作为合并依据。

**添加本文件不等于上述保护已经启用。** 此文档变更不修改仓库权限、分支保护、CI 或生产部署；如需启用服务端限制，应由管理员单独配置并验证。