敏捷开发规范 (Agile Standards)

为适应五人以下小团队的快速迭代需求，我们要遵循 "最小化阻力" 原则。

核心原则

1. 主干开发 (Trunk-Based): 不维护长期存在的 dev 分支，所有功能直接合并回 main。
2. 快速通过: Code Review 应在 24 小时内完成，或通过口头沟通快速解决。
3. 自动化优先: 格式问题交给 Linter，人工只看逻辑和架构。

分支管理 (GitHub Flow)

我们采用最简单的 GitHub Flow。

流程图

规则

• main: 永远处于可部署状态。
• feat/xxx: 从 main 切出，开发完成后通过 PR 合并回 main。
• 不需要 dev 或 release 分支。

命名习惯

• feat/user-login
• fix/motor-jitter
• docs/update-api

提交消息 (Conventional Commits)

保持好习惯，有助于自动生成日志，但不必过于教条。

feat: add basic navigation
fix: resolve webrtc latency
docs: update readme

极简代码审查 (Lite Code Review)

PR 准则

• 小步快跑: 一个 PR 最好只包含一个功能点，修改行数 < 300 行。
• 自我审查: 提交前先自己 diff 一遍。

审核路径

1. 常规: 提 PR -> 飞书 吼一声 -> 同事点 Approve -> 合并。
2. 结对编程: 如果是两人一起写的代码，可以直接合并，无需额外 PR 流程。
3. 紧急修复: 可以直接推送到 main (仅限一人开发且自信的场景)，但事后需补文档。

自动化检查

尽量在本地解决格式问题，不要浪费 CI 资源。

• C++: clang-format
• Python: black / ruff
• JS/TS: prettier / eslint

CI/CD 极简流