从私信到协作开发：GitHub Pull Request 的发展史

🧵 本文由 Chris Wanstrath (GitHub Co-Founder) Twitter 上某 Thread (https://twitter.com/defunkt/status/1623393340967501824) 启发。

因为 GitHub Pull Request 的出现，研发协同的理念得以在全球发扬光大。PR 的缩写也不再是 Public Relation 的专属，接下来让我们回顾一下 GitHub PR 的发展简史。

Pull Request 发展史

Pull Request 使开发者可以更轻松地协作、分享和审查代码更改。开发者将自己的代码更改提交给一个项目，并请求该项目的维护者审查和合并这些更改，维护者可以提供反馈和建议，以确保代码质量和项目的一致性。一旦维护者接受 Pull Request，这些更改就会被合并到主分支中。

GitHub 背后的想法是用 git 基于邮件的工作流程，提供一个基于 web 的替代方案。Pull Request 则是基于 git 的 request-pull 子命令的（https://git-scm.com/docs/git-request-pull）。

GitHub beta 版本发布的时候，还没有 Pull Request 这个功能，不过因为是社交网络，所以有私信功能。所以那个时候要提 PR 的时候只是给人家发私信：请在这个分支上拉取一下我的 fork。

不过，不久之后就有了 Pull Request 按钮：（https://github.blog/2008-02-23-oh-yeah-there-s-pull-requests-now/）。

代码审查 Code Review

在 Pull Requests 2.0 前，GitHub 在某种程度上其实也有代码审查。2008 年就已经有「提交评论」的功能了，你可以在任何 commit 或者某行代码下面评论，有评论的地方会被气泡标记（https://github.blog/2008-04-10-commit-comments/）。

虽然功能还很基本，没有状态，没有针对基于分支的工作流优化过，不过已经比「全部回复」进阶很多了（想象一下线程变多以后会变得多乱😅）。

Pull Request 2.0

两年，20 万个 PR 之后，PR 才从私信形式逐渐进化成更类似其目前「协作式代码审查」的形式（https://github.blog/2010-08-31-pull-requests-2-0/），PR 变成了一连串关于你要合并的代码的讨论，代码变动对比 view，这是 GitHub 对于代码审查的解读，也是 GitHub 对于协作式开发的愿景的代表。

合并按钮 The Merge Button

Pull Request 2.0 往前踏了一大步，代码审查和接受补丁（那时候的 Fork Queue 已经可以 cherry-pick 了，虽然跟现在的概念不完全一样）都更方便了，但还是缺了点什么。2011 年， PR 有了下一个质的飞跃：合并按钮（https://github.blog/2011-04-25-the-merge-button/），合并一个 PR 再也不用通过 git 命令行输入好几个 command 了，只要点一下合并按钮，就能自动合并并关闭 PR。

合并队列 Merge Queue

随着开发团队和系统的规模不断扩大，并发变化出现的可能也更多，GitHub 一个月前宣布了「合并队列」Pull request merge queue，通过在合并前更新 PR 来避免合并没有经过最新版本的基础分支测试的代码，而不会中断 CD。https://github.blog/changelog/2023-02-08-pull-request-merge-queue-public-beta

番外

关于产品的思考

很难想象 GitHub 推出的时候并没有 Pull Request 这个功能，完整的 PR 工作流也是几年之后才逐渐完善的，团队花了很多年才创造了现在被认为理所当然的用户体验。不过，他们的想法「基于 web 的 git 工作流」从开始起就一直存在。

有很多关于产品的思考，我们现在（和未来）也正在推敲 & 完善在「数据库 CI/CD 流」上，如何能提供最优秀的用户体验。

Team work makes the dream work

Chris 提到「相信最好的那些软件是通过协作完成的，而 PR 就是一个很好的例子」，我们完全同意，Bytebase 的初衷就是促进 DevOps 团队进行更好的协作，我们在设计产品时也会考虑如何更方便、安全、高效地达到这一目的。

适当清理功能 🧹

上文提到的 Fork Queue 和私信这两项功能现在都没有了，不过他们存在过（就你会说废话），在 2012 年被优化了。合并按钮很好地取代了分叉队列，而且市面上不乏私信的工具，谁还需要多一个收件箱呢？https://github.blog/2012-04-03-spring-cleaning/

Schema 设计的重要性 🏗

另外，产品的功能来来去去，但涉及信息结构 Schema 的问题可能真的要从一开始就想清楚 😄。比如 13 年前，这个 PR 里定义的组织模型，也一直沿用至今。

关于 GitHub 为什么用的是 MySQL

Chris 提到了一个小插曲：在早期差点就把 GitHub 从 MySQL 迁移到 Postgres 了，甚至已经创建分支了，但他为私信功能写的一些糟糕的 SQL 查询语句在 Postgres 里面不 work，于是 MySQL 就留下来了 🐘。

---

最后我们再来总结一下 PR 的成长史：

🥚 2008 年刚推出的时候，PR 其实还是私信，不过不久就成为了独立按钮，很快用户也能评论提交的代码了；

🐣  PR 2.0 后，它才逐渐演变成一个完整的流程（更接近现在的样子），包含对于代码的讨论和前后对比

🐥 之后加上了了合并按钮，到今年进阶有了合并队列。

🐤 What's next?

另：擅长 SQL 和不擅长 SQL 其实并不相互排斥。