如果两次提交之间的等待时间过长，该怎么办？

我很调皮……太多的“牛仔编码”，还不够提交。现在，我在这里做出了巨大的贡献。是的，我应该一直坚持下去，但是现在为时已晚。

什么是更好的？

1. 做一个非常大的提交，列出我所做的所有更改
2. 尝试将其分解为可能无法编译的较小提交，因为文件具有多种修复，更改，其他方法名称等。
3. 尝试仅针对适当的提交对文件进行部分还原，然后放回新的更改。

注意：到目前为止，我是唯一从事此项目的程序员。至少在我们雇用更多程序员之前，唯一会查看所有提交评论的人就是我。

顺便说一句：我正在使用SVN和Subclipse。在进行任何这些更改之前，我确实创建了一个新分支。

更多信息：我首先问了一个与我如何进入这种情况有关的单独问题：如何为重写应用程序的粘合做准备

要回答这个问题，您必须问自己，将来如何使用这些提交的结果。最常见的原因是：

• 看看引入了什么版本的错误。
• 了解为什么存在某些代码行。
• 合并到另一个分支。
• 为了能够检出先前版本以对客户或测试人员在该版本中看到的问题进行故障排除。
• 能够包含或排除发行版中的某些部分。

假设您可以创建一个签入消息，该消息同样适用于每行更改的代码，则前两个原因也可以通过一次大签入得到解决。如果您是唯一的程序员，则较小的提交不会使您的合并更容易。如果您不打算仅对部分未提交的更改进行发布或测试，则后两个原因不适用。

进行小额提交还有其他原因，但这是因为您正处于更改中间，而时间已经过去。这些原因使得更容易排除错误或实验性更改，并且更容易与同事保持同步，而无需进行大量可怕的合并。

从我对您所描述的情况的理解来看，在这一点上拆分承诺似乎没有什么好处。

我认为无论您做什么，都尽量避免签入您知道不会编译的代码。

如果您认为您的第三个选择是可行的，那么只要您可以确保提交顺序不会创建无法编译的系统，那可能是一个不错的选择。否则，只做一个大的承诺。这很丑陋，但是很简单，快速，并且可以完成。往前走，多做点事情。

进行频繁，小而有意义的提交的最重要原因是帮助理解代码的历史。特别是，如果很难生成可理解的差异，则很难理解代码的变化方式。

选项1混淆了您所做的更改的历史记录，但否则不会造成任何问题。

选项2掩盖了您所做更改的历史，可能比选项1少了一些，但是如果他们假设或以其他方式认为提交是不同的，例如可能可以独立合并到其他分支中，则可能给您自己或其他人造成其他问题。除非有很强的实际原因，为什么它比选项1更受青睐，所以它并不理想。

选项3是最好的，其他条件都相同，但是，如您在其他地方所述，如果这样做需要“极长时间”的时间或会导致其他重大成本，则您必须权衡这些成本与预期的收益。创建更清洁的提交。

根据您提供的信息，我选择选项1。也许您应该设置提醒以提示您进行更改？

原型设计和重写

需要记住的另一个考虑因素，尤其是考虑到您是唯一的程序员，以及我怀疑您正在开发一个相对较新的代码库时，养成在习惯于在您更改代码时养成不同习惯的习惯可能是个好习惯正在对新代码进行原型设计，而不是维护或扩展现有代码。两者之间可能没有十分清晰的区分，但我认为这仍然是一个有用的区别。

在制作新代码的原型时，几乎可以肯定在分支中，但也可以在单独的项目中，只要要保存更改就提交。或者甚至完全可以在版本控制之外工作。相反，您可以专注于收集有关您正在考虑的各种假设或设计的可行性的证据。我经常使用其他工具（例如LINQPad而不是Visual Studio for C＃代码）编写小型原型。

验证特定的假设或设计后，请在您的主项目中（最好是在分支中）重写它，并进行有意义的小型提交，以最好地帮助他人（包括将来的您）了解更改的性质你在做。

尽管唯一合理的答案是永不折断行李箱，但有时是不可能的。例如，如果您提交过多，svn可能会中断提交（我不确定是选项还是功能）。在这种特殊情况下，只需分段检查即可。由于您是一个程序员，因此不会打扰任何人。

因此，我会选择选项1。如果不可能，则选择选项2。

选项3需要付出很多努力，但这根本不值得。

尝试将其分解为可能无法编译的较小提交，因为文件具有多种修复，更改，其他方法名称等。

当我发现自己处于类似情况时，我使用了以下技术：

1. 仅添加与特定功能相关的代码： git add --patch
2. 隐藏所有其他更改： git stash save --keep-index
3. 运行测试/尝试编译
4. 如果一切正常，请提交更改，否则请转到1

我对SVN不熟悉，所以我不知道这是否适用于您的特定情况，但是基础应该是相同的-隔离一小部分代码并分别进行测试。

选项4怎么样：在临时位置备份仓库的当前状态，将仓库恢复为原始状态，列出所做的所有更改（您仍然可以查看临时备份），然后手动重新实现（并编译）和测试！）作为单独的提交。

这应该更容易一些，因为您已经编写了代码，只是从临时备份中找出要复制和粘贴的部分。

当您干净地重新实施每个更改并因此确保提交是独立的，小型的且可编译的时，您可以删除临时备份，并且几乎所有内容（提交的时间/日期除外）都与之完全相同。如果您从一开始就正确地做，那将会是。

您是唯一的程序员。只需进行一次大规模检入，详细说明您所做的工作。

您是否可能回滚所做的“部分”操作？如果不是，则绝对继续执行选项1。

将代码检入版本控制系统有两个原因。当您是唯一的开发人员时，所有这些都围绕安全性展开-即，如果您搞砸了，机器死了或其他原因，您总是可以回到最后一个检查点。

稍后进入项目的程序员不太可能想要回滚到未编译的版本。因此，恕我直言，选项2是疯子。

选项3听起来像是在浪费时间，如果我是您的老板，并且看到您在浪费时间进行此操作，那么我将与您讨论一下您的时间是值得的。

要进行迭代：通过检入代码，可以在机器出现故障的情况下覆盖/节省您的屁股。在一个人的团队中，其他所有东西都是橱窗装饰。

我的规则是：未经认真的代码审查就不能签到。如果我对我自己的，我得检讨自己的代码，但它会进行审查。您似乎已经进行了许多其他人无法审查的代码更改，因此您无法自己进行审查（审查自己的代码更加困难，需要更多的纪律，因为您会自动做出错误的假设，认为自己的代码正确无误）。

每个人的牢不可破的规则是：切勿检入甚至无法构建的代码，并认真避免检入无效的代码。

解决方案：复制更改的代码，回到原始点。一次将一个更改合并到原始代码中，对其进行检查，测试并将其检入。使用您描述的编程方法，您一定会发现这种方式的严重错误。

这也是训练自己良好的编程习惯的好方法。

我想你太担心了。如果您是唯一的程序员，并且没有适用的规格表，那么您的工作完全取决于您。我认为没有人会因为做出较大的提交而惩罚您，因此您将遇到的唯一问题是技术问题，例如无法回滚提交中的单个文件更改。由于此时您仅由仓库控制，这也不是一个大问题。

实用主义和教条主义之间要划清界限。在团队中，您所做的并不是一个好主意，并且可能不应该重复进行，但是在您的情况下，我将提交大型提交。

问题不在于提交之间的长时间延迟，而在于您将代码保持在不可编译状态的时间过长。首先，您对“长期”的定义是什么？对于某些人来说，过渡状态5分钟太多了，但有些人甚至可以在几天之内完善其代码，而无需尝试运行编译器。

实际上，这并不重要-重要的是您失去了对代码的控制，您的代码变得不可管理。这是正常现象，这只意味着您有技术债务，现在该考虑重构了。所以你感到沮丧吗？您的代码无法编译，甚至没有单元测试？在这种情况下，您如何考虑重构？别担心。完成您的“牛仔编码”，然后开始清理它。理想情况下，尝试编写一些测试。你没有时间吗？好的，从小的改进开始。

某些更改不需要测试。更改变量名称以使其更适合，将重复的代码移到单独的函数中，依此类推...您将更好地了解代码。之后，您可以进行更大的更改。同样，如果可能，尝试编写测试。使代码易于管理。

之后，您将看到下一个更改不会花费您太多时间（无论它意味着什么）。