千家信息网

怎么做一个完美的Pull Request

发表于:2026-11-01 作者:千家信息网编辑
千家信息网最后更新 2026年11月01日,这篇文章主要讲解了"怎么做一个完美的Pull Request",文中的讲解内容简单清晰,易于学习与理解,下面请大家跟着小编的思路慢慢深入,一起来研究和学习"怎么做一个完美的Pull Request"吧
千家信息网最后更新 2026年11月01日怎么做一个完美的Pull Request

这篇文章主要讲解了"怎么做一个完美的Pull Request",文中的讲解内容简单清晰,易于学习与理解,下面请大家跟着小编的思路慢慢深入,一起来研究和学习"怎么做一个完美的Pull Request"吧!

1.添加关于"为什么"的代码注释

在写一个新功能的时候,会有很多与之相关的信息。写代码时要全盘考虑需求,第三方系统的局限性,以及和遗留代码库的交互。但是别人不了解其上下文来源,所以看到这个代码时会问"它为什么在这?"或是"为什么要选择这种方法?"因此要通过添加解释性的注释,让阅读代码的人提前知晓"为什么"。笔者不认同一些人宣扬的观点:注释有害,应当忽略。

注释有很多种类。那些描述代码用途的确实是累赘。提取一个方法,采用一个精心挑选的命名,就能消除这种麻烦。另一方面,当解释为什么这样写代码时,也增加了代码阅读者的信息量。这些注释将阅读者的认知水平理想化地提高到了与编码人员相同的层级,这有助于增进对代码的理解。

笔者的注释通常会给出类存在的原因、相关资源的链接以及代码的前因后果:

# First Crew Dragon launch was postponeddue to bad weather,          # and now we needan event for the "second" first launch.          # Hence the stupidname.          classSecondFirstCrewDragonLaunch           ...          End

2.描述清晰

有关pull request的描述为审查者提供任务最初的上下文,包括:

  • 标签的链接。

  • 对已完成事件的总结(如果不能从pullrequest的标题中看出)。

  • 相关pull request的链接(例如在另一服务中的相关变化)。

不要把自认为理解代码需要的信息放在对pullrequest的描述里,应当进行代码注释:它们的效果更加显著,有助于未来代码阅读者的阅读。

3.精简pull request

这是一项强大的技术,谷歌甚至就小型pullrequest的益处单独写了一篇文章(https://google.github.io/eng-practices/review/developer/small-cls.html)。以下是笔者最喜欢的小型pull request的特点:

  • 审查更彻底

  • 审查更快捷

  • 更易合并(频繁的合并能减少冲突)

  • 如果被拒绝,浪费的精力更少

以下办法能使小型pull request的编写更简单:

  • 将重构提取到单独的pull request中

  • 将大型功能分解(即使它们不是面向用户的)

  • 学一些git小窍门很有帮助,把git add --patch和git rebase --interactive当成朋友

  • 把长期运行的功能分支设置为pull request的目标,而非master的目标:

4.快速回应审查

处理审查注释通常比较费时,需要修复打字错误、添加遗漏的测试案例、对方法重命名等。如果你能快速完成,你的同伴就能花更少的时间来记忆与pull request相关的信息。

但这种方法的缺点是会增加上下文切换的工作量,替代方法是使用番茄工作法(Pomodoro technique):每工作25分钟穿插一次短暂的休息。它能让人更专注、更有成效、更健康,并减轻疲劳度,休息后的上下文切换也会进行得更加自然。负面的破坏性影响虽然没有消失,但是会大大降低。

5.给自己的pull request注释

为某些变化(例如删除和重构)添加解释性的代码注释是没有意义的,应当考虑为自己的pull request注释,给审查者提供更多的上下文。

6.在创建pull request前重定新master的基准

这样做有很多好处:

  • 测试可能在本地分支中会通过,但在应用的最近更新时会失败。

  • 能够使用最新添加的功能(例如新的工具类)。

  • 审查者如果没能找到近期的变化,就会感到困惑。

相比合并,笔者更喜欢重定基底,因为重定基底使得分支仅包含相关的提交。

7.不要修改经过审查的提交——要发送新的

要在单独的提交中处理审查注释,而不是修改或者除去更改。这样能够让审查者更容易核对在上次审查后发生的变化:

8.在实现功能之前讨论整体方法

这可以省下很多时间。在要处理更复杂的重构和功能之前,先与同事讨论一下方法。与其他的开发人员讨论,解释这项任务和你的想法,他们也许会表示赞成,也许会提出更好的方法。

很多时候笔者都面临着初步协调的缺失,好几天的工作成果白白浪费。想象一下你连续五天做一件事情,结果却听到"对不起,其实我们不需要……"想要把自己从失望中拯救出来,你得尽早获得反馈。

感谢各位的阅读,以上就是"怎么做一个完美的Pull Request"的内容了,经过本文的学习后,相信大家对怎么做一个完美的Pull Request这一问题有了更深刻的体会,具体使用情况还需要大家实践验证。这里是,小编将为大家推送更多相关知识点的文章,欢迎关注!

代码 注释 方法 上下 上下文 功能 笔者 信息 变化 工作 解释 分支 链接 阅读者 处理 学习 重构 人员 任务 内容 数据库的安全要保护哪些东西 数据库安全各自的含义是什么 生产安全数据库录入 数据库的安全性及管理 数据库安全策略包含哪些 海淀数据库安全审计系统 建立农村房屋安全信息数据库 易用的数据库客户端支持安全管理 连接数据库失败ssl安全错误 数据库的锁怎样保障安全 南京欣网互联网络科技有限公司 华服互联网科技怎么样 中国互联网科技工作委员会毛军 互联网科技官网 互联网科技有限公司经营范围 互联网金融与金融科技 互联网科技集团 善班互联网科技 科技创新互联网企业 齐家互联网科技有限公司 搜狐科技互联网 坤平互联网科技 中科明德北京互联网科技 智帮互联网科技公司最近动向 产业互联网科技服务公司 互联网营销推广黑科技 互联网科技数字货币 卡尔迅互联网科技有限公司 普陀区互联网教育科技管理办法 华人运通互联网科技公司 互联网科技工作委员会副主任毛军 润盈互联网科技 汽车互联网创新科技园 南山科技园互联网公司有哪些 厦门比较好的科技互联网公司 互联网科技公司实习生 杭州披云加互联网科技有限公司 东营紫格互联网科技 2021世界互联网领先科技成果发布 吉林省码上互联网科技电话
0