日常 Git 协作流程

基础指南审阅稿 0.1 — 2026-10-28。

先读上下文并确认范围

核对项目、本地目录、分支、远端、公开性和当前授权，阅读项目入口、当前计划及相关操作说明。保留无关的暂存和未暂存改动。编辑、本地提交、推送、创建 PR、发布版本及网站部署是不同动作；已有授权继续有效，但不能把整体计划当成所有动作的授权。

核对文件清单和差异，执行与改动相称的检查。公开项目应当在本地提交之前先完成公开内容检查，即使暂时不推送。只暂存本次文件，按授权提交，再回读提交身份、内容及工作区余下改动。

本地提交不上传内容。普通编辑不自动包含新建另一个 Git 仓库、配置远端、修改保护规则或新增备份任务；也不能为获得干净工作区而丢弃其他改动。

在当前授权内核对远端目标及相对于实际目标分支的完整差异。范围包括该分支上此前尚未合并的提交，不能只看最后一次提交。上传前再次核对公开边界。

正常推送获准的功能分支，不强推。首页与动画的默认示例中，AI 准备正确的源分支、目标分支、标题、描述及真实验证结果，交给人工在网页后台新建请求；不能把准备好的表单说成已经创建 PR。

使用者也可以另行授权 AI 创建或更新对应 PR，此时执行后要回读确认其存在和状态；这个可选方式仍不授予 AI 最终合并权限。公开仓库里的功能分支或草稿 PR 已经是对外上传，不是合并前一直私有。

若被权限或策略拦截，报告真实原因，不换管理员会话、令牌、服务直连端口、容器或另一种接口绕过。处理内容冲突也不自动扩大操作权限。

默认示例中，人工进入 OneDev/GitHub 网页管理后台的请求页面，新建合并请求，核对推荐的源和目标，填写标题、描述并提交。若另行授权的流程已经创建了请求，先检查已有请求，不重复创建。默认推荐分支不代表已经审核。

人工检查全部差异、验证证据、目标和预期结果，然后执行最终合并。本流程下，AI 不代点合并、不调用合并接口或命令，也不启用自动合并来替代人。

“必须审核”和“只有人能最终合并”是两个控制点。审核通过后，AI 身份仍可能具有合并权限，需要分别验证。除专用 AI 账号外，还要检查它是否能拿到人的管理员凭据、网页登录会话或其他通道。

回读服务端实际合并结果及目标。用户要求准备 PR，不等于已经确认合并。
获取远端状态，核对审阅改动与合并结果。Squash 或 Rebase 会改变提交身份；目标分支已推进时，应结合对应基线核对结果差异，不能机械要求整个仓库文件树完全一致。同基线的 Squash 可使用最终文件树一致作为证据。
清理前检查未提交改动、未推送提交、其他工作树及适用的保留安排。不擅自增加备份，也不覆盖本地独有工作来强行对齐。
关系满足时快进同步本地主线；若出现分叉，说明原因，不直接重置消除。
在授权内仅清理已核实完成的功能分支。远端已删除的分支只清理过时跟踪引用，不重新创建。Squash 后，单纯基于提交祖先的删除检查可能不通过；任何替代清理都要先核对内容和原工作保留情况。
报告最终分支、工作区及保留事项。分支清理完成不等于完成版本发布或网站部署。

仓库维护者决定命名和审查约定。OneDev 与 GitHub 的账号、配置不同，共用步骤保持一致。用安全验收规范区分流程约定与真实权限；GitHub 的简要差异见平台对照。