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