git 仓库分支 (branch) 和标签 (tag) · 物联网平台-威尼斯人最新

仓库的分支 (branch) 规范，影响到每个团队的工作流的一致性；标签 (tag) 便于开发团队、测试团队和其他团队识别每个项目的版本，特别是在协同处理线上问题的时候，大家可以非常清楚地知道线上运行版本和代码库的对应关系。因此我们在制作的时候，主要考虑几个因素：

• 一是要有一定的规则，方便持续集成 ci（自动化构建、测试、分布等）
• 二是要有一定的自由度，以适应不同团队的内部协作灵活性
• 要清晰规整，不要参差不齐难以识别

基于我们当前团队的协作能力和提交代码的质量水平，并考虑方便持续集成 ci（自动化构建、测试、发布），我们约定下列常驻 branch：

• develop 分支：顾名思义即持续开发的分支，我们希望每个开发组都在这个分支上保持线性的持续小步迭代，正常的 codereview workflow 和开发级的自动 ci 也在这里进行。当开发完一个迭代 (sprint)，开发小组有信心转测时，就将代码合并到 release 分支，并要求打一个 alpha 级的 tag(如 5.2.0-alpha)
• release 分支：顾名思义即用于发布过程的分支，包括开发转测 (实际上我们认为这里的测试集成测试)、测试和 bugfix 以及发布上线的过程，当发布成功时要打一个发布 beta tag(如 5.2.1-beta)，并将代码合并到 master 分支
• master 分支：即有质量保证的、可安全运行的分支，禁止直接代码提交，避免被污染，仅用于代码合并和归集，在这个分支上的代码应该永远是可用的、稳定的。当需要拉一个特别的开发分时，应该基于 master。

当需要 fix 线上的一个问题是，应该基于上线时的那个 beta tag 做 hotfix。当出现线上 bug 需要 hotfix 时，我们需要在上次上线的 tag 处拉一个临时的 hotfix 分支进行 修正，或者在未被其他开发迭代污染的 release 分支上直接 hotfix 上线并合并到 master 和 develop，然后打一个新的 tag(如 5.2.2-beta）

这个分支体系是我们期望长期持续迭代的分支规划，其它临时分支的删除、创建、命名，都由团队自己决定，保持一定的灵活性。但每个团队都应该努力避免对上述常规情况造成破坏的情况发生，如果有特殊情况（如有两个并行的开发分支同步进行），需要由各组 leader 和 qa 团队协商提供临时方案，这会影响到团队协同中的转测、ci 基准分支等。

关于打 tag 的规则 ：

鼓励开发和 qa 团队共同对勤于打 tag，这便于真正的版本管理，避免有 rollback 需要或者需要查看和对比历史版本的时候的混乱和低效局面。但同时也要求一定的规范性，让人一看便知。

tag 格式为： majorversion.minorversion.fixversion-typelabel，其中 typelabel 为 alpha、 beta、 devel。具体参见下图举例，其中 devel 是留给开发过程中使用的。

分工上，开发团队负责打 tag-alpha，测试团队负责打 tag-beta。

但是，自己决定并不意味着胡乱命名，大家仍然要以 语义明（白）（准）确 的原则来管理自己的分支和标签名，因为所有这些都是为了提高协作效率。

这是一个参考示意图：

事实上，上图和常用的 git 分支实践是比较相似的，只是为了方便自动化工作，我们将 release 分支常驻并配合 tag 管理了，其他工作的 workflow 基本相似，如下图：