中小体量游戏项目主干开发的流程说明

一、主干开发：

利：避免功能开发合分支解决冲突的问题。

弊：不同功能开发提交不稳定内容，影响他人（故适用人少时）

（若某功能开发工作量大流程长，也可再切单独开发分支）。

二、出包分支和标签（对于项目主工程）：

出包时打一个branch，作为正式分支，后续将基于此分支出包、并作为热更底包。

热更时打一个tag，仅用来标记热更时处于什么git未知（可以看到更新了哪些提交）。

------------------------------------------- NRatel -------------------------------------------

注意⑴：在切正式分支后，仍要本次进包的后续修改，需要“双提”。

即：在main改完后要合到branch。 

（“从main合到branch”，而非“从 branch合到 main” 的原因是：QA在branch验证一次即可保证 main 和 branch 的结果都正确）

注意⑵：切分支的早晚有各自利弊。

切的过早，可能使双提内容过多，需挑选哪些要“双提”，影响效率。

切的过晚，不能尽早开始打包（尤其是Unity打包时间较长）。

注意⑶：对于线上问题的热更修改，也需“双提”。

如图所示：

三：游戏的配置表如何双提？

由于配置表用 以独立版本号命名文件夹 放置。

因此，只需在 Jenkins上将最新配置目录分别导出到项目主工程的 main 和 branch即可。

例如，将 1.0.6 分别导出 main 和 v1.4.0（如下图：）。

注意，以上操作需保证 打包时尚无新的配置版本出现。

后续，如果 main 要使用新的配置后，如 1.0.7，则将 1.0.7 。

若 v1.4.0 需要热更配置，则应在 1.0.6中修改，然后导到 v1.4.0。

四、游戏的关卡文件如何双提？

同项目主工程 的双提，提到main后，使用git合并到branch。