经过几个小时的工作，你终于到了那里。您的代码已经准备好了。是时候提交拉拉请求(PR)并让您的宝宝接受检查了。有要填充…的PR模板。乌夫，这太烦人了！请不要浪费我的时间在这些东西上，看看我的代码吧！
让我们实话实说：我们去过那里不止一次。模板填充不良的PRS，或者(甚至最糟糕的)没有模板和极其无用的描述的PRS。“加上这个”。“解决这个问题”。
但我们知道这不是发送代码的正确方式。在这篇文章中，我想指出提供一份令人惊叹的公关的重要性，包括完整而有用的描述，以及评审者提供反馈所需的所有信息。此处没有模板，也没有要遵循的规则。我的目标是激励你给你的公关一些爱。
你可能会想，为什么你要花时间精心制作一份充满爱的公关。原因很简单：你的作品，你的评论者，你应得的！
每一行代码、每一次提交、每一次测试都是一项独特的工作。它应该得到尽可能好的展示。在展示时不加注意地制作一些东西有什么意义呢？给你的工作一些爱，用别人也会欣赏的方式来展示它。
要访问美术馆的图像。你有机会与你正在观察并想买的杰作的作者快速交谈：阳光明媚的海滩上一幅令人惊叹的西红柿死画像。太有意义了！你问作者他是如何得到这样的灵感的，他回答说：“嗯，我拿了一些颜色，我气喘吁吁地说。”不是卖艺术品的最好方式，对吧？
你的公关也是一样的：如果你不花一些时间恰当地展示你的作品，你就不能假装别人欣赏你的作品。
回到美术馆的例子。你是评论家，应该对大家都在谈论的名著“快乐之地的悲伤西红柿”进行评论。你在美术馆四处寻找，你会发现艺术品还在包装里，上面贴着一个小标签，上面写着：“西红柿”。要审阅它，你需要打开包装，四处打听关于它的信息，询问作者关于颜色的选择，等等。听起来不太吸引人，对吧？
记住，你的评审者的时间和你的一样宝贵。此外，如果没有一些背景，也很难提供适当的审查。帮助你的评论者帮助你：用一个有意义的标题和对你所做工作的恰当描述来给你的公关带来一些爱。我们稍后再来关注这个…。
你花了几个小时(如果不是几天的话)来完成一项任务。几次提交、测试、失败和成功。你想提交一份公关而不表现出你在工作中投入的细心吗？而不解释你经过几次思考后做出的选择？
回到美术馆的例子。这一次，你是“快乐之地的悲伤番茄”的作者。当然，要想出一部如此复杂的杰作并不容易。你想让人们欣赏你的工作，了解你在这上面付出了多大的努力，你投入了多少热情。我想你不会把艺术品放在黑暗的角落里，没有镜框，就在灭火器上方，靠近女洗手间。你想把它放在尽可能好的灯光下，有一个令人惊叹的框架，放在画廊最重要的地方。
你想对你的公关做同样的事情。你值得你的评论者能够理解和欣赏你的作品！他们的评论会更好，这将帮助你提供更多的价值。就像我之前说的：帮助他们，帮助你。
我想现在我们都同意，我们的公关应该得到一些关爱。如何做到这一点呢？嗯，不需要很辛苦，只要注意细节就行了。
请将您的公关保持在尽可能小的范围内。我理解有时任务/功能需要大量工作，但如果可能，请将其分成较小且非常集中的公关。您可以更容易地专注于业务逻辑的特定部分，并且您的审阅者将提供更好的审查。当您不必查看20个文件时，理解逻辑和提供反馈要容易得多。
承诺是你公关的基石，他们也应该得到一些爱。提交时，请提供有关提交内容的有用信息。我不会在这个话题上花太多时间，因为你可以在互联网上找到很多有很好提示的文章。我喜欢Chris Beams在这篇不错的文章中描述的建议。
公关的标题是你的评审者看到的第一件事，可以提供很多有用的信息。这是一个特写吗？解药？一件简单的家务活？在标题中清楚地说明这一点，同时对公关关注的任务只字不提。
标题之后是描述。你如何组织它并不重要，它可以是一个项目符号列表，一个清单，一个非正式的描述，一个照片浪漫的…。重要的是你提供的信息。依我拙见，描述应理解为：
题目：你想通过这次公关达到什么目的？你是如何实现你的目标的？
动机：您为什么要提交这份公关？如果它与票证/任务相关，请提供指向它的链接。
突破性变化：这份公关是否引入了一些突破性变化？为什么？如果你的评论者知道这个公关可能会破坏一些东西，他们可能会给予额外的关注。
附加信息：有没有其他对审查者有用的信息？例如，对一段听起来可能很奇怪的代码做出特定决策背后的原因。
让我明确并重复一遍：格式并不重要，重要的是你在描述中提供的信息的质量。如果你能用3行文字提供高质量的信息，那就太好了！
你测试你的公关了吗？我想(希望)你已经习惯做这件事了。简要描述您做了什么类型的测试，如果合适的话，测试公关需要什么。我知道测试可能在文件列表中可见，但我认为您的评审者会很高兴有一个摘要。
此外，PR可能不仅仅是您可以显式测试的代码。假设您向repo中添加了一些脚本。您能做的最好的事情就是编写用来测试它的命令，然后复制和粘贴输出。这只是一个例子，我相信你可以找到其他的例子。
您的PR可能有依赖关系以及合并后应完成的其他任务。它可以是在此PR之前应该合并的另一个PR，或者应该在数据库中更新的值，或者应该清理的一些资源，因为合并PR之后不再需要。你应该总是清楚地说明你的公关的依赖关系。为什么？嗯，首先，这将是对你的一个很好的提醒！它也会对你的评审者有帮助，这将验证他们以及公关本身。
好了，伙计们，到此为止。我已经说过了，我不想提供一套做公关的规则。这些只是一些建议，希望能对您有所帮助。时间回到你的公关，给他们一些❤️！
由卢卡·弗洛里奥提供动力。计算机科学博士。对分布式系统充满热情。半堆栈显影剂。数据和ML爱好者。克拉夫·马加黑带。