选择代码流策略
选择适合你的团队工作方式的代码流策略非常重要。 你有几个策略需要考虑。 完成本模块后，可以浏览选项。 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 分支中。 拉取请求获得批准并合并后，它将成为中央代码库的一部分。
分支工作流是什么样的？
步骤 1：当你开始处理新功能或 bug 修复时，首先要做的是确保从最新的稳定代码库开始。 为此，可以将 main 分支的本地副本与服务器副本同步。 这样就可拉取自你上次同步以来其他开发人员已推送到服务器的 main 分支的所有更改。
步骤 2：为确保你安全地使用代码副本，只需为该功能或 bug 修复创建一个新分支。 可以想象，你正在处理的所有任务的分支众多，可能让你很难记得住，因此良好的命名约定在此处至关重要。
在更改文件之前，请签出新分支，以便你知道你正在处理来自该分支而不是其他分支的文件。 可以随时通过签出该分支来切换分支。
步骤 3：你现在可以安全地进行任何你想要的更改，因为些更改只在你的分支中进行。 在工作时，可以将更改提交到你的分支，以确保不会丢失任何工作，并提供一种方法回滚对以前版本所做的任何更改。 在可以提交更改之前，还需要暂存文件，以便 Git 知道你准备提交哪些文件。
步骤 4：下一步是将本地分支推送或上传到远程存储库（如 GitHub），以便其他人可以看到你正在处理的内容。 别担心，这还不会合并你的更改。 你可以根据需要随时向上推送你的工作。 事实上，这种方法适合备份工作或让你能够在多台计算机上工作。
步骤 5：这是常见步骤，但不是必需步骤。 当你确信你的代码按照你希望的方式工作时，就可将远程 main 分支拉取或合并回本地 main 分支中。 远程分支已发生改变，而本地 main 分支尚未发生。 将远程 main 分支与你的分支同步后，将本地 main 分支合并到工作分支中，然后再次测试生成。
此过程有助于确保功能使用最新代码。 它还有助于确保在提交拉取请求时可以顺利集成工作。
步骤 6：现在需要将本地代码提交并向上推送到托管存储库。 这与步骤 3 和 4 相同。
步骤 7：你最终准备好向远程 main 分支提交更改。 为此，你开始拉取请求。 在 Azure Pipelines 或其他 CI/CD 系统中配置时，此步骤会触发生成过程，你可观察所作更改通过管道移动的情况。 生成成功且其他人批准你的拉取请求后，你的代码可合并到远程 main 分支中。 （更改合并仍然需要手动完成。）
Andy：这看起来很复杂，很难学。
Mara：Git 看起来令人生畏，因为它是如此的强大，但是在你熟悉了流程之后，就会觉得很自然。
你每天将仅使用几个命令。 摘要如下：
| 类别 | 执行此任务 | 使用此命令 |
|---|---|---|
| 存储库管理 | 创建 Git 存储库 | git init |
| 下载远程存储库 | git clone |
|
| 分支 | 创建分支 | git checkout |
| 暂存和提交更改 | 查看哪些文件已更改 | git status |
| 暂存要提交的文件 | git add |
|
| 向分支提交文件 | git commit |
|
| 远程同步 | 从远程存储库下载分支 | git pull |
| 将分支上传到远程存储库 | git push |
Andy：这听起来是个不错的起点。 我完全可以应付。 我可以根据需要了解更高级的命令。