在 Git 中：为什么经常提交是好的？ [关闭]答案

【问题标题】：In Git: Why is it good to commit often? [closed]在 Git 中：为什么经常提交是好的？ [关闭]
【发布时间】：2015-02-25 09:40:20
【问题描述】：

所以总的来说，我对 Git 和 DVCS 还是很陌生，而且我一直在到处阅读，至少在私有分支上，“始终提交总是好的”。问题是：为什么？我正在使用 SourceTree（带有图形界面的 Git 客户端），并且我发现一旦一切正常并且我完成后提交我的代码会更容易（暂存然后），因为在提交之前我仍然可以在 SourceTree 中看到我的差异。

那么更频繁地提交的原因是什么？我应该多久做一次？

【问题讨论】：

为了最大程度地降低两个并发更改之间的冲突风险并拥有较小的提交粒度，您可以更轻松地重新排序和移动。
好吧，你可以“一直”在本地提交，只有在一切正常时才推送。
DVCS - How often and when to commit changes 的可能重复项
@chmike “尽量减少两个并发更改之间发生冲突的风险”？。我不明白这个。如果我是唯一一个在一个项目上工作的人，那么就没有冲突的风险，如果有更多的人在一个项目上工作，那么在我推送我的提交之前不会出现“冲突”，那么制作的意义何在许多提交，如果我完成后它们仍然会同时被推送？
@vikingsteve 这正是我的问题：我为什么要一直提交？

标签： git commit atlassian-sourcetree

【解决方案1】：

经常提交背后的想法是为自己创建一个实时的变化源。我认为这也是一种保护措施，以防您对代码进行小幅更改，出现问题并丢失您正在处理的版本。这样，它就减少了对人类记忆的必要性，而是依赖于（冗余）计算机存储。

【讨论】：

好的，所以我必须经常提交以获得更详细的更改历史记录，这样我就可以在出现问题时恢复这些更改。我做对了吗？另外，让我们假设以下情况：我在一个大项目中更改了一个文件，这导致其他 10 个需要更改的文件出现错误。我应该在更改每个文件后提交吗？还是应该在所有文件都已更改（并且没有错误）之后再做？
@modellero，就个人而言，在您给出的示例中，即使文件仍然有错误，我也会在您所做的每一次更改后提交。这与调试的原理相同，您将注释掉每一行，直到找到错误为止。另一方面，您希望创建尽可能少的“间隙”。如果您进行 100 次更改并提交一次，然后在 3 天后发现错误.... 废话，这 100 次更改中的哪一个导致了错误？对 100 个单独的提交进行排序以缩小故障点比通过一个巨大的提交并在大海捞针更容易。
@modellero，与其说“一直提交总是好的”，不如说“提交太多总比不够好”。

【解决方案2】：

经常提交是好的，原因与经常备份的好处相同。当你有不想丢失的代码时提交，比如在成功 make check 之后。

与大多数集中式版本控制系统（例如 Subversion 或 CVS）不同，您可以在您的代码准备好之后但在您推送或与世界分享之前回过头来润色凌乱的历史记录，因此 git 不会强迫您“第一次做对。”

【讨论】：