使用 Git 实现超强的持续交付

说实话，并不是说 Git 本身非常适合持续交付。这是因为分支工作流程非常适合 CD，而 Git 非常适合分支工作流程。除了是 CD 的 BFF 外，分支与合并工作流程还能让您解决棘手的错误、尝试新技术或从头开始编写新功能，而不必担心您的变更会阻碍队友推进自己的任务。

显然，Subversion 和其他传统的版本控制系统也允许您进行分支。但是我们暂且先不提，介绍分支的邪恶双胞胎：合并。

像 Subversion 这样的传统版本控制系统根本不擅长跟踪存在于不同分支上的文件版本，需要合并时，Subversion 必须停下来询问方向。（您懂得...小小的弹出窗口问“您想要合并版本中的这行还是那行？”）合并期间需要大量的人工互动，这一事实促使团队冻结代码，这样无论谁在进行合并，都不会因为其中一个分支出现的新变更而中断。而且代码冻结非常昂贵：这段时间工作效率很低。

另一方面，Git 非常擅长跟踪存在于不同分支上的不同版本文件所做的变更，而且它始终知道该文件的共同祖先是什么样子。因此，它基本上有一个内置的 GPS，可以让它在合并处导航，而不必一直停下来询问路线。

使用 Git，您可以自由地利用分支的力量，这在 Subversion 中是不切实际的。分支和合并所涉及的开销非常微不足道，以至于只能存活一两天的分支不仅变得可行，而且大有裨益。

好吧，很好。但是，究竟是什么让分支在持续交付方面如此强大？

举个例子，Atlassian 的所有开发团队都同意，绝不直接向主分支或稳定分支做出任何提交。每个人都在分支上工作。事实上，我们非常看好分支，以至于我们已经开始为我们解决的每个 Jira 问题创建一个单独的分支——稍后会详细介绍。

无论如何，这意味着员工可以随心所欲地打断任意数量的测试并对分支造成尽可能多的伤害！主分支仍然处于您可以从中发布的状态，在这个状态下，您可以在不继承一堆损坏代码的情况下从主分支上创建新分支。这对于 CD 和一般开发人员的生产效率（更不用说士气了）来说是一种胜利。

分支可以帮助您接受团队外部的贡献

Git 的分支工具，尤其是用于分叉整个代码存储库的工具，可以轻松地从直属团队以外的人那里获得贡献：承包商、合作伙伴公司的开发人员、来自其他业务部门的开发人员等。您不必担心那些不熟悉您代码库的人会随意变更关键分支并阻碍您交付新代码的能力。

同样，对他们的分支或分叉代码存储库进行严格的自动化测试是实现协作愉快的关键。在批准任何到主代码行的合并之前，您需要查看他们的构建和测试结果。

分支成功完成 = 项目跟踪清晰度

现在很流行为您实现的每个故事、错误修复或任务（即每个 Jira 问题）创建一个开发分支。几年前，我们在 Atlassian 采用了这种逐问题分支模式，一直到现在！它在我们的客户中也变得很受欢迎。

为每个问题创建分支可以轻松地手动选择要发布到生产环境或捆绑到版本中的变更。鉴于您不是在主分支上大肆变更，您可以选择进入主分支的内容和时间。您可以交付一部长篇故事的 MVP 加上一个不错的选择，而不是等到所有内容都全部完成。或者发布一个错误修复程序，然后在常规版本的框架内进行修复。即使修复很紧急，您也不必为了删除那个变更而放弃其他尚未准备好交付的变更。

而这种单一代码变更的便捷性就是持续交付的本质。

这种方法不仅可以将未经验证的代码排除在主分支外，当您在分支名称中包含相关的 Jira 问题密钥和开发人员的姓名或首字母缩写时，每个问题所处的开发状态就显而易见了。

请注意上图中使用的命名惯例：它是正在实施的 Jira 问题的唯一密钥，外加对该问题全部内容的简短、人类可读的描述。因此，作为版本管理者或其他利益相关者，您可以看看上面显示的代码存储库，一眼就知道 AMKT-13952 跟踪的用户故事已经准备好发布了，因为您可以看到它已经合并到主分支了。无需所有手动操作即可实现可追溯性——棒极了。

问得好！由于本网站上的其他文章更深入地探讨了每个阶段，因此我将在这里快速介绍一下。

• 为您即将处理的问题创建一个分支。在分支名称中包含 Jira 问题密钥，这样分支的用途就很清楚了。而且，如果您使用的是其他 Atlassian 工具，例如 Bitbucket 和 Bitbucket Pipelines，他们会获取问题密钥，并在问题、分支、所有提交、构建、拉取请求和与该问题相关的部署之间创建链接。换句话说，问题密钥非常神奇。
• 在分支上进行变更。您要进入自己的小世界了，可以随心所欲的操作了。尝试新事物、打破东西，没关系，因为您还会...
• 将您的分支置于 CI 之下。您和团队可以决定是否在此处运行专门的测试，例如负载测试或基于用户界面的端到端测试，以及是否在每次将变更推送到分支时自动触发测试运行。Atlassian 的团队通常在开发分支上进行单元和集成级测试。
• 经常使用主分支的最新版本更新您的分支。您可以使用变基或分支提交来完成此操作，这完全取决于您自己。（但请记住，不要对您与其他开发人员共享的分支进行变基——这会惹恼他们。）无论哪种方式，您都能在合并之前发现集成冲突，这反过来又有助于保持主分支的干净。
• 当您准备好向上合并时，请创建一个拉取请求。这意味着实现已完成，您已经从队友那里拉取变更并已解决由此产生的所有冲突，并且针对您的分支的所有测试都已通过。
• 合并以及随意部署。有些团队更喜欢将每项变更合并到主分支并且所有测试都通过后立即自动交付，即持续部署模型。其他团队更喜欢人为决定要交付哪些变更以及何时交付，这由您和团队决定。

就是这样，分支工作流程使持续交付成为一项更简单的提议，而 Git 消除了分支的麻烦。继续阅读，深入了解如何设置 Git 存储库使其适合 CD，以及如何使用 Atlassian 工具将所有这些想法付诸实践。下一页见！