我们有一个概念，即向主请求请求中的所有代码都应准备好生产。这是有道理的，我认为这是一个公正的声明。
这里的想法是，一旦创建了PR，就说明您已经将它放到了主控器中，但是希望某些审稿人仅与您“同意”，并发现您碰巧遇到的任何问题。
由于我们只是人，所以我们会犯错，并希望其他审阅者可以找到单元测试找不到的项目-拼写错误，不正确的javadocs等。
但是，“拉取请求”是我们应该向开发人员提供某种程度的帮助/培训的地方，如果需要，应该达到什么程度？
每次您推送新更改时，审阅者都必须重新审阅您的更改，这要花费他们的开发时间，并导致重新审阅更改。
因此，在请求请求中应该允许接受多少培训？我的一部分感到，这从大三到大四。但是，我也觉得这里不应该是发现大量问题的地方-即使对于初中生也是如此。
是否还有其他人在努力使开发人员实现“我的拉取请求应该准备好生产”的目标？
Answers:
否。拉取请求不是培训的地方。您的团队有正确的想法。PR的意思是“我认为这是一件好事。万一我错过了什么，我能得到第二眼吗？毕竟我是人类。” 而且我怀疑那正是您的徒弟正在做的事情。他们诚实地认为这是一件好事。
这是一个极端的想法（双关语意）。与让您胃灼热的学徒结对计划。作为更高级的团队成员，将其提升并提高生产力是您的工作。
如果违反团队核心设计原则或标准的代码进入拉取请求阶段，那么绝对应该在此处解决。代码审查可以成为传达团队标准和设计实践的一种好方法。
但这是最好的地方吗？以下是一些我为什么不说的原因：
结对编程和设计审查是获得大规模反馈的首选场所。
就是说，让代码通过更加糟糕，因为担心在代码审查过程中解决它是“错误的”，并且在某些情况下（例如，远程团队），这是您最好的选择。在这种情况下，请解决代码审查中的问题，并解决到目前为止开发过程中的问题。
虽然在拉取请求期间发现问题可能不是理想的方法，但肯定比在测试或生产问题中更好。
我想说的更多，因为拉取请求不应该是您培训人员的唯一场所。此外，初级开发人员并不是唯一需要在pull请求中接受一些培训的开发人员。承包商，开源贡献者，不熟悉本地代码或标准的其他部门的开发人员，甚至是资深的程序员，在自满时也需要偶尔提醒。
暂时保持拉取请求的成本很少。尽可能多地给与您尽可能多的反馈，然后不理会它，直到作者再次通知您他们认为可以合并为止。无论是完全准备就绪还是需要大量工作，拉动请求都是用于传达建议的代码更改的出色中央工具。
有些拉动要求的审核结果只是橡皮图章，有些是向团队外部提交的要求，可能要花一个月的时间。第一种在您可以得到时是不错的，但这并不意味着第二种没有价值。试图让人们一直提交完美的请求请求只会令每个人感到沮丧。
我一直认为，优秀领导者的标志之一就是可以在每个开发周期中根据需要提供额外的培训。对我来说，这意味着我不仅要编写自己的代码或审查代码，还要与更多的初级开发人员坐在一起，与他们配对编程，以帮助他们避免遇到我踩到的地雷。
主要是，我没有幻想我们的主要目标是教育-并非如此。无论您是高级，领导还是初级开发人员，目标都不是您的理想。目标始终是向客户交付质量代码。最好按时，按预算做他们想做的事。但是，我确实意识到我不可能自己完成所有工作，因此我有责任帮助所有人帮助团队成功。这意味着当培训机会出现在自然界中时，就应予以承认。
因此，对于您的询问是否是初级培训的场所的问题，我不得不说，在这些期间出现可教导的时刻并不少见。嘿，您将不得不处理您的第一次合并冲突，让我们在审查后再进行讨论。哦，瞧，您的DAO没有包含任何单元测试，我们将把您的评论推迟到有机会介绍这些新方法之前。您为什么认为在此财务计算中使用双原语比使用BigDecimals更好？是的，这并不少见。
因此，尽管我会说这肯定会发生，但是显然这不是请求请求的主要目标。我也不认为没有期望Pull请求中的代码已经准备就绪。通常不是。
如果您在gitflow样式分支策略中使用feature和release分支，那么您的拉取请求将更像是release候选。还没准备好生产，而是更接近它。您知道您的代码可以编译（正确），并且您有足够的测试能力可以断言它符合用户故事的目标。而且，由于您已经在开发环境中运行了多个集成测试，因此，如果要求您演示您的更改，那么您将准备好进行演示，在进行PR审查时将进行更改。
最终，我认为我们应该在PR审查期间提供帮助，但这种帮助并不围绕通用编码。相反，它与准备建议的代码以使其包含在生产质量代码的工作库中有关。PR为开发人员提供了一个机会，以证明他们对PR中包含的每项更改都有正当理由并有扎实的把握。即便如此，即使在我们通过单元测试，演示和大量问题进行权衡之后，也仍然无法预期所提议的更改已准备就绪可以投入生产。
毕竟，代码已关闭。但是随后，我们让质量检查小组对其进行酷刑。
我要感谢每个人所做的贡献，并帮助我了解人们对于该主题的看法。
这是我给出反馈后的答案，现在基于收到的答案和评论我的理解。谢谢大家。
摘要
您能否在技术团队方面更多地谈谈您的公司文化？如果您在开发人员想要合并到主线中时为代码准备就绪而苦苦挣扎，那么您真正对开发人员说的是什么？您是在告诉他们，当他们的工作“完成”时，还行吗？可以中断系统吗？如果他们增加了技术债务，那么如果他们可以证明其合理性并知道自己在做什么，并表明他们可以回来并稍后进行重构，那也许就可以了。但是，如果他们不知道为什么要做危险的事情，那么您要让它通过几次？
如果您有初级开发人员，那么他们的前几个请求请求显然会出现问题。最终，他们应该掌握这些技巧。如果发现他们仍然遇到问题，那么您可能正在为其分配尚未准备好的工作？
或者，也许您需要雇用一名替代的初级员工并解雇尚未解决的初级员工？
你知道我所看到的吗？由于裙带关系，没有能力的开发人员会继续在公司工作多年。因此，他们的拉取请求当然需要多次审核。用精益的话来说，他们是“浪费”-拖累了团队，拖累了利润。
因此，您必须自己决定：大三学生显示能力需要多少次拉动请求，您是否有勇气让不参加的人放手？