持续交付中的分支管理与版本控制

如今，愈来愈多的项目使用Git做为版本控制的工具，经过Git来进行分支和Tag管理，但大多数状况这个过程都由手工完成，缺少相应的规范，对于分支和版本号的控制也很随意，出现这样的状况每每是你们对软件交付过程当中的软件版本控制不够重视，“只要确保软件是最新的版本便可”，甚至是项目管理的漏洞或者缺陷。

其实软件的版本控制以及分支管理贯穿于整个软件产品的生命周期，平常的项目管理对于开发团队可否有节奏且顺利的交付软件也很重要。

的确，有时候频繁的冲突会搞的开发人员头晕脑胀，好比，一次项目在代码合并时出现了冲突，致使整个项目组挨个排查，花费了大半天时间影响开发效率不说，还浪费资源；又或者开发人员随意建立分支，各类不规范的合并使得Git Graph线条杂乱无章，彻底看不出来主干发展的脉络；还有提交信息混乱，让人不清楚此次提交是由于什么，实现了什么功能 ，解决了什么问题。

本文并非一篇技术文章，其中也没有让别人耳目一新的观点或者论述。这篇文就只是为咱们这些但愿进行简单、有效协做的人准备的。任何参与到软件开发的人，不管承担何种角色，均可能对其感兴趣，毕竟每一个人都会用到分支和合并。

在此，本文将结合Choerodon猪齿鱼为你们阐述如何进行方便有效的分支管理和版本控制，以及如何选择适合自身的版本控制模型。

如何来解决这些问题呢？

有经验的老司机可能会说，“创建规范”。

是的，只有创建规范，才能抑制很差的事情继续在项目组蔓延，至于创建什么样的规范？咱们不妨先制定一个目标。

目 标

• 简单——全部的团队成员天天都会使用这些模式，因此相关规则和程序必需要简单明了。

• 灵活——可选择不一样的分支管理模型，例如GitFlow、GitLabFlow或者GitHubFlow，甚至自定义。

• 可视化——界面化比命令行更安全可控，将分支管理模型的规则和约定固化到系统中。

• 需求与代码关连——分支须要和具体的任务需求关连。

做为一个有经验项目管理者或者产品负责人，你必定会思考这样一个问题：咱们项目组在开发过程当中应如何管理分支？不错，分支管理将和项目组开发人员日夜伴随，若是采用了一个不合适的分支管理模型，那么能够想象兄弟们得多么的痛苦。

Okay，那么就从分支管理模型开始......

分支管理规范

GitFlow、GitHubFlow等都是已经被证实颇有效的分支管理模型，可是这些更多的是书面的规则、约定，基本上是靠着程序员的自觉性和Git命令一块儿维持着这个约定，其实无数的经验告诉咱们“这很脆弱”。因此，如何使用系统界面化操做将这些规则和约定表示出来，就变得颇有意思。

▌分支管理模型

不要着急，先来看看 Choerodon 猪齿鱼提供的分支模型，Choerodon使用 GitLab 进行分支管理，默认分支为 master。目前支持七种常见的分支类型：

1）master：主分支，用于版本持续发布；

2）develop：开发分支，即平常迭代使用的开发分支，用于平常开发持续集成；

3）feature：特性分支，用于平常开发时切出分支进行单功能开发；

4）bugfix：故障修补分支，一般用于修复故障；

5）release：发布分支，适用于产品发布、产品迭代；

6）hotfix：热修分支，用于产品发布后修复缺陷；

7）custom：自定义分支，用户能够自定义须要的分支类型。

* 注：

（1）develop是GitFlow分支模型的重要组成部分。

（2）bugfix旨在与敏捷的问题类型（故障）呼应，用于标识此分支的任务是修复某个故障。

这7个分支就是咱们手中的7个魔方，经过这7个魔方的组合能够变化出无尽的分支管理模型，好比GitHubFlow。

GitHubFlow分支模型只存在一个master主分支，平常开发都合并至master，永远保持其为最新的代码。

• 在领到平常开发任务时，基于master建立feature特性开发分支，提交代码后，合并至master并删除feature。

• 在领到修复故障的任务时，基于master建立bugfix故障修补分支，提交代码后，合并至master并删除bugfix。

• 须要发布时，一样须要基于master建立release，生成的应用版本部署在UAT测试环境进行测试，若须要修改则提交至release。

• 产品上线后发现故障须要紧急进行热修复时，则基于tag建立hotfix，将修复的代码提交至hotfix；部署该分支上的版本经过验收后，基于hotfix打出热修版本的tag，如0.8.1。

• 因为新版本的迭代也同时进行，因此须要在hotfix上rebase master，变基至master分支最新的提交，再合并至master并删除hotfix，就能够将本次修改的提交应用至master上。

这个分支模型的优点在于简洁易理解，将master做为核心的分支，代码更新持续集成至master上。根据目前收集到的反应来看，获得了更多的好评，认为GitHubFlow分支模型更加轻便快捷。

若是GitHubFlow不合适，可使用GitLabFlow或者GitFlow，也能够自行定义规则。这里没有“银弹”，只是相对比较灵活的配置。

▌分支命名规约

有了分支管理模型，还须要命名规约，不一样类型的分支命名方式应该不一样，值得庆幸的是，猪齿鱼已经帮你完成了这个步骤。feature、bugfix分支的分支名使用的是关联问题的issue号（在猪齿鱼中打通了需求和代码分支的关连关系），对于release及hotfix，分支名可命名为须要发布的版本号，如0.8.0、0.8.1等。在这里使用到了相似0.8.0这样的版本编号规则，若是你对此不了解，没有关系，在下面将详细的介绍。

▌提交命名规约

除了分支的名称须要规范，提交的命名也一样如此。不幸，猪齿鱼并无把这个规则固化到系统中，须要团队共同遵照。

格式为：[操做类型]操做对象名称，如[ADD]readme，表明增长了readme描述文件。

常见的操做类型有：

• [IMP] 提高改善正在开发或者已经实现的功能

• [FIX] 修正BUG

• [REF] 重构一个功能，对功能重写

• [ADD] 添加实现新功能

• [REM] 删除不须要的文件

▌合并请求

合并请求是开发过程当中必不可少的一个环节，其中有以下一些重要的事情要作：

1. 代码Review

2. 启动CI

1. 单元测试

2. 代码质量检查

版本号规则

在软件管理的领域里存在着被称做“依赖地狱”的死亡之谷，系统规模越大，加入的套件越多，你就越有可能在将来的某一天发现本身已深陷绝望之中。

—— Tom Preston-Werner 的《语义化版本2.0.0》

在这里咱们不去解读到底什么是“依赖地狱”，你们能够到语义化版本2.0.0中了解。那么，咱们的重点是什么呢？在这以前，先了解一下“语义化的版本控制”

版本格式：主版本号.次版本号.修订号，版本号递增规则以下：

1.主版本号：当你作了不兼容的 API 修改

2.次版本号：当你作了向下兼容的功能性新增

3.修订号：当你作了向下兼容的问题修正。

先行版本号及版本编译信息能够加到“主版本号.次版本号.修订号”的后面，做为延伸。

这就是“语义化的版本控制”最核心的规则，固然这不是所有，Tom Preston-Werner还详细的阐述了主版本号、次版本号和修订号的变化递增规则，不过这些规则很长，很复杂。

没有关系，猪齿鱼帮咱们作了这些复杂的事情，将“语义化的版本控制”固化到了系统中，简而言之，

● 当进行代码打包时，而非发布新版本

将版本号规则定为`年.月.日-时分秒-分支名`。如：`2018.7.20-152837-hotfix-0.8.1`，这个时间是当前提交时间。当代码提交到各个分支上时会自动触发CI，生成版本号规则如上所示。



● 当须要发布新版本时，例如如`0.8.0`、`0.8.1`

• 主版本号：当作了不兼容的 API 修改或功能强大的升级，能够将主版本号的数值增长1。
  
• 次版本号：当作了向下兼容的功能性新增或是功能上的小迭代，能够将次版本号的数值增长1。
  
• 修订号：当作了向下兼容的问题修正，但功能上没有很大的变化，能够将修订号的数值增长1。



需求与代码关连

一直以来，需求通常和系统的功能联系在一块儿，可是与代码关连却不常见，若是能将需求和代码联系在一块儿，奇妙的化学反应就发生了。

“咱们能够追溯到一个用户故事对应了哪些分支，哪几个提交”，

“甚至出现了一些BUG，能够找到是哪一个分支提交的，当初为了发布XXX新的需求”，

“不只如此，咱们经过需求与代码分支关连，可以查看到哪些需求已经部署到了测试环境，那些需求已经部署到了正式环境”，

“能够作从业务到代码的整个链条的统计分析...”

...

这一切，猪齿鱼已经帮助项目管理者和程序员实现了。在猪齿鱼的敏捷管理服务中，能够经过用户故事、任务、缺陷等直接一键建立分支，而后，你能够从git checkout -b 开始愉快而又有挑战的一天。不只如此，也能够在分支管理中，将现有的分支关连到用户故事、任务或者缺陷。

总 结

回顾一下咱们的目标，简单、灵活、可视化，以及需求与代码关连。版本控制一直都是一件提及来容易，作起来难的事情，可是咱们作到了，重要的是猪齿鱼将这些特色和规则固化到了DevOps流程中，让咱们忘记复杂易错的操做，把精力放到业务开发上。但愿咱们的分享可以给你们带来帮助。