从私信到协作开发:GitHub Pull Request 的发展史
🧵 本文由 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 按钮。
代码审查 Code Review
在 Pull Requests 2.0 前,GitHub 在某种程度上其实也有代码审查。2008 年就已经有「提交评论」的功能了,你可以在任何 commit 或者某行代码下面评论,有评论的地方会被气泡标记。
虽然功能还很基本,没有状态,没有针对基于分支的工作流优化过,不过已经比「全部回复」进阶很多了(想象一下线程变多以后会变得多乱😅)。
Pull Request 2.0
两年,20 万个 PR 之后,PR 才从私信形式逐渐进化成更类似其目前协作式代码审查的形式,PR 变成了一连串关于你要合并的代码的讨论,代码变动对比 view,这是 GitHub 对于代码审查的解读,也是 GitHub 对于协作式开发的愿景的代表。
合并按钮 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。
番外
关于产品的思考
很难想象 GitHub 推出的时候并没有 Pull Request 这个功能,完整的 PR 工作流也是几年之后才逐渐完善的,团队花了很多年才创造了现在被认为理所当然的用户体验。不过,他们的想法「基于 web 的 git 工作流」从开始起就一直存在。
有很多关于产品的思考,我们现在(和未来)也正在推敲 & 完善在「数据库 CI/CD 流」上,如何能提供最优秀的用户体验。
协作 Teamwork makes the dream work 🦄️
Chris 提到「相信最好的那些软件是通过协作完成的,而 PR 就是一个很好的例子」,我们完全同意,Bytebase 的初衷就是促进 DevOps 团队进行更好的协作,我们在设计产品时也会考虑如何更方便、安全、高效地达到这一目的。
适当清理功能 🧹
上文提到的 Fork Queue 和私信这两项功能现在都没有了,不过他们存在过(就你会说废话),在 2012 年被优化了。合并按钮很好地取代了分叉队列,而且市面上不乏私信的工具,谁还需要多一个收件箱呢?
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 其实并不相互排斥。
版权声明: 本文为 InfoQ 作者【Bytebase】的原创文章。
原文链接:【http://xie.infoq.cn/article/4e2fa910e6729ec9146212755】。
本文遵守【CC-BY 4.0】协议,转载请保留原文出处及本版权声明。
评论