在这里，你滚动你的饲料，你发现另一个金的。哦，天哪，它华丽，甚至难以置信。它的完美之美…拉请求中的第一个提交只是文档更改…我说的是，但是我们讨论的是面向用户的文档和支持指南…屏幕截图的占位符也是。然后有一个评论，上面有一个需要拍摄和更新的截图的待办事项列表。所有的复选标记都打了勾当然。那个第二次提交，这是所有描述新特性应该做什么的测试用例……并且提交的CI报告有测试失败……自然，因为这是测试的真正含义首先，是第三次承诺，有了简单的提交消息"Implements ELENDUR-2436"…好吧，谁会怀疑它，提交有光荣的绿色复选标记，逆转了第二个测试用例引入的红色X承诺。并且最后，第四次提交将占位符屏幕截图替换为真实的交易……之后当然是评论"好吧，我想这已经准备好了，现在可以回顾了"。你向右滑动到diff视图，欣赏它的美丽，没有杂散的空白更改，只需要触摸导入，doc对所有新方法的评论……引入的方法、字段和变量的名称读起来很有趣，你的眼睛会很高兴，然后你输入：heart:在评论中点击approve，你怎么能不呢！现在代码审查已经足够了，是时候做一些编码了"你对自己说……然后你开始为ELENDUR-2756工作了。你把你的更改推到GitHub上，打开create pull request屏幕……然后是沮丧命中。你的拉请求是一团糟，20次提交，diff屏幕上有很多噪音…你开始通读pull峎u请求_模板.md检查表…好吧，我得写一些测试…"该死的文档，我讨厌写那些"…最后你明白了。"我永远不会像Kim那样成为一个优秀的开发人员。"你试着先写测试，但是你最终不得不重构它们……Kim只是凭空提炼出完美成形的测试，直到特性出现，所有测试都失败了着陆。让甚至还没有开始文档优先开发…是的，听起来很不错，文档准确地描述了这个功能是什么以及它应该如何工作……但是这显然是一项远远超出你的能力的技能能力。嗯，我在这里告诉你："不要对自己这么苛刻！"所有那些拉请求的影响者都作弊。你不知道他们在实现这个特性上做了多少尝试，也许甚至有几百个左右的小调整。当我们审视自己的发展时，我们会看到我们在努力使某件事发挥作用的过程中所做的成百上千的改变。就像在Instagram上，它只向你展示他们决定发布的照片，而不是数百张被删除的照片，直到它们看起来很像对。照片值得称赞的是：georgedolgikhit并没有就此止步，一旦他们有了工作，他们就可以使用IDE重构工具来使更改看起来更好。将变量从i、j、k重命名为更有意义的值。提取函数并给出反映其功能的名称。写更多的测试。写文件。这些是Instagram针对拉取请求的过滤器影响者。以及现在是大公开赛了秘密：他们都是使用git rebase修改他们的请求，并设置一个引人注目的阶段故事.gitrebase是用于拉的Photoshop请求。一次你有一个完美的故事，然后你只推第一个提交并创建拉请求。然后，您可以一次推送提交，等待CI服务器开始生成更改。这就是卡戴珊的代码创造了他们美丽的吸引力请求。所以不要因为你的拉取请求在第一次尝试时看起来并不完美，也不要觉得你必须让你的请求看起来那么好不是。但是，在你推动之前，把你的改变整理好一点也没有坏处…因为它会帮你改变审查过了。所有人可以使用IDE重构工具的过滤器使请求看起来更好，而一个非常难看的请求可以从一些git rebase修饰中获益…只是不要根据一张图片（从一千张被删除的图片中）来判断自己，空气刷和精心上演的Instagram完美生活观。