活用 GIT 分支规范发布流程的构想

这不仅仅是构想，而且完全可以付诸行动。

虽然本文中显著的注明了 GIT 字样，但并不表示 SVN 无法完成类似工作，而本文也无意于讨论 SVN 对于分支的支持是否友好，而仅以 GIT 为参考，设计一套发布流程规范，为将来的新项目做铺垫，也是给大家一个蓝图。

发布版本 & 发布窗口 & 功能需求

要理解一套完整的发布流程，我们有必要先了解一下流程中的三个层面。

首先是发布版本，每一次的线上发布都可以认为是一次 release 版本，重大的功能发布可以认为是一个重大版本，对其进行打标（GIT 有 tag，SVN 没有研究）。当发布上线失败时，我们就可以拉取上一个 release 版本的代码实现代码回滚。

接下来看看发布窗口。发布窗口和我们工作的公司息息相关，比如我们一周有两个发布窗口，除特殊需求及修复 BUG 外，非窗口时间做线上发布都被认为是非法的（测试MM和测试GG要来找你喝咖啡的哦:smile:）。

最后是功能需求，即你手上需要完成的功能点。每一个功能需求会有对应的排期，有项目经理、产品经理或者研发同学确定后，就可以预判到上线日期。功能需求的完成需要投入开发与测试的人力资源。

了解了发布流程中的三个层面后，我们可以将它们与工作中的一般流程——开发、测试、上线相结合，制定一套分支与层面的关联规则。

为每个功能需求建立的分支，我们暂且称之为功能分支。分支应该是基于最近一次的 release 版本创建的。当多个需求同时进行时，可以互不干扰的将对应分支部署至测试环境，方便测试人员进行测试，减少其他需求的干扰。

分支命名可以由开发人员自定义，不与其他分支名冲突即可，比如 userName_feature_createTime。

发布窗口的分支也应该基于最近一次的 release 版本创建的，我们称之为窗口分支。发布窗口的分支可以被视为所有当期需要发布的功能分支的集合。在功能分支测试完毕后就可以合并至窗口分支。窗口分支最终会通过预发布测试后，推向线上。

窗口分支的权限，在理想情况下应该是由测试人员控制。

当窗口分支发布至线上并通过测试后，我们就可以从主干拉取窗口分支，然后进行提交版本。

每一次主干的提交必须确保是上线发布成功后，以尽可能确保主干的版本纯净性。当需要版本回退时，获取主干的上一个版本部署一下即可，轻松方便。

在主干上随便提交代码的行为应该是严格禁止的，所以主干的权限应该仅分配给少数负责人。