在代码库的不同部分上工作时修复错误

这至少发生在我身上一次。我在代码库的某些部分上工作，而在不同部分中发现了一个小错误，该错误使我无法完成当前正在尝试做的事情。修复该错误可能就像更改单个语句一样简单。

在那种情况下你会做什么？

1. 修复错误并将其与您当前的工作一起提交
2. 将当前工作保存到其他位置，在单独的提交中修复错误，然后继续工作[1]
3. 继续您应该做的事情，提交代码（即使代码已完成） 破坏构建 无法通过某些测试），然后修复错误（和 构建 使测试通过）在单独的提交中

[1]实际上，这意味着：将原始存储库克隆到其他位置，修复错误，提交/推送更改，将提交拖到您正在使用的存储库中，合并更改，然后继续工作。

编辑：我改变了第三，以反映我的真正意思。

我已经完成了1和2，最后，我想我更喜欢＃2。它为错误修复提供了更多可见性，这对于质量检查/发行说明/其他开发人员而言可能很重要。

我还遇到了这样一种情况，我认为实际上不是一个错误（不是说这里就是这种情况），并且在单独的提交中“修复”该错误允许另一个开发人员与我联系并解释什么是错误而不是“修复”，只是在我的正常值机中迷路了。

我通常会排名第二。它使存储库更清洁，并使日志更易于理解。当与我一起工作的其他开发人员在同一提交中提交15个不同的错误修复，功能和重构时，我讨厌它。

另外，根据您的团队对缺陷进行跟踪的方式，您可能需要搜索缺陷回购，以确保如果要修复的缺陷在其中，请将该项目标记为完成。或者，您可能需要创建一个新项目并将其标记为完成，以便缺陷系统和代码存储库匹配。

我做＃2。使用git之类的工具可以轻松地将其拆分为多个提交。如果您不能说服您的团队改用更现代的工具，则git-svn将为您提供解决此问题所用的一部分。这篇博客文章很好地概述了您要解决的工作流程：关于Git的事情

我选择未编写的选项（4）：将您的项目划分为高度专业的程序集/库，以便无关的错误始终位于版本控制树中的其他位置。

抱歉，以上说法听起来很抱歉，但我是真诚的。每当我看到一个包含一百种形式和名称空间的相互独立的整体项目时，我都会感到畏缩。我曾经经常面对同样的困境，想知道我是否以及如何打破涉及不同职能领域的承诺。直到很久以后，我才意识到在一个可提交的项目中拥有所有这些不同的功能区域本身就是一个主要的设计缺陷。

在使用特定功能时，我仍然经常发现完全不相关的错误。我可能正在使用UI，并在某些业务逻辑中发现了一个错误，因此必须对其进行修复才能继续。区别在于业务逻辑是始终与UI位于不同的程序集/项目中，因此我要做的就是对BL进行非常小的更改，然后进行一次非常小的提交，然后继续工作。

拥有一个真正优秀的项目组织不仅使它成为可能，而且非常容易处理这些问题，而无需掩埋更改，破坏构建或陷入恼人的分支/合并中（即使您使用的是DVCS，也并非完全如此）无痛）。

如果您缺少此选项-即您是一个初级开发人员，在项目组织中没有发言权-那么我将简单地选择＃1并在日志中记录适当的注释，以便其他人知道您为什么这样做。如果进行了重大更改，则还应在问题跟踪系统中提交错误报告，以查看已修复的内容以及原因。

我尝试做＃2。如果确实是一个单独的问题，则很有可能该文件所在的文件与您正在处理的文件不同。您应该能够将文件作为单独的提交检入，即使该文件是在您正在使用的同一存储库中进行的。出于上述所有原因，使提交尽可能独立是有意义的，以便在错误的情况下跟踪和还原更改。

我通常只修复错误，然后继续进行我的工作。是时候提交了，假设错误修复在一个单独的文件中，我会同时执行两次提交-第一个是仅包含错误修复的部分提交，第二个是其他所有提交。

简短答案：＃2。您确实希望在版本历史记录中将该错误修正（在您的跟踪器中注明！）标记为单独的实体。

更长的答案：

• 偶然发现错误
• 编写一个测试或更能证明这个错误
• 通过测试
• 提交更改及其测试（git add --interactive或darcs record -i您的VCS）（*）
• 回到我在做什么。

（*）在CVS中（不是，实际上），有时我会检出一棵干净的树以及我正在使用的副本。然后，我使用合并（在我的情况下为winmerge）将错误修正仅拉入干净的树中，以便我可以分别提交。（另一个选项是重命名更改的文件，cvs update并合并。提交更改后，请删除文件，然后将移动的文件重命名为原始名称。）

不过要注意的是，我通常只会发现与我正在处理的内容或与词汇紧密相关的错误。如果人们在代码库的无关部分中发现错误是正常的，那我会感到惊讶-为什么您在修复错误时阅读无关的代码？（是的，这与Aaronnaught所说的完全相反！）

我修复了该错误，并进行了单独的提交，每个修订/功能都有一个。

大多数时候，更改不在同一文件中，因此很容易将提交分开。如果更改在同一个文件中，则我使用TortoiseHg（Mercurial GUI前端）来精确选择要提交的差异（我认为可以在命令行上使用Record扩展名进行此操作），但这不太方便）。

某些人在处理功能时会使用Mercurial队列来隔离次要修复程序。次要修补程序堆叠在MQ中，并且在完成并提交功能后，还将提交队列的内容（队列中每个条目的一个变更集）。

我通常会做＃2。将我当前的工作保存到其他地方：通常可以通过创建补丁来正常工作。另外，某些IDE（IntelliJ）允许搁置更改，这恰好是：将当前工作保存到其他位置。

我的工作取决于该错误是否确实存在于其他部分。如果是这样，则签入与我所做的一半更改无关。我进行更改，构建不同的部分，以确保我没有犯一些琐碎的错误，对其进行测试（也许通过执行阻止我执行的任何操作），并在进行解释时进行检查。通常，我会为此做一个工作项目，然后在签入/解决后，将WI分配给测试人员。然后，我回到正在做的事情。

如果所有文件都被我修改了一半，我将无法独立构建和测试该部分。在这种情况下，我会为其另做一个WI，当我签入更改时，我会使用相同的签入方法来解决这两个WI，这通常违反了我的原则，但在这种情况下适用性很好。

在这两种情况下，该错误修复程序最终都由我进行了测试，并通过某种方式进行了检查，以便人们理解为什么我那天随机更改了该代码，并向其他人分配了WI以确认它现在是否正确。

我们做＃1。＃2听起来不错，但我不能说＃2可以解决的＃1问题。

对我公司来说，另一个因素是我们构建Web应用程序，而我们的测试几乎完全通过Web界面进行-大致上，人们称之为功能测试而不是单元测试。在签入之前，我们已经通过了所有测试。将提交拆分为较小的位将意味着每个位运行一次测试，这将花费更多的时间。我希望有一个更快的测试套件，它可以让我们做更小的提交，但是我们没有。