总结

在本章中，你了解了同步和异步工作的优缺点。你可以利用这些知识创建高效的异步工作流，从而促进跨团队的合作，并使远程和混合团队能够跨多个领域和时区运作。你还了解了 GitHub Discussions、Pages 和 wikis 如何帮助你在代码和需求以外的主题上实现异步工作流。

在下一章，我将解释开源和内部源对你的软件交付绩效的影响。

案例研究

Tailwind Gears 的两个试点团队首先将他们的代码迁移到 GitHub 仓库。其中一个团队已经在使用 Bitbucket 服务器上的 Git，对于这个团队来说，迁移就像将仓库推送到一个新的远程仓库一样简单。另一个团队则使用 Team Foundation Server (TFS) 版本控制系统，他们必须先将代码迁移到 Git，再将其推送到 GitHub。

两个团队决定参加为期两天的 Git 培训，以便能够充分利用 Git 的强大功能，并制作易于审查的良好提交。他们使用草稿拉取请求，以便团队中的每个人始终了解其他成员正在做什么，并且他们暂时要求至少两名审阅者。

许多工作仍然在仓库之外进行，主要是在公司 SharePoint 服务器上存储的 Word、Excel 和 Visio 文档中。部分文档会转换为便携式文档格式（PDF），并在发布符合某些规定的产品之前由管理层签署。这些文档太多，无法一次性全部转换为 Markdown。团队决定在他们的代码仓库中创建一个基于 Markdown 的自定义 Wiki，将所有内容集中在代码旁边。他们在 SharePoint 上的当前文档中添加了链接。每次文档需要更改时，内容将被移到 Markdown 文件中，链接将被删除。管理层不再签署 PDF 文件，而是作为代码拥有者被添加到相应的文件中，并直接在拉取请求中批准更改。结合审计日志，这对于所有必要的合规审计都是有效的。

在迁移到新平台时，许多方面对两个团队都很重要，后来其他团队也会迁移到新平台。因此，他们创建了一个共享平台仓库。该仓库包含 GitHub Discussions，以便与所有工程师合作，即使他们尚未加入这两个团队中的任何一个。同时，他们使用 GitHub Pages 设置了一个技术博客，用于分享技巧和经验。Jekyll 网站也用于共同协作审查指南和行为准则。

进一步阅读与参考资料

以下是本章中的参考资料，你可以使用这些资源来深入了解相关主题：