将编码进度拆分为有意义的提交而无需太多开销

当处理修订或功能时，有时我会偶然发现其他细微的问题，这些问题可以在几秒钟内即时得到改善。当我立即执行它们，然后提交完成的功能/修复程序时，提交包含不止一件事。例如"add feature X and code clean up"或"fix bug X and improved logging"。最好将其分为两个提交。万一这两个更改发生在同一个文件中，我不能简单地添加一个文件，提交，添加另一个文件然后再次提交。因此，我看到以下三个选项：

1. 在处理某些事物时故意忽略无关的事物。

2. 复制具有两个更改的文件，将其还原，包括一个更改，提交，包括另一个更改，然后再次提交。

3. 不要更改无关紧要的小东西，而是将它们添加到待办事项列表中，然后再做。

我不太喜欢这三个选项，原因如下：

1. 如果不能解决小问题，则代码质量可能会受到影响。如果我有意识地错过了一次不费吹灰之力就可以改善的机会，那我就会感到难过。

2. 这会增加人工工作，并且容易出错。

3. 这对于不太小的待办事项很好，但是将一个微小的项目添加到待办事项列表中并稍后再访问通常比立即修复要花费更长的时间。

您如何处理这种情况？

我认为您在编程时必须非常务实。即使有可能制定出完美的方案，工作流程或实施方案，有时您也只需要完成工作即可。这是我的工作：

我使用git的能力来尽可能地暂存/提交单个块和行，以分隔无关的更改，尽管如果分隔未正确完成，有时这可能会带来暂时的问题。由于更改将是相邻的，因此除非您有测试CI管道中每个单独更改的策略，否则通常这不是一个大问题。

当无关的更改太大时，我会将其放在待办事项列表中，通常在紧随其后的同时立即记入我的脑海。有时我可能需要一两天的时间才能恢复工作，这取决于我当前的任务和思路。如果我还没有好的解决方案，有时我会简单地将TODO：放在令人讨厌的代码旁边。

碰巧，分离事物是不切实际的，我将与原始工作一起进行细微的调整。

当我选择要走的路线时，变更的大小通常是决定因素，但是最后，我宁愿忽略工作流程规则，也不愿留下任何气味。

我的编辑器有一个插件，使暂存文件的各个部分变得非常容易。我想象其他程序员编辑器可能也有类似的插件，尽管您始终可以使用手动方式进行操作git add --patch | -p。然后，我使用git stash保存其他更改，以隔离测试我的小型提交。然后，在我提交之后，我只是做一个，git stash pop然后从我停下来的地方继续。正是这些功能的目的所在。

诀窍是不要进行更改，除非您准备付出应有的努力。

我倾向于做的是添加到待办事项列表中（有时通过在代码中添加注释，有时是在故障单上的注释中，有时通过在单独的分支中更新代码，知道最终会合并到修订中）。如果没有汇总次要质量问题的bug票证，我专门为此提出一个，因此我和其他所有人都可以知道分支合并后这些代码更改的原因是什么。我从来不会只是为了乐趣而进行更改，所有内容都具有可追溯性，因此当代码更改时，我的同事不会感到太惊讶。

简而言之-是的，在编码时忽略它们。如果要添加功能，无论大小多么小，都不要试图添加2个功能。如果有人决定还原您的分支（例如，因为不再需要您的功能），那么您还将丢失所有的小型错误修正。同样，您也不想在某些正常工作的关键代码中做一个小的“修正”。

我TODO经常使用的一个选项是添加注释，然后通过git add --patch选择文件的相关部分来进行频繁的“部分”提交。然后用于git rebase --interactive重新排序部分提交并将其合并到最终功能和修订提交中，然后再推送它们。

这样可以使您的主要提交保持整洁，并且仍然可以让您修复立即发现的其他问题。

git rebase在这种情况下，a没什么问题，因为您只重写本地提交。

另一个选择是“隐藏”您当前的更改。工作流程如下所示：

1. 开始进行与功能A相关的更改
2. 发现错误B并决定立即修复
3. 从仓库中的命令行执行git stash （之后，代码将返回到开始使用Feature A之前的状态）
4. 此时，您尚未提交的功能A更改已存储在“存储区”中
5. 进行必要的代码更改以修复Bug B并再次提交到存储库中
6. 从命令行运行 git stash pop
7. 现在，您对功能A的未提交的更改会从存储库中弹出，并与错误B的（已提交）修复一起还原到您的正在进行的代码中

分别暂存（并提交）与错误修复相关的更改。在Git Extensions中，这非常容易做到。从命令行，我认为您需要做git add -p。