问极限编程日报提交

EN

每天？？如果你遵循这一策略，你应该比这更频繁地做出承诺。

我的想法是你很早就做出承诺。经常犯。经常同步。使提交量小且易于审查。冲突的发生是因为两个人在同一件事情上独立工作--当你在小的快速单位工作时，冲突的窗口变得小得多。剩下的冲突很小，而且很容易解决，因为每个人都有精神状态。(相对于过去6个月试图解决重大冲突的行业标准而言，这是不同的。)

缺点是你可能会被在公司里远离你工作的其他人击垮。此外，这也使得很难在可能或不想投入生产的分支上工作。许多人还认为这不是一种可扩展的策略--大型组织需要更复杂的实践。

我不同意这种批评。作为参考点，在Google提交之前，必须对所有更改进行同级检查。平均提交少于20行。提交直接发生在主分支上。有大量的单元测试和集成测试，在提交可以完成之前自动运行。(有了一个基础设施，就能以可接受的速度实现这一目标。)在谷歌，人们普遍认为，这些做法成功地扩展到了谷歌。然而，如果你拿出其中的任何一件，它就不会。

让每天(如果不是更频繁的话)提交的概念来自于连续积分的思想。CI的基本思想是，开发人员应该每天集成他们的更改几次，从而消除每个开发人员单独开发几个星期的历史规范，然后花费几个月的时间来集成他们所有的不同部分。大多数CI工具自动化构建代码更改和运行单元测试套件的过程，因此开发人员负担很小。

在此背景下，以下是对您问题的直接回答。

在回家前提交所有更改的好处是什么？

• 允许持续集成，这是一件好事。
• 更少的机会失去你的工作(如果使用储存库不在你的机器上)
• 如果你犯了一个错误，有一种简单的退步方法
• 您可以对其他开发人员进行更改。

不做在回家前提交所有更改的风险有多大？

• 你丢东西是因为硬盘坏了。
• 你失去了一些东西，因为你不小心删除或修改了错误的东西。
• 你不知道你有集成问题，直到它们真的很难解决。
• 您的代码不会在代码的其他部分的上下文中进行测试。

我认为日常提交(或更多)通常是一个很好的软件工程实践，不管使用什么方法。一些好处(不按特定顺序)

• 跟踪提交日志的时间成为“我周二做了什么”的一个很好的来源，在下个星期一的截止日期之前填写时间表。
• 如果您使用的是连续集成，那么签入将提示生成，从而验证您的代码(至少)没有破坏构建。(加上TDD和自动烟雾测试，您将获得更多的有效性)。
• 较小的批次以较小的每日批次工作，减少认知负荷。与其考虑你在当前的冲刺中所要做的一切，你可以专注于你今天正在做的事情。
• 把墨菲定律的影响降到最低--我让硬盘无缘无故地死了。把你的入住看作是备份。当你的本地硬件丢给你时，你愿意损失多少工作？

检查次数较少的一些缺点

• 合并文件的时间越长，保存的文件越多，您的更改就越有可能与其他开发人员需要合并的更改发生冲突。
• 如果没有登机，你的队友就看不到你在做什么。
• 相反，所有的好处，你失去了所有的好处，每天或更频繁地。