全文共3828字，预计学习时长8分钟
源代码控制是软件开发中不可或缺的一部分。对源代码进行恰当的储存和管理将极大地方便工作，特别是当大型产品团队持续释出程式码时。
在微软公司，仅是负责产品开发与测试的团队就拥有2000多名员工。试想一下，在如此之大的一个团队中，若是程式码未能得到恰当的维护与释出，这该是一场多大的噩梦啊。
今后，对于几乎所有的软件开发公司来说，程式码释出管理方案及其流程要求都会非常相似：无缝地对程式码进行管理，并进行适当的版本控制，从而在产品开发以及生产的过程当中，加快程式码周转时间。
先从源代码控制系统——分散式版本控制系统（GIT）说起。
通常，程式码管理是在四个不同型别的GIT分支当中完成的。这四个分支为：
· 主分支/开发分支(有时二者同时存在)
· 功能分支
· 释出分支
· 热补丁分支
我们以产品天睿公司数据库引擎+机器学习引擎为例，这款产品现已在Azure上架并提供相应服务。
传送门：https://www.teradata.in/Products/Cloud/IntelliCloud
来设想这样一个情境：假设现在需要将 Viewpoint与Unity这两款天睿公司的专利附加产品和数据库引擎整合起来。
注：上述情境纯属虚构。支援以上附加功能的数据库已在Azure上提供相应服务，并已在使用者中普遍推广开来。
经过整合，这两款附加产品会成为可以同时使用的两项功能。
同时，假设我们还要考虑到这样一个问题：由于Viewpoint这个软件相对复杂、难以掌控，因此Viewpoint整合完成并投产的时间要比Unity晚一个月。
释出过程的总体要求如下：
· 对于团队成员来说，所采用的方法应该足够简单，以便他们快速上手编写程式码。
· 具备能快速修正已释出程式码的灵活性，保证在生产时不会出现不完整且不必要的程式码。
· 能够用合适的方式追踪记录已释出的程式码；另外，不是所有的使用者都会即时将自己使用的产品程式码更新到最新版本，因此我们也希望可以同时刻支援已释出程式码的不同版本。
在下面有关于Git 流方法的介绍中，我们先会探讨“如何利用Git流管理已释出程式码”这个问题，再介绍微软释出流策略，最后，还会讨论一下团队整合方面的建议。
GIT流方法
GIT流方法始创于2010年，由文森特·德赖森（VincentDriessen）提出。直至今天，这个方法仍为众多产品公司广泛使用。那么现在，就让我们在Git流中构建出上文提出的假设。
主分支与开发分支
· 用以支援天睿公司产品在Azure上提供稳定服务的主要生产程式码会出现在主分支上。这条分支是用来储存到目前为止所有已释出功能的官方释出历史记录。
· 开发分支作为一个整合分支，会把释出的各个程式码汇总到主分支上。在建立主分支之后，开发分支会从主分支中分离出来。
功能分支
· 为了整合Viewpoint以及Unity，开发人员要将程式码开发为两个不同的功能分支，然后再将这两个分支合并成一个开发分支。
· 多个开发人员可以根据自己的细化任务在各自的子功能分支上工作，然后将程式码合并到主功能分支上，以便最终完成该功能。
· 一旦某个功能分支开发完毕，开发人员就要将其不断更新，使之与开发分支保持一致，这样就可以很好地检查编写进功能分支的新程式码，并对其完成合并工作，从而确保产品的质量保证（QA）。成功保证QA后，这一功能分支就会重新合并到开发分支上。
释出分支
· 在假设中，开发人员要首先发布Unity的整合版本。开发人员要先将功能分支合并到开发分支，再从开发分支当中分离出一支释出分支。
· 这个释出分支可能会成为最终产品，并且会根据释出计划与释出标签的情况合并到主分支上。
· 其他功能的开发并不会受到影响，因为在这些功能释出之前，它们是不会合并到开发分支上的。
· 使用此释出分支方法将使检视释出级别的变更日志变得更为简单。
热补丁分支
· 假设天睿公司的数据库引擎在某个特定的Azure服务区（假设为中国服务区）中无法与Unity连线，这便形成了一个实时服务的程式故障。
· 为了处理这一程式故障，开发人员要从主分支中建立一个热补丁分支，再在热补丁分支上修正该故障。测试结束后，该补丁分支会与开发分支和主分支合并。
· 当新功能通过不同的释出分支合并到主分支时，需要在开发分支上合并，以避免补丁分支被覆盖。
Git流方法的优点？
· 开发人员可以很清楚地了解到哪些是实时功能、以及这些实时功能是何时启用的，同时还可以对这些功能进行控制。除此之外，开发人员还可以在程式码库中针对不同的功能用合适的方法管理发布历史。
· 由于未释出的候选程式码肯定会被检入到开发分支当中，这些程式码的开发不会因即将建立的释出分支而受到影响。
· 开发人员可以将单个功能分支设定为受保护的Git分支，并且通过拉取请求的方式将特定的开发人员子功能分支的程式码合并到主分支中，这一操作可以增强检入安全性。
Git流方法也可能会增加开支？
· 要使这种方法发挥完美效果，开发人员就要保持警惕，确保所有热补丁分支都已合并到主分支和开发分支上。如果未能成功将相关分支合并到开发分支上，程式故障等问题还会重新出现在之后建立的释出分支中。人为的小失误可能就会对生产造成重大影响。
· 操作中涉及分支数量极多，因此即使是升级一个小功能，释出工作也会变得十分繁重。
微软释出流
为了降低Git流的复杂性，提高程式码的生产速度，整个微软公司正朝着“工程系统一体化”的方向发展。VSTS团队等微软内部团队采用的是比Git流更为简单的分支方法。
虽然Git流方法在管理及释出程式码方面相当，但对于大型团队来说，管理如此多的分支和层次体系仍然十分麻烦。另外，鉴于其合并热补丁分支的方式，Git流方法可能会导致频繁的合并冲突（详情请参阅“缺点”部分）。
接下来看一看如何在数据库引擎的帮助下用微软释出流方法整合Unity和Viewpoint。通常在这种情况下，开发人员要用到的分支种类会更少一些。
主分支
· 这一分支是每次合并的中心支柱。天睿公司的程式码为Azure提供服务，而在发生合并的这一特定时间点上，该分支则是这些天睿公司程式码的真正来源。
· 单个主题（如用于整合Viewpoint的程式码）以及热补丁分支要合并到主分支上，而释出分支是从主分支上分离出来的。
主题分支
· 每位开发人员都要从主分支中分离出主题分支，并在主题分支上完成大量工作。这一分支可能会包含用于特定功能的少量程式码，抑或是小故障修正，等等。
· 在假设中，Viewpoint和Unity两个功能的开发都要由多个开发人员在不同的主题分支上进行。
· 目的码完成后，开发人员需要通过拉取请求的方式将主题分支合并到主分支上。
· 通常情况下，释出流方法并不要求开发人员将子主题分支合并到某个母主题分支，然后再将该母主题分支合并到主分支上。这是为了降低整个操作的复杂程度。
释出分支
· 当代码需要在特定时间点投入生产时，开发人员就要从主分支中分离出一个释出分支。例如，在按照计划将Unity与数据库整合在一起，并完成了相应的开发和测试工作后，开发人员会建立一个新的释出分支。
· 采用敏捷方法的团队往往会在迭代周期（sprint）的最后建立释出分支，sprint中的各个任务也是如此定义的，从而可以使其在sprint结束时作为开发成果投入生产。
· 一旦建立了新的释出分支，开发人员无需再保留旧释出分支。新发布分支需要从主分支上分离并创建出来，这是因为主分支的程式码是最新的，而且它也已经弃用/删除了旧释出分支。
热补丁分支
· 开发人员若是需要通过修改生产程式码的方式紧急修正程式故障，通常会建立热补丁分支。
· 相比于Git流，微软释出流热补丁分支的操作有很大不同。
· 当需要修正程式故障时，开发人员会从主分支中分离并创建出一个普通分支，然后按照常规的方法修正并测试，最后将其再次合并到主分支上。之后开发人员还会选择性地把修改的程式码同步更新到释出分支上。
· 这种方式可以确保修正补丁一定会出现在主分支上。
· 只有成功释出的程式码才能实时修正程式故障，因此产生合并冲突的可能性极小。
释出流方法的优点？
· 由于所有程式故障、热补丁以及功能开发程式码都会首先检入到主分支上，所以主分支上的程式码一定会更新为最新版本。这可以帮助开发人员更好地管理程式码释出，对自己的工作更有信心。
· 鉴于只用到了一个主分支，且没有建立开发分支，因此程式码释出的管理工作会简单许多，这一点在团队壮大的过程中会变得尤为明显。
· 这一方法会非常适合我们团队，因为我们在开发并发布程式码时采用的是敏捷开发法。
释出流方法也可能会增加开支？
· 由于所有分支都是从主分支中分离出来的，且所有的分支最后又都会合并到主分支上，因此要想让那些不会发布的释出分支上的程式码保持不变，还是比较困难的。
· 为了防止那些不完整的功能、甚至是被禁用的功能被发布并生产，制作释出时间轴和进行工作隔离时必须保证没有失误。
二者结合扬长避短
根据对自身需求以及对Git流和释出流的了解程度，我们决定采取一种中庸之道——取二者优点总结而成的一种新方法。
新方法遵循微软释出流的方法原则，但有以下两个主要变化：
· 建立一个母主题分支/母功能分支，并按常规要求进行拉取请求，从而将母主题分支/母功能分支中与某功能相关的程式码合并起来。只有当完全开发并测试过某功能后，开发人员才会将其合并到主分支上。
· 先从释出分支分离并创建出一个热补丁分支，将该分支合并回释出分支后，再将更改选入到主分支当中。这样我们就可以确保只有热补丁分支被合并进了释出分支，同时也能确保热补丁分支成功合并进了主分支。
用正确的方法管理程式码不仅有助于减少程式故障的发生，还有助于推动释出工作的合理规划以及正确维护。若是采用此种方法，开发人员就很有可能将释出周期缩短至一个月，基于Pipeline的CI/CD也会相应得到更多应用。
留言 点赞 关注
我们一起分享AI学习与发展的干货
欢迎关注全平台AI垂类自媒体 “读芯术”
