我用谷歌搜索了很多，但我找不到答案。
据我所知，每次编辑文件时都应应用提交。解释编辑的内容，原因等。
然后我应该推送提交以使文件的服务器版本同步。
我无法理解的是：
为什么我应该提交而不是立即推送我编辑的文件？
确实，在使用版本控制时，您要做的一件非常常见的事情是："将更改记录到提交中，然后将该提交发送到远程服务器"。事实上，大多数 Git GUI 工具可能允许您一步完成此操作。但是，从逻辑上讲，"将更改记录到提交"和"将提交发布到服务器"是不同的操作。在 Subversion 中，只有服务器会跟踪提交，所以你必须将更改发送到它才能实现。在 Git 中，本地存储库也会跟踪提交，因此可以拆分它们。
现在，虽然在一个步骤中执行这两个步骤是一个常见的工作流，但在很多情况下，您可能想要执行其他操作：
- 您
目前不在线，或者远程服务器碰巧关闭，或者由于某种原因您与它的连接速度很慢。 也就是说，发送更改在技术上是不可能的，或者会中断您的工作并长时间扰乱您的注意力。在这种情况下，希望将发布提交推迟到以后，但您希望在此之前继续工作（并进行提交）。
您希望必须合并同事的更改。这是处理代码的一个非常大的上下文切换，与上述情况类似，您可能希望将其延迟到完成任务后，以便您可以专注于它。（事实上，这往往是 Subversion 团队中一个非常普遍的问题——"合并很烦人"的心态，让人们在离开时做一整天的工作，而没有真正正确地解决冲突。由于使用具有明确目的的"nice"提交更容易解决冲突，因此这会产生恶性循环。
您正在通过电子邮件发送补丁为项目做出贡献。（这就是Linux内核过去开发的方式，也许现在仍然是。这个需求实际上影响了 Git 早期的设计。
您正在进行非常频繁的提交，并可能将它们推送到私有远程存储库以进行备份。但是，您希望在发布它们之前使用
git rebase来清理它们 - 例如，将新功能与初始实现中发现的错误修复捆绑到单个提交中。
一个基本原因：您正在提交一个甚至还不存在远程服务器上的功能分支，因此没有什么可推送的。（这也是需要的，功能分支不一定需要广泛发布。
基本上，Git 力求最大的灵活性，以支持任意复杂的工作流程。现在，您可能不需要这个，在这种情况下，您可以轻松使用 GUI 或小型 shell 脚本来组合您需要的东西。
上面的答案很好，但我这样做还有一个更重要的原因 - 有时，在一个分支上进行本地测试时，我希望有自定义配置，但这些配置不应发送到实际的远程存储库。在这种情况下，在本地提交它有助于我保持该配置的安全。