本文由 Chris Wanstrath (GitHub Co-Founder) Twitter 上某 Thread 启发。
因为 GitHub Pull Request 的出现,研发协同的理念得以在全球发扬光大。PR 的缩写也不再是 Public Relation 的专属,接下来让我们回顾一下 GitHub PR 的发展简史。
Pull Request 发展史
Pull Request 使开发者可以更轻松地协作、分享和审查代码更改。开发者将自己的代码更改提交给一个项目,并请求该项目的维护者审查和合并这些更改,维护者可以提供反馈和建议,以确保代码质量和项目的一致性。一旦维护者接受 Pull Request,这些更改就会被合并到主分支中。GitHub 背后的想法是用 git 基于邮件的工作流程,提供一个基于 web 的替代方案。Pull Request 则是基于 git 的 request-pull 子命令的。GitHub beta 版本发布的时候,还没有 Pull Request 这个功能,不过因为是社交网络,所以有私信功能。所以那个时候要提 PR 的时候只是给人家发私信:请在这个分支上拉取一下我的 fork。不过,不久之后就有了 pull request 按钮。
![](https://pic3.zhimg.com/80/v2-6c46a8fc00ea47d04ef21cf3699dfbea_1440w.webp)
代码审查 Code Review
在 Pull Requests 2.0 前,GitHub 在某种程度上其实也有代码审查。2008 年就已经有「提交评论」的功能了,你可以在任何 commit 或者某行代码下面评论,有评论的地方会被气泡标记。
![](https://pic4.zhimg.com/80/v2-b5934e8c0baeb25813305bb4a77d1ee3_1440w.webp)
虽然功能还很基本,没有状态,没有针对基于分支的工作流优化过,不过已经比「全部回复」进阶很多了(想象一下线程变多以后会变得多乱 )。
Pull Request 2.0
两年,20 万个 PR 之后,PR 才从私信形式逐渐进化成更类似其目前「协作式代码审查」的形式,PR 变成了一连串关于你要合并的代码的讨论,代码变动对比 view,这是 GitHub 对于代码审查的解读,也是 GitHub 对于协作式开发的愿景的代表。
![](https://pic2.zhimg.com/80/v2-4dcf9eebf51a6d10d7479b152aec2341_1440w.webp)
合并按钮 The Merge Button
Pull Request 2.0 往前踏了一大步,代码审查和接受补丁(那时候的 Fork Queue 已经可以cherry-pick了,虽然跟现在的概念不完全一样)都更方便了,但还是缺了点什么。2011 年, PR 有了下一个质的飞跃:合并按钮,合并一个 PR 再也不用通过 git 命令行输入好几个 command 了,只要点一下合并按钮,就能自动合并并关闭 PR。
合并队列 Merge Queue
随着开发团队和系统的规模不断扩大,并发变化出现的可能也更多,GitHub 一个月前宣布了「合并队列」Pull request merge queue,通过在合并前更新 PR 来避免合并没有经过最新版本的基础分支测试的代码,而不会中断 CD。
![](https://pic4.zhimg.com/80/v2-ecd565954459579cbcd27b9b2f4ecfe7_1440w.webp)
番外
关于产品的思考
很难想象 GitHub 推出的时候并没有 Pull Request 这个功能,完整的 PR 工作流也是几年之后才逐渐完善的,团队花了很多年才创造了现在被认为理所当然的用户体验。不过,他们的想法「基于 web 的 git 工作流」从开始起就一直存在。
有很多关于产品的思考,我们现在(和未来)也正在推敲 & 完善在「数据库 CI/CD 流」上,如何能提供最优秀的用户体验。
Team work makes the dream work
Chris 提到「相信最好的那些软件是通过协作完成的,而 PR 就是一个很好的例子」,我们完全同意,Bytebase 的初衷就是促进 DevOps 团队进行更好的协作,我们在设计产品时也会考虑如何更方便、安全、高效地达到这一目的。
适当清理功能
上文提到的 Fork Queue 和私信这两项功能现在都没有了,不过他们存在过(就你会说废话),在 2012 年被优化了。合并按钮很好地取代了分叉队列,而且市面上不乏私信的工具,谁还需要多一个收件箱呢?
![](/qrcode.jpg)
Schema 设计的重要性
另外,产品的功能来来去去,但涉及信息结构 Schema 的问题可能真的要从一开始就想清楚 。比如 13 年前,这个 PR 里定义的组织模型,也一直沿用至今。
![](https://pic4.zhimg.com/80/v2-beb9cc28b76b0ee1295b2bcfff769b9b_1440w.webp)
关于 GitHub 为什么用的是 MySQL
Chris 提到了一个小插曲:在早期差点就把 GitHub 从 MySQL 迁移到 Postgres 了,甚至已经创建分支了,但他为私信功能写的一些糟糕的 SQL 查询语句在 Postgres 里面不 work,于是 MySQL 就留下来了 。
最后我们再来总结一下 PR 的成长史:
2008 年刚推出的时候,PR 其实还是私信,不过不久就成为了独立按钮,很快用户也能评论提交的代码了;
PR 2.0 后,它才逐渐演变成一个完整的流程(更接近现在的样子),包含对于代码的讨论和前后对比
之后加上了了合并按钮,到今年进阶有了合并队列。
What's next?
另:擅长 SQL 和不擅长 SQL 其实并不相互排斥。