提交日志规范

多人协作、尤其是引擎移植这类改动密集的项目里，一条好的提交日志能让评审和事后排查省下大量时间。核心约定是：用前缀标明改动类型，正文交代「改了什么、为什么改、怎么测的、有没有遗留问题」，并带上项目代号和模块名方便检索。

改动类型前缀

• [+] 新增内容（功能、文件等）。日志需包含：新加了什么、为什么加、自己的测试结果、有没有遗留问题。
• [-] 删除内容。日志需包含：移除了什么、为什么移除、测试结果、有没有遗留问题。
• [*] 对原有内容的修改。日志需包含：改了什么、为什么改、测试结果、有没有遗留问题。
• [FIX] 修复 QA 报告的 bug。日志需包含：对应 bug 号、问题描述、原因分析、改动如何修复、测试情况、是否有遗留问题。

所有提交都加上项目代号和模块名，格式：[类型][Proj][Module]，便于在历史里按项目/模块过滤。

示例

[+][Proj][Steam] 接入 Steamworks SDK 以支持 Steam 相关功能。
Steamworks 能正确初始化和退出。
NOTE: 当前用的是 sample 的 Appid。
TODO: 实现具体的 Steam 功能。

[-][Proj][Content] 删除未使用的 content 文件。
引擎升级后 light map 数据和 map 文件从 1 个拆成 2 个，但原文件还在，
导致 cooking 报错。新 build 已重新生成，测试无问题。

[*][Proj][Rendering] 临时关闭客户端实现的后处理，让引擎能编过。
用宏 DISABLE_CLIENT_CODE 屏蔽它们。
TODO: 配合升级后新增的渲染 pass 重新实现。

[FIX][Proj][BUG-299] 按 ALT+F4 退出游戏时，launcher 会被自动拉起。
游戏进程的返回值不对，和某发行版本不一致：该版本会校验命令行参数来决定返回值。
这边在启动游戏时往命令行传了一个参数，再用类似逻辑返回进程退出码。
带这个修复测了 3 次都无法复现该问题。

提醒

如果用英文写有困难，可以先写中文，再用翻译工具协助翻成英文——别让语言成为写清楚改动的障碍。