问如何在我提出的请求的数量和大小上找到一个很好的平衡？

EN

(1.)我怎么才能找到合适的平衡..。

那是你和你的团队之间的事。

听起来你的团队不重视公关，或者至少不是你的。三天太长了。希望一只大拇指就足以合并公关在你的回购。

我认为公关邀请是我应该迅速处理的一项高度优先的任务，因为它阻碍了一位同事。也就是说，如果我注意到公关是“长的”，我会把它推迟到完成我正在做的工作，并在一天结束或早上的第一件事上与它接触。短PRs，我会尽快理解和批准。我批准了很多单行PRs。让您的评审人员轻松地批准您发送给他们的内容。

(2.)我是否应该在前一个(经常相关的)请求被合并之前提出一个新的拉请求？

不是的。

在提交了PR-A之后，该代码现在为审阅者提供了快照。开始在分支B上工作，它是从A中克隆出来的，也许在某个时候，我们预计所有相关分支都会被检查和合并，这样您的许多特性分支都将直接从develop中克隆出来。

提交PR-A时写着“我愿意把A合并成不变的发展”，同样对于PR-B来说也是如此。麻烦的是，B是基于尚未开发的未经批准的编辑，而B是关于A特性的额外工作。基于评审，您可能希望在合并之前编辑A，这将影响B。不要在这些细节上浪费审阅者的时间。在提交B之前，等待A上的灰尘清除。如果需要，切换到一个可以并行取得进展的无关特性上。提交后编辑分支是很好的，特别是在回应评论意见时。但是，不要用打开的PRs上的编辑流来负担您的审阅者。如果您注意到发生了这种情况，这表明代码在提交时还没有准备好。

(3.)我应该使用不同的方法来进行代码评审吗？

是。

如果您不确定有什么非常具体的东西，提交并推动它，然后删除一个同事相关的github URL和问题。它应该提到提交哈希和行号，例如https://github.com/freebsd/freebsd-src/blob/78599c32/usr.bin/grep/grep.c#L65

你可能会建议“我要删除这一行--你知道有什么东西缺乏单元测试，可能会崩溃吗？”

这样做的目的是在公关之前制定出风险更高的版本，这样批准最终的公关就“容易”了。这类似于在预定的时间之前处理会议的事务，这样与会者就可以有效地橡皮图章，重新开始他们已经同意的工作。

(4.)我应该设定一个不同的目标/找到一种不同的方法来衡量我的生产力吗？

什么？！？

你误解了公关过程的意义。生产力是以交付给业务的价值来衡量的，而不是通过提交、推送、SLOC、PRs或其他业务不关心的技术细节来衡量的。与您的团队领导或管理链中的其他人员进行交谈，以澄清对业务有什么重要意义。

理想情况下，一个PR应该引用一个特性，一个特性应该有一个PR (每个受影响的存储库)。这样，审阅者就可以很好地了解为实现该特性所做的所有更改。审查人员需要这样的概述，以便他们能够判断在实现该特性时是否遗漏了什么。

让每个PR只引用一个功能是确保PR不会增长太大的一个好方法(除非功能本身已经非常大)。

如果您喜欢对您的代码进行早期反馈，您可以同意您的团队的意见，您将在希望收到反馈时立即打开一个PR，并且在您处理该功能时将不断更新该PR。然后，您还需要与团队就如何发出信号表示您认为您已经完成了实现和“最终评审”可以执行的问题达成一致。

1. 我应该在以前的(通常是相关的)请求被合并之前提出一个新的拉请求吗，就像我一直在做的那样？

理想情况下，如果您在等待对前一个功能的PR的批准时开始使用一个新特性，那么您应该选择一个不依赖于前面的功能已经完成的特性。然后你就可以从主要的开发分支中分离出来，而不用担心公开的公关。

如果您需要从依赖特性开始，那么使用打开的PR从分支中分离出来。在创建下一个PR时，目标要么是您刚开始的分支，要么是主要的开发分支，在此基础上将提供最有用的回顾经验。

1. 我应该设定一个不同的目标/找到一种不同的方法来衡量我的生产力吗？

IMHO，你绝对应该找到一种不同的方法来衡量生产力。减贫战略是一种质量保证工具，而不是衡量生产力的标准.

“我希望尽早获得对代码更改的反馈，避免陷入阅读/理解现有代码的泥潭”

听起来你在提高PRs，你知道你还没有准备好被合并作为一种请求帮助你工作的方式。

“我已经发现PRs开始堆积”

听起来你的队友不想帮你做你的工作。也许他们觉得你应该把更多的工作放在你的PRs上，然后再让他们复习。

理想情况下，PRs没有任何问题，而PR只是对您遵循规则的一次人工检查。编写和通过测试，与工作项相关联等。

显然，关于最好的方法做PRs还有很多要说的，但是你所要求的方式让它听起来像是一个#theWorkplace问题，而不是一个#软件工程问题。