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