| | |
|---|
| | | - 需要交接的部分：把"当前状态 + 待办"追加到 `HANDOFF.md`（同事的做法就是这样）。 |
|---|
| | | 3. **git 工作流（2026-09-03 用户授权，无需再询问是否推送；提交粒度参考同事 xyc）** |
|---|
| | | - **一条提交 = 一个改动**：代码/脚本 + 该改动的说明文档（`HANDOFF.md` / 方案 / 口径清单）放在同一条提交里；不要为每个小改动单独建报告再单独提交。 |
|---|
| | | - message 写法：`feat(模块): …` / `fix(模块): …` / `docs: …` / `docs(交接): …`，一句话说清"改了什么"。 |
|---|
| | | - message 写法（**对齐同事 xyc 风格；2026-10-09 用户确认**）：`feat(模块): …` / `fix(模块): …` / `docs: …` / `docs(模块): …`，一句话说清"改了什么"。 |
|---|
| | | - **类型只用** `feat` / `fix` / `docs`（同事另有过少量 `chore`）；不要自造类型。 |
|---|
| | | - **scope 用模块名**，中英均可——同事用过 `holiday` / `version` / `deploy` / `observation` 与 `交接` / `部署` / `节假日` / `汇总表`；**约 6 成提交不带 scope**（如 `docs: add …`），不带也合规。 |
|---|
| | | - **不写正文**（同事 91 条里 90 条无正文）：全部信息放在主题这一行，不要 bullet、不要多段、不要署名或工具尾注。 |
|---|
| | | - 主题中位约 40 字（最长 119），可以长，但只讲**一件事**。 |
|---|
| | | - 待验收标注按第 5 条以 `（待验收）` 收尾，例：`fix(汇总大表): 四页取数月份列改按表头动态定位（待验收）`。 |
|---|
| | | |
|---|
| | | - **禁止入库**：临时脚本与调试产物（`_tmp_*`、`_shots/`、`outputs/`）、构建产物（jar / dist / target）、密钥与口令、大体积备份（`*.sql` 全库导出）；过程日志与日结只留本地。 |
|---|
| | | - 推送前：先按上面完成测试，再 `git fetch origin` 与远端 `main` 对比合并（必要时解决冲突），确认无误后 commit 并 push 到公司 gitea（`http://61.183.254.94:3000/r/trafficAudit.git`，账号 zyj）。 |
|---|
| | | - 若远端已有同事新提交：必须先合并/基于最新再推，禁止强推覆盖同事代码。 |
|---|
| | |
|---|
| | | 4. **git 单仓库约定（2026-09-21 用户确认，替代 2026-09-07 的双仓库约定）** |
|---|
| | | - 本机只使用公司 gitea：`origin` = `http://61.183.254.94:3000/r/trafficAudit.git`（账号 zyj）。个人 gitee 仓库已不再使用，不要再把它当作 origin 或额外拉取源。 |
|---|
| | | - 拉取/推送一律走 `origin`（远端分支 `main`）：先拉合并，禁强推，再 commit/push。 |
|---|
| | | |
|---|
| | | |
|---|
| | | 5. **验收门禁（分级；2026-10-06 用户确认，参考同事 xyc 的做法）** |
|---|
| | | - **一般功能 / 修复 / 重构**：沿用现行规则——按第 1 条完成测试后即 commit + push，不等待人工验收。 |
|---|
| | | - **口径类 / 版式类 / 任何会改变输出数字或表格版式的改动**：代码与文档照常提交推送，但必须在 `HANDOFF.md` 对应段落标注 **【待验收】**，写清验收项与产物路径；用户验收通过后，再补一条 `docs(交接): …` 提交把状态改为「已验收（YYYY-MM-DD）」。 |
|---|
| | | - 未验收的改动，提交信息与交接段里禁止写成「已完成 / 已验证」，只能写「待用户验收」。 |
|---|
| | | - 例外优先：用户当次明确说「先不提交 / 等验收再提交」时，一切以用户当次指示为准。 |
|---|
