怎么做一个完美的PullRequest

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

创新互联坚信：善待客户，将会成为终身客户。我们能坚持多年，是因为我们一直可值得信赖。我们从不忽悠初访客户，我们用心做好本职工作，不忘初心，方得始终。十多年网站建设经验创新互联是成都老牌网站营销服务商,为您提供成都网站设计、成都网站建设、网站设计、H5高端网站建设、网站制作、品牌网站建设、微信小程序服务,给众多知名企业提供过好品质的建站服务。

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这一问题有了更深刻的体会，具体使用情况还需要大家实践验证。这里是创新互联，小编将为大家推送更多相关知识点的文章，欢迎关注！