协作的核心——拉取请求

拉取请求不仅仅是传统的代码审查，它还是一种实现以下目标的方式：

  • 协作开发代码

  • 分享知识

  • 创建对代码的共同拥有感

  • 跨团队协作

那么，究竟什么是拉取请求呢？拉取请求（也称为合并请求）是将来自其他分支的更改集成到 Git 仓库的目标分支中的过程。这些更改可以来自同一仓库中的一个分支，也可以来自一个 fork（你仓库的副本）。拉取请求通常缩写为 PR。没有写权限的人也可以 fork 你的仓库并创建拉取请求。这允许开源仓库的所有者在不赋予每个人写权限的情况下接受贡献。因此，在开源世界中，拉取请求是集成更改到仓库中的默认方式。

拉取请求还可以用于跨团队协作，这种方式被称为 “内源”（inner source），在《第5章，开源和内源对软件交付性能的影响》中会详细介绍。

关于 Git

Git 是一个分布式版本控制系统（RCS）。与中央版本控制系统（central RCS）不同，每个开发者在他们的机器上存储整个仓库，并与其他仓库同步更改。Git 基于一些简单的架构设计。每个版本都作为整个文件存储——不仅仅是更改。通过哈希算法跟踪更改。版本和文件系统作为一个有向无环图（DAG）存储，并通过父对象的哈希链接。这使得分支和合并更改变得非常容易。因此，Git 自我描述为：git——愚蠢的内容追踪器（参见图 3.1 的 Git 手册页）。

Git 是由 Linus Torvalds 在 2005 年为 Linux 内核创建的版本控制系统。在 2005 年之前，BitKeeper 被用于此目的，但由于许可证的更改，BitKeeper 无法再在不收费的情况下用于开源项目。

Git 是目前最流行的版本控制系统，关于 Git 的书籍非常多（例如 Chacon S. 和 Straub B., 2014；Kaufmann M., 2021 等）。Git 是 GitHub 的核心，但在本书中，我更关注的是 GitHub 作为 DevOps 平台，而非作为版本控制系统。

在《第11章，基于主干的开发》中，我将讨论与工程速度相关的分支工作流，但不会深入探讨分支和合并的内容。有关更详细的内容，请参阅《进一步阅读和参考文献》部分。
image 2024 12 26 20 54 07 869
Figure 1. 图 3.1 – Git 的 man 页面——愚蠢的内容追踪器

Git 按行版本控制文本文件。这意味着拉取请求关注的是更改的行：一行可以被添加、删除或同时进行更改——在这种情况下，你可以看到旧行和新行之间的差异。在合并之前，拉取请求允许你执行以下操作：

  • 审查更改并对其发表评论

  • 在不首先合并的情况下，将更改与源仓库中的新代码一起构建和测试

只有当更改通过所有检查后，它们才会通过拉取请求自动合并回去。

在现代软件工程中，由于一切皆为代码，它不仅仅是源代码。你可以在以下方面进行协作：

  • 架构、设计和概念文档

  • 源代码

  • 测试

  • 基础设施（作为代码）

  • 配置（作为代码）

  • 文档

所有这些都可以通过文本文件来完成。在上一章中，我已经提到过，markdown 是人类可读文件的标准。它非常适合用来协作处理概念文档和文档。如果需要可以归档或发送给客户的物理文档，你还可以将 markdown 渲染为便携文档格式（PDF）。你还可以通过图表扩展 markdown，例如使用 Mermaid（见 https://mermaid-js.github.io/mermaid/）。

尽管 markdown 是用于人类可读文件，YAML（YAML Ain’t Markup Language）则用于机器可读文件。因此，通过组合源代码、markdown 和 YAML，你可以自动化创建开发生命周期中的所有工件，并且像协作源代码一样协作修改它们！

示例

在 GitHub，基本上所有内容都是通过 markdown 处理的。即使是法律团队和人力资源（HR）也使用 markdown、问题和拉取请求来协作处理合同。一个例子是招聘流程：职位描述存储为 markdown 格式，整个招聘流程使用问题进行跟踪。其他例子包括 GitHub 网站政策（如服务条款或社区准则）。它们都是用 markdown 编写的，并且是开源的（https://github.com/github/site-policy）。

如果你想了解更多关于 GitHub 团队协作的内容，可以查看这个视频：https://youtu.be/HyvZO5vvOas?t=3189。