选择代码流策略

选择适合你的团队工作方式的代码流策略非常重要。 你有几个策略需要考虑。 完成本模块后，可以浏览选项。 Tailspin Web 团队决定开发基于 Git 和 GitHub 的代码流策略。

当 Mara 设置 Azure Boards 时，她和团队确定了一些需要处理的初始任务。 其中一项任务是创建基于 Git 的工作流。

让我们来听听团队是如何想出更好的合作方式的。 目前，他们使用的是集中式版本控制系统，但计划迁移到分布式系统 Git。

当 Andy 走进来的时候，Mara 正在孜孜不倦地研究她分配到的功能。

Andy：嗨，Mara。 在今早的领导会议中，有人提出我们的团队和游戏开发团队使用的是不同的版本控制系统。 为了简化我们在团队之间共享资源的方式，我们被要求迁移到一种可更好地处理协作的分布式版本控制系统中。

Mara：很高兴知道这一消息。 如果你记得，我们在自己的记事板上写了这一点。 目前，我们使用的是集中式版本控制系统。 这目前非常适合我们，但我同意当我们开始在团队之间共享信息，且我们的团队规模壮大时，分布式版本控制系统是更好的选择。 我们将在会议上讨论的另一项任务是提高透明度，让所有相关者都知道每个人在做什么。 我认为像 Git 这样的分布式源代码管理系统也会有所帮助。

Andy：我一直想尝试 Git。 但好像一直没时间。 Git 很难了解或设置么？ 如果合理的话，也许我们现在就能解决。 我厌倦了总是拖延。 要是能够查看每个人都在做什么，还能访问整个存储库，那就太好了。 好吧，那它到底是怎么回事呢？

Mara：让我来说明一下，然后你可决定我们是否需要立即实现它。

Mara 和 Andy 来到白板前讨论版本控制。

什么是 Git 和分布式版本控制呢？

Mara：左边的图是我们现在使用的集中式版本控制。 在 Team Foundation 版本控制 (TFVC) 中，我们有一个集中版本的代码库 ，可供所有人使用。 我们每个人都处理需要更改的文件，处理完这些文件之后再将其合并回主存储库。

Andy：是的，这适合我们。 除了有一项中断性变更合并到中央存储库而使我遭到阻止的那次。

Mara：没错！ 你被阻止了 。 我们可以使用 TFVC 的分支策略来解决阻止问题，但是在我们当前的配置中，合并可能会变得更加复杂。 当我们遇到这种中断性变更 后，必须解决该问题，否则没人能完成任何工作。 这个问题一直潜伏着，因为我们都使用相同的代码副本。

右侧是分布式版本控制的示意图。 我们仍然有一个中央存储库 ，它是稳定版本的代码库，但每位开发人员都有自己的副本 供工作使用。 这让我们能够试验和尝试各种方法，而不影响中央存储库。

分布式版本控制还可确保只有工作代码 合并到中央存储库中。 我们甚至可以设置它，以便代码在被评审之前不能合并。

Azure DevOps 的优点在于它既适用于集中式版本控制系统，也适用于分布式版本控制系统。

Andy：当不止一个人更改同一个文件时会发生什么？

Mara：通常情况下，Git 可以自动合并多个更改。 当然，我们希望始终确保这些更改的组合能够产生有效的代码。 Git 无法自动合并更改时，它会直接在文件中标记冲突，以便人工选择接受哪些更改。

Andy：目前，我们的代码存储在我们自己的服务器中。 如果我们移到使用分布式版本控制，代码将存储在何处？

Mara：很高兴听到这个问题。 这就需要用到托管了。

在哪里可以托管存储库？

Mara：当我们决定在何处托管存储库时，我们有几种选择。 例如，我们可将它们托管在本地服务器、Bitbucket 或 GitHub 中。 Bitbucket 和 GitHub 是基于 Web 的托管解决方案。 我们可以从任何位置访问它们。

Andy：你用过其中一种解决方案吗？

Mara：我以前用过 GitHub。 它具有对开发人员很重要的功能，比如可以方便地从命令行或在线门户访问更改日志和版本控制功能。

Andy：Git 是如何工作的？

如何使用 Git？

Mara：正如我前面提到的，通过分布式系统，开发人员可随意访问他们需要的任何文件，而不会影响其他开发人员的工作，这是因为他们有自己的存储库副本。 克隆是存储库的本地副本。

当我们处理某个功能或 bug 修复时，我们通常希望尝试不同的方法，直到找到最佳解决方案。 但是，在主代码库的副本上尝试代码不是一个好主意，因为你可能不想保留最初的几次尝试。

为了向你提供更好的选择，Git 有一项名为“分支”的功能；通过它，你可维护任意数量的副本，并且只重新合并你希望保留的副本。 这样可以使主分支保持稳定。

Andy：到目前为止，我理解了这些概念。 那如何签入我的代码？

我的本地更改如何进入主代码库？

Mara：在 Git 中，默认分支（主干）通常被称为 main。

当你认为你的代码已准备好合并到所有开发人员共享的中央存储库中的 main 分支中，就可创建所谓的“拉取请求”。 创建拉取请求时，你是在告诉其他开发人员，你已经准备好要评审的代码，并且希望将其合并到 main 分支中。 拉取请求获得批准并合并后，它将成为中央代码库的一部分。

分支工作流是什么样的？

Andy：这看起来很复杂，很难学。

Mara：Git 看起来令人生畏，因为它是如此的强大，但是在你熟悉了流程之后，就会觉得很自然。

你每天将仅使用几个命令。 摘要如下：

Andy：这听起来是个不错的起点。 我完全可以应付。 我可以根据需要了解更高级的命令。