我发现这种观点在这篇帖子上很常见，尤其是在一部分工程师中——即中层工程师……

我对我的团队的简单建议是： PR就像是发给你的团队和未来自己的邮件。 在这种背景下，更容易把握正确的语气并考虑范围/什么才是重要的。 --- > 对每种情况都严格应用DRY原则 我发誓，从开发者的角度来看，DRY原则对软件行业造成的破坏比它带来的好处还要多，因为它演变成了一根大棒，用来毫无顾忌地打击别人而不考虑具体情况。

那些自认为是高级程序员的中级程序员，正是我看到的那些说你刚才所说的话的人，即： * 是的，对生产代码进行TDD在理论上很好，但在我的情况下行不通。 * 是的，简短的PR在理论上很好，但在我的情况下行不通。 在每种情况下，据我所见，这都意味着“它其实行得通，只是我不知道怎么做”。 当我对“如果你认为它在你的案例中行不通，来问我，我会向你展示”时，他们往往退缩，最后我还是得到了一个巨大的PR。 实际上，我认为我从未见过一个长PR不会从战略性地拆分中受益，但每天我都会看到另一个本应被拆分的PR。

谢谢，更多人需要读这篇文章。软件行业似乎充满了这些奇怪的排他性结构，只会阻碍发展。 关注客户成果，保持主分支整洁。

>在PR中，没有人会一个一个地阅读中间的提交信息，这是肯定的。 >不要浪费时间写没人看的东西。 在我继续写这些信息的时候，我也想过这个问题。我认为我可以为自己辩护，说它们主要是给我自己看的。我可以具体描述一下我试图通过一次推送来完成的几个事项。这让我可以反思我是否在提交之间等得太久，或者我的想法是否太分散，应该分成两个不同的分支，每个分支都有自己的PR。然后还有在较慢的项目中，某个事项被降级，我几周甚至几个月后又回来处理的情况。这些信息帮助我重新跟上进度。 因此，我认为花20秒左右的时间写出1到2句话是值得的，即使最终审查PR的人永远不会查看。我也不介意在单个提交中加入“同上”或“修复了问题”之类的词语，当一个提交真的...…

>“在PR中，没有人会一个一个地阅读中间的提交信息” 我会清理我的提交历史，使中间的提交信息有意义。在PR中没有人会阅读这些信息，但当我六个月后运行git blame来查找一个错误时，我希望提交信息能告诉我一些东西，而不是“去吃午饭了”。 >对每种情况都严格应用DRY原则，或者强迫别人使用TDD来开发基本的应用程序 当然，严格地做某事或强迫别人做某事是不好的，但根据我的经验，复制粘贴代码、方法过长以及缺乏良好的测试是更常见的问题。 你可能在你自己的情况下完全正确，但一般来说，如果资深开发人员抱怨你的代码很粗糙且缺乏测试，也许他们并不是在吹毛求疵。

>在PR中，没有人会一个一个地阅读中间的提交信息，这是肯定的。 我确实会！我发现这是当作者花时间以这种方式组织代码时，审查代码最简单的方法。我很幸运能和一些很棒的人一起工作。

> 没有人会一个一个地阅读PR中的中间提交信息，这是肯定的。我曾经在一个团队工作，团队领导坚持这一点，并开始撰写类似“如果你读到了这条信息，我会给你5美元”的信息。我从来没有给任何人一美元。不要浪费时间写没人看的东西。 我却会。尤其是当作者很专业的时候。 不过，从经验上看，你说得对，大多数人确实不会看。 然而，我认为改变文化而不是抛弃这种做法会是更好的回应。 阅读和审查清晰的提交历史真的要好得多。我认为真正让提交历史变得清晰（而不是草率地做小的提交）会迫使作者更仔细地审查它。

提交信息你搞错了重点。这更像是提交的最终测试。如果你不能轻松地说明你做了什么以及为什么这么做，那么你需要重新考虑你的更改。