假设我正在为现有的C模块添加一些新功能（它可以是任何语言，但我们将使用C作为示例）。假设模块是二叉搜索树，我想添加三个新函数：preOrder（），postOrder（）和inOrder（），每个函数遍历树（以不同方式）并在每个节点上打印数据。我们还要说这些函数都依赖于一个新的依赖关系，称之为libprettyprint。
要将新依赖项添加到项目中，我必须在模块实现（.c文件）中添加#include行，并编辑一些Makefile规则。
我将把我的3个新函数中的每一个单独提交，这样它们就可以很容易地被接受，改变了上游拒绝的矿石。但至少有两种不同的方式来处理新的依赖：
方式一： 我会添加#include，更改makefile，然后编写我的第一个函数。然后我会承诺。然后我会编写其他两个函数并分别提交每个函数。 （共3次提交）
方式二： 我可以做一个非常小的提交w /只是#include和改变的Makefile，然后在三个单独的提交中提交三个函数。 （共4次提交）
方式对我来说似乎更糟糕，因为如果项目维护者/我的老板拒绝了第一次提交但接受了另外两次，他们会删除#include和编辑的Makefile，而另外两次提交将无法编译。方式二解决了这个问题。
我的问题是，在现实世界中，总是使用Way 2值得付出额外的努力吗？或者它只是使提交日志和浪费时间复杂化？
答案 0 :(得分：2)
从我的POV，你
我（个人）更喜欢使用并乐于从同事员工那里看到 The Zero Zero ：
逻辑任务完全包含在一个逻辑上完成的提交中。你添加了三个函数，这个添加要求：1）包括2）改变了makefile 3）添加了lib文件4）源代码中的新函数？！好的，将其设置为一次性提交，以便审核者只能查看一次提交，并且不会搜索“依赖”。
如果由于任何原因，您的提交不符合审核者的要求，您和他就会遵循最佳实施形式，并且由于更正了商定的实施，您还要进行最终提交。从修订版N“ - 减少对每个人的摩擦，从视角清晰可见的演变