如果我在代码中遇到了非关键性的拼写错误（例如，print（error）语句中出现了错误的撇号），是否值得做出承诺来解决该错误，还是应该将其单独放置？

具体来说，我很好奇如何权衡提交日志的解决方案与解决这些非关键错别字的价值。我倾向于解决它们。我是在学脚吗？

我个人的感觉是，即使只是小小的改进，提高质量值得给附加的提交日志条目带来些许麻烦。毕竟，当您考虑破窗效果时，小的改进就非常重要。

您可能需要在TRIVIAL:其前面加上标签，或者如果您的VCS支持，则将其标记为琐碎的。

您不是在做书呆子，最好单独解决它们。更改越原子化就越好-您不希望将崩溃的错误修复与500个注释/键入更改混在一起。

在一般情况下：是

它总是值得提高可维护性的软件。

就去吧。

如果您即将发布版本...

... 如果您不是团队负责人，请与他/她核对。

关于提交日志的内容...

我同意其他人的看法，如果仅是解决一个单独的错字，您至少应该写一些东西使其与“功能”相关的提交区分开。

一种常见的做法是在问题跟踪器中执行一些永无止境的任务，以跟踪永无止境的变化。例如，有以下任务的情况并不少见：

• 大型自动化无害清理（空白扫掠），
• 语法和拼写错误
• 建立系统修改，
• 等等...

请注意，当人们懒于创建正确记录的故障单时，这些ID不会用作几乎所有物品的一次性任务ID。尤其是如果您拒绝未链接到ID的提交（这是一件好事，但是像这样的大型任务对于懒惰的开发人员将更具吸引力）。

错别字应作为提交添加。修复拼写错误的单词或语法错误将提高代码的可读性。

使用诸如“ Fixed typo”或“ file.c中的Fixed typo”之类的提交消息将帮助您将这些提交与其他主要代码提交区分开。

是的，您绝对应该这样做，尤其是在项目初期。

为什么？两点：

1. 您可能不知道打字错误是否“很关键”，直到为时已晚。有些修复程序可能无法修复，因为每个人都认为这不会有什么大不了的。直到它是。

2. 与进行数百行代码/函数调用之后，尽早并有意识地修复错字要容易得多。同样，临时黑客可能会很快变得半永久。这就是为什么我必须处理同时具有“ CollapseAll”和“ ColapseAll”方法的对象的原因。

对于最终用户可能看到的语法错误，那么是的，绝对值得进行提交，因为用户或QA很有可能会出现并报告错误，并且需要对其进行跟踪。如果已解决，则可以加快解决问题的时间。

但是，如果这是围绕代码的注释中的语法错误，我将不做任何事情，除非它是对实际代码的更改的一部分，在这种情况下，您将更新代码的文档。

如果您担心弄乱提交日志，那么您在做其他错误。:-)频繁提交是一件好事！我一直犯错字。尽快在代码库中获取它们，并加快开发周期！

我投赞成票。签入他们。我在一家讨厌人们签入东西的公司工作。我的意思几乎是任何东西。代码审查非常广泛，因此，如果签入的更改只是修正了错字，您就会抱怨。您可以想象代码的状态。实际上，代码并不可怕，但是它像糖水一样渗出，而不是像酒一样流淌。

您的变更管理流程是否允许？

在我的环境中，我所做的每次提交都必须与业务用户或强制性的系统级更改所请求的更改请求联系在一起，并完成相应的最终用户测试过程。像您描述的简单错字可能不会被记录为两者中的任何一个（我发现我的一个应用中存在错字和语法错误，已经存在了4年之久，没有人注意到），所以如果/当审核员来时打电话给我很难解释自己。

我将保存您正在描述的更改（实际上，实际上有一个-方法名拼写错误，我刚刚发现了它），当我有一个“实际”更改时需要并在日志中添加“固定各种错别字”。

使用DVCS编辑历史

如果您担心干净的提交历史记录，请考虑在功能分支中进行主要工作。如果碰巧使用分布式VCS，则可以在将提交历史记录推送到主分支之前轻松地对其进行编辑。如果您使用的是SVN，请尝试使用Git-它可以与Subversion 进行双向交互，并且您还可以在实际提交Subversion之前编辑历史记录。

否则要保持常识

如果您不希望或无法编辑提交历史记录，则没有功能上的理由对不影响自动测试或编译的次要错字进行早期提交或原子提交。在我看来，在这种情况下，保持提交历史记录整洁比真正执行原子提交更为重要。将一两个错字更正与“常规”修改混合在一起不会损害任何潜在的审核过程。但是，您可能想将几个琐碎的更正归为一个提交，也许是在较大的编码会话之后“清理”时。

注意，功能性错误仍应在原子提交中尽快提交。

此处答案的一般语调似乎建议即使对于较小的错别字也应采取“快速完成一切”的策略。我倾向于不同意并欢迎讨论。