You cannot select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
OnlineMsgServer/CONTRIBUTING.md

180 lines
5.7 KiB
Markdown

This file contains ambiguous Unicode characters!

This file contains ambiguous Unicode characters that may be confused with others in your current locale. If your use case is intentional and legitimate, you can safely ignore this warning. Use the Escape button to highlight these characters.

# Contributing Guide
本仓库已经同时包含服务端、Android 客户端、Web 客户端和本地部署脚本。后续协作必须按下面的规则执行避免再次出现分支漂移、协议不一致、WIP PR 长期悬挂、本地调试资产误入版本库等问题。
## 基本原则
1. `main` 只接收可合并、可验证、可发布的代码。
2. 一个 `issue` 对应一个主题分支,不要在同一分支里混入多个不相关需求。
3. 本地调试资产不进 Git包括证书、密钥、构建产物、个人环境配置。
4. 任何跨端协议改动都必须做双端联调,不能只改单边实现。
5. 没做完的工作不要以普通可合并 PR 的形式挂着;未完成状态请使用 Draft 或继续在本地分支开发。
## 分支规则
1. 新功能或修复必须从最新 `main` 切出:
```bash
git fetch origin
git checkout main
git pull --ff-only origin main
git checkout -b emilia-t/issue-<id>-<topic>
```
2. 分支名建议包含作者、issue、主题例如
- `emilia-t/issue-7-audio-message`
- `emilia-t/issue-12-notification-sound`
- `emilia-t/issue-18-server-switching`
3. 不要长期复用一个旧分支持续堆新需求。
4. 合并前必须再次同步 `main`,优先用 `rebase`,避免无意义 merge commit
```bash
git fetch origin
git rebase origin/main
```
## 提交规则
1. 提交应当聚焦单一目的避免一个提交同时混入协议、UI、美术、文档、重构。
2. 提交信息必须带范围和目的,推荐格式:
- `feat(android): add voice message playback`
- `fix(web): parse Android audio payload correctly`
- `docs: document local debug CA setup`
- `chore(server): tighten message size validation`
3. 不要使用 `update`、`misc`、`fix bug` 这类无信息量的提交说明。
4. 提交前先看一遍差异,确认没有把临时调试代码、个人地址、日志打印一起带上。
## PR 规则
1. PR 标题必须描述结果,不要长期保留 `WIP:` 前缀。
2. 未完成内容请使用 Draft PR准备好评审后再转正式 PR。
3. PR 描述至少写清楚以下内容:
- 改了什么
- 为什么改
- 怎么验证
- 是否影响协议、兼容性或部署方式
4. 如果 PR 和目标分支冲突,提交人必须先在本地解决冲突,再更新 PR。
5. 如果发现 PR 只包含部分有效改动,而剩余部分与当前主线冲突或重复,应当把有效增量摘到新提交中,而不是强行点合并。
## 验证要求
提交 PR 前,至少执行与你改动范围对应的验证命令,并在 PR 描述里写明结果。
### 服务端
根据改动类型至少做一项:
```bash
dotnet build
dotnet test
```
如果改动涉及消息大小、限流、鉴权、peer 转发或 TLS/WSS请补充实际联调结果。
### Android 客户端
```bash
cd android-client
./gradlew :app:assembleDebug
```
如果改动涉及以下内容,还需要额外验证:
- 语音消息Android 发 -> Web 收Web 发 -> Android 收
- 通知:前台/后台通知、系统通知开关、通知音效预览
- 服务器切换:切换后自动重连、聊天记录按服务器隔离
- WSS 联调:确认 `deploy/certs/android-local/local_ca.crt` 能被 debug 包信任
### Web 客户端
```bash
cd web-client
npm install
npm run build
```
如果改动涉及录音、播放或协议兼容,还要验证:
- Web 发语音 -> Android 收
- Android 发语音 -> Web 收
- 分片消息能正确重组
## 协议改动规则
本项目最容易出问题的部分是“服务端、Android、Web 三端协议不同步”。任何协议改动必须遵守以下要求:
1. 明确改动的是哪一层:
- 握手
- 鉴权签名
- 业务包结构
- 语音标签或分片
- 消息大小限制
2. 修改协议后,至少检查:
- Android 客户端
- Web 客户端
- 服务端解析或转发逻辑
3. 如需兼容旧客户端,必须写清楚退化策略。
4. 不允许只在某一端“默认推断”字段而不在代码或文档中说明。
## 本地调试资产规则
以下内容只允许本地存在,不允许提交到版本库:
- `deploy/certs/`
- `deploy/keys/`
- 本地生成的 `server.pfx`
- `android-client/app/build/`
- `web-client/dist/`
- 调试日志、抓包、临时脚本
Android debug 本地 CA 信任的约定如下:
1. 本地 CA 证书路径固定为 `deploy/certs/android-local/local_ca.crt`
2. 该路径已被 `.gitignore` 覆盖
3. `android-client/app/build.gradle.kts` 会在 `assembleDebug` 时动态生成 debug-only `networkSecurityConfig`
4. release 构建不会信任本地 CA
## 冲突处理建议
如果 PR 已经明显落后于 `main`,不要直接在平台上硬点合并。正确做法:
1. 本地同步最新 `main`
2. 手动解决冲突
3. 重新跑验证
4. 再推回分支
如果发现 PR 中一部分内容已经被主线吸收,另一部分仍有价值,优先做“摘取有效增量”,不要把旧分支整条强行合进来。
## Issue 与关闭规则
1. 处理 issue 前先确认需求边界,避免顺手扩需求。
2. 做完后在 issue 或 PR 中写清楚:
- 实际完成内容
- 验证方式
- 仍未解决的边界
3. 关闭 issue 前,确认代码已经合入目标分支,而不是只停留在本地或个人分支。
## 推荐工作流
1. 从最新 `main` 切分支
2. 只做单一目标改动
3. 本地自测
4. 更新必要文档
5. 同步最新 `main`
6. 再次验证
7. 提交 PR
8. 评审完成后合并
9. 删除分支
## 最低合并清单
合并前至少确认以下事项全部满足:
- 改动范围单一且清晰
- 无本地调试资产入库
- 与改动相关的构建命令已通过
- 协议变更已做跨端验证
- 文档已补齐
- PR 无未处理冲突
- PR 标题和描述可读,不是 `WIP`