为什么应该在Git中提交而不是推送？

Question

我已经搜索了很多，但是找不到答案。

根据我的理解，每次编辑文件时都应该提交一次commit。解释编辑的内容、原因等等。
然后我应该推送commit，使服务器版本的文件同步。

我不明白的是：

为什么我要提交而不是立即推送我编辑过的文件？

- Fez Vrasta

---

1. 你现在不在线。
2. 你正在进行一个需要通过电子邮件发送补丁的项目。
3. 在推送之前，你想将自己的更改合并到一个较为清晰的状态中。
4. 由于远程仓库位于速度较慢的服务器上或网络连接较慢，因此你想继续工作，并在去喝咖啡时再进行推送。Git 的设计允许在工作流程方面具有很大的灵活性，其中断"记录对仓库的更改"和"在仓库之间交换更改"是他们实现这一点的方式之一。

- millimoose

另外还有第4点：你承诺推送到一个服务器上不存在的本地分支。 - chepner

老实说，有很多合理的理由想要分别执行这两个操作，所以问题应该是“为什么SVN把这两个操作捆绑在一起？” - millimoose

这取决于你如何看待版本控制。如果你认识到它不仅仅是关于发布你的更改，而且还有助于跟踪（可能是未完成的）修改，那么不推送变得更加清晰。 - Benjamin Bannier

换句话说，“记录更改并立即将更改发送到远程服务器”是一个非常常见的需求。这也是为什么大多数Git GUI工具都可以方便地完成这个操作。但从逻辑上讲，它们是两个独立的操作，因此可能会出现您想要单独执行它们的情况。这就是为什么git允许您选择加入这两个操作，而不是强制将它们合并在一起的原因。 - millimoose

Answer 1

在使用版本控制时，记录更改并将其发送到远程服务器是您想要完成的非常普遍的事情。实际上，大多数Git GUI工具可能都可以在一步中完成此操作。然而，从逻辑上讲，“记录更改为提交”和“发布提交到服务器”是不同的操作。在Subversion中，只有服务器跟踪提交，因此您必须将更改发送到服务器才能实现这一点。在Git中，本地存储库也会跟踪提交，因此可以将它们拆分。

现在，虽然一次性完成这两个操作是常见的工作流程，但在许多情况下，您可能希望执行其他操作：

1. 您当前没有联网，或者远程服务器正好处于离线状态，或者由于某些原因连接速度很慢。即发送更改既不可行，又会在较长时间内打断您的工作并干扰您的注意力。在这种情况下，您需要推迟发布提交，但是要继续工作（并进行提交）直到那时为止。

2. 您预计要合并同事的更改。这是从编写代码转换到合并的一个非常大的上下文切换，类似于上面的情况，您可能希望推迟此操作，直到完成任务，以便保持专注。 （实际上，这往往是Subversion团队的一个非常普遍的问题-“合并很烦人”的心态会导致人们在离开时将一天的工作做成一个提交，而没有真正解决冲突。由于采用明确目的的“好”提交更容易解决冲突，因此这会造成恶性循环。）

3. 您正在通过电子邮件向项目贡献补丁。 （这是Linux内核过去如何开发的方式，也可能仍然是。实际上，这个要求早期影响了Git的设计。）

4. 您正在进行非常频繁的提交，并可能将它们推送到私人远程存储库以备份。但是，您希望使用git rebase在发布之前对其进行清理-例如，将新功能与最初实现中发现的错误修复结合为单个提交。

一个具体的原因是：你正在提交一个在远程服务器上还不存在的功能分支，所以没有东西可以推送。（这也是有意的，因为特性分支不一定需要广泛发布。）

基本上，Git 旨在通过最大的灵活性来支持任意复杂的工作流程。现在，你可能不需要这个，那么你可以轻松地使用 GUI 或小的 shell 脚本来组合你需要的东西。

- millimoose

---

另外，有时我会暂缓提交以避免触发CI，直到我非常确信我的代码是干净的，并且已经进行了测试。 - bitsapien

Answer 2

以上答案很好，但我这样做还有一个更重要的原因——有时，在测试某个分支时，我想要自定义配置，但这些配置不应该发送到实际的远程仓库。在这种情况下，本地提交帮助我保持该配置的安全性。

- berlin