Daniel-DB-hub/developer-portfolio

遵循 Git 工作流程

核心规则

production 是唯一长期分支。请勿直接在其上工作。

在任何 Git 写入操作之前：

1. 运行 git status --short --branch。
2. 确认不存在意外文件或更改。
3. 拉取远程仓库。
4. 创建或切换到短期的任务分支。
5. 保持分支仅针对一个目标。

分支命名

使用：

• feat/<scope>
• fix/<scope>
• hotfix/<scope>
• test/<scope>
• docs/<scope>
• refactor/<scope>
• chore/<scope>

使用小写连字符形式（kebab-case）。切勿使用 main、dev-production、changes、update 或类似的模糊名称。

提交之前

1. 审查 git diff 和 git diff --staged。
2. 移除无关文件。
3. 如果出现密钥、私人证据、内部 URL、原始 AI 会话、客户数据或学生数据，请停止。
4. 运行与更改范围相关的检查。
5. 使用常规提交消息。
6. 除非明确要求，否则不要添加 AI 共同作者尾注。

推送与拉取请求

• 切勿直接推送到 production。
• 切勿强制推送 production。
• 切勿绕过钩子或必需的检查。
• 切勿使用纯粹的 --force。
• 仅在明确批准后，才能在任务分支上使用 --force-with-lease。
• 每次对生产环境的更改都需通过拉取请求。
• 遵循 .github/pull_request_template.md。

合并边界

除非 Randi 在当前对话中明确批准合并特定的拉取请求，否则 Claude 必须在合并之前停止。

仅使用 squash 合并。合并后删除任务分支。

完成报告

报告：

• 分支
• 提交
• 运行检查及结果
• 拉取请求状态
• 机密性审查
• 剩余风险
• 是否仍需合并批准

完整策略

阅读并遵循：

• docs/governance/git-workflow.md
• docs/governance/github-configuration.md