开发者学习笔记【阿里云DevOps助理工程师认证（ACA）课程：软件代码与质量管理（更新版）（一）】
课程地址：https://edu.aliyun.com/course/3112069/lesson/18999
软件代码与质量管理（更新版）（一）
内容介绍：
一、版本控制
二、代码规约
三、单元测试基础
一、版本控制
版本控制在软件工程学里有一个正式的定义，它是指追踪和控制软件变更的实践。版本控制系统是用来辅助进行版本控制的工具。
我们先来看版本控制系统的发展历史。最早在 1982 年出现第一个版本控制系统RCS，它的全称是 revision control system，然后在 1990 年的时候出现一个著名的广泛使用的版本控制系统。 CBS 的全称是 concurrent version control system，虽然它并不是并行的，也并不是分布式的，但是我不知道为什么它的名字里出现concurrent。然后 CBS 是最早大范围使用的，曾经在工作站上非常的流行，大概在像 San 的 slots 和 IBM 的工作站上，惠普的工作站上基本上是所有的 Unix 工作站上都有CBS。在 1992 年的时候， IBM 出品一个著名的里程碑式的版本控制系统，叫 clear case，那时 clear case 是非常有名，非常高端，特别昂贵，只有很少的人使用过。大概在 2000 年的时候出现subversion，这是目前为止上一代用的最为广泛的版本控制系统。大概在 205 年的时候出现现代的分布式版本控制系统，包括Git，Mercury和 TFS，还包括像Bazar，这些都是分布式的版本控制系统。
为什么需要版本控制系统？
首先版本控制系统它能记录下你所有的activity，包括是谁在什么时间做了什么事情。 commit message，它还提供你做的事情的这个额外的信息，解释变更的原因，然后由这个信息我们可以帮助软件进行发布管理。 同时现代的版本控制系统，像Git，SUB， Mercurio 和 TFS 这些分布式的版本控制系统，它还可以进行同步和并行，这样辅助多人团队进行协作，因为它是分布式。git，不光是 git 所有的版本控制系统，它还有一个辅助的功能，是帮助你进行 bug 调试，比如有一次改动，比如你的线上的版本出现一个问题，但是你知道在那之前的某一个版本是没有问题的，就可以利用版本控制系统，这中间可能有 10 次变更，你一次一次的去看到底是哪一次变更导致你的问题，你就可以把这一次变更到底改了什么拿出，这样可以极大的缩小你的追踪的范围，可以让 bug 调试变得简单。
现代的版本控制系统都支持分支和分支的合并，分支策略是版本控制里面一个非常重要的组成部分。分支策略现在大概分成主要的分支策略有三种，第一种是主干开发，分支发布，可以看图里面所有的开发的动作都在主干上完成，而一旦需要做一个分支的做一个发布的时候，我们就拉出一个分支，然后在这个分支上进行发布。 它的主要的优势是管理比较简单，大家从图上就能直观的看出这种管理方式是相对的简单一些。但是它也有一个弱点，就是主干的问题会阻碍开发的进程，因为一旦主干出现问题，这个时候想发布就没有一个稳定的地方可以发布。主干上现在有问题，就不能拉出一个分支来进行发布。
我们看第二个分支策略叫做分支开发，主干发布所有的开发活动都在分支上面进行，然后一旦这个分支稳定，需要进行发布的时候，就把它合并回主干，然后做一次发布。这有一个优点跟第一个不一样，它的开发是在分支上进行，和主干的代码提供一个可靠的隔离。但是它和第一个分支策略也有同样的问题，主干的问题会阻碍开发的进程。比如这一个分支已经准备好，你需要发布的时候，这个时候如果同一时间主干上的代码有问题，就没有办法合并到主干上，然后使用一个能用的分支进行发布。所以这也就是主干问题会阻碍开发的进程。
第三个分支策略是什么呢？
是分支开发，分支发布，它可以兼顾上面两个策略的优点，比如它可以开发分支，提供了可靠的代码隔离，然后它主干的问题也不会阻碍发布，因为它是分支上发布完之后再合并回主干。但是这个同时会导致另一个问题，就是集成的时间点可能会比较延后。不过这个问题其实相对于阻碍开发进程的问题，这是一个相对较小的问题。所以现在用分支开发，分支发布这种策略的公司会比较多，当然不是仅仅是简单的这种分支开发，分支发布，这种有的时候会有一些变通。
