一个Pull Request不仅仅是一项传统的代码审阅。还能实现以下几点:
●代码协作
●分享知识
●创建代码的共享所有权
●跨团队协作
但Pull Request到底是什么?Pull Request(也称为Merge Request)是将来自其他分支的更改集成到Git代码存储库中的目标分支的过程。更改可以来自存储库的分支,也可以来自派生(存储库的副本)。Pull Request通常缩写为PR。没有写入权限的人也可以派生存储库并创建PR。这使得开源存储库的所有者无须向每个人授予存储库的写入访问权限,他人就能参与贡献。这就是为什么在开源世界中,Pull Request是将更改集成到代码存储库中的默认方式。
Pull Request还可用于以称为内部源代码的开源风格进行跨团队协作(参见第5章)。
Git是一个分布式版本控制系统(Revision Control System,RCS)。与中央RCS相比,每个开发者都将整个存储库存储在自己的机器上,并与其他存储库同步更改。Git基于一些简单的架构决策。每个版本都存储为整个文件,而不仅仅包括更改部分,并使用哈希算法跟踪更改。修订和文件系统存储为有向无环图(DAG),该图使用父对象的散列进行链接。这使得分支和合并更改变得非常容易。
Git是Linus Torvalds在2005年为Linux内核创建的RCS。直到2005年,BitKeeper一直用于版本控制,但由于许可证的变更,BitKeeper不能再免费用于开源项目了。
Git是当今最流行的RCS,有很多关于Git的书(参见Chacon S.和Straub B., 2014;Kaufmann M., 2021等)。Git是GitHub的核心,但在本书中,GitHub作为一个DevOps平台,而不是RCS。
第11章将讨论与工程速度相关的分支工作流,但不会深入讨论分支和合并。请参阅拓展阅读和参考资料部分来了解相关内容。
图3-1为Git的手册页。
Git按行对文本文件进行版本管理。这意味着Pull Request关注已更改的行:可以添加、删除,或同时添加和删除一行。在本例中,可以看到更改前后旧行和新行之间的差异。在合并之前,Pull Request允许用户做以下事情:
●审阅更改并对其进行评论。
●在源存储库中构建并测试更改和新代码,而不需要首先合并它。
只有当更改通过所有审阅时,它们才会被Pull Request自动合并。
在现代软件工程中一切都是代码,它不仅仅是关于源代码。读者还可以在以下方面进行合作:
●架构、设计和概念文档
●源代码
●测试
●基础设施(以代码形式)
●配置(以代码形式)
●文档
图3-1 Git手册页:the stupid content tracker
任何事情都可以在文本文件中完成。在前一章已经讨论过将Markdown作为人类可读文件的标准。它非常适合在目录文件和文档上进行协作。如果需要存档或发送给客户一份实际文件,还可以将Markdown转变为可移植文档格式(PDF)。用户可以使用图表扩展Markdown。例如,使用Mermaid(参见https://mermaid-js.github.io/mermaid/)。Markdown是针对人类可读的文件,而YAML Ain’t Markup Language(YAML)是针对机器可读的文件。因此,通过源代码、Markdown和YAML的组合,可以自动创建开发生命周期的所有工件,并在更改上进行协作,就像在源代码上协作一样!
在GitHub,所有事项基本上都是用Markdown来处理的,甚至法律团队和人力资源(HR)也使用Markdown、issue和Pull Request来协作。例如在招聘流程中:职位描述存储为Markdown文件,并且使用issue跟踪完整的招聘流程。又如GitHub网站政策(如服务条款或社区指南),都是Markdown格式,而且都是开源的(https://github.com/github/site-policy)。
如果读者想了解更多关于GitHub团队协作的信息,请参阅https://youtu.be/HyvZO5vvOas?t=3189。