进行多次提交和一次推送与每次提交和推送之间有什么区别吗

Question

如果我们做以下2种情况，git repo有区别吗：

• 案例 1：进行 10 次提交，最后进行一次推送
• 案例2：一次提交一次推送，每次提交重复上述步骤10次

Answer 1

这取决于贡献者的数量和远程仓库的合并策略。

1. 只有一名贡献者，政策允许直接推送。

   不同之处在于您运行 push 命令的次数。两种方式的最终代码和历史记录都是相同的。

2. 多个贡献者且政策允许直接推送。

   如果你通过一次推送推送 10 次提交，要么是因为快进推送而成功，要么是因为非快进推送而失败。如果你推送一个提交，你有更多的机会因为非快进推送而失败。在您的两次推送之间，远程分支可能会被其他贡献者更新，这使得您的本地分支与远程分支分歧，并且您的下一次推送将在您执行获取和合并/rebase 之前失败。 “提取和合并/变基”可以在单个命令 git pull 或 git pull --rebase 中完成。

3. 合并策略只允许合并/变基拉取请求。

   如果只有一个贡献者，您不太可能采用这样的政策。所以我们只讨论一个团队。如果您的团队使用像 Gerrit 这样的审查工具，您将面临这种情况。推送后，新提交不会立即合并到远程分支中。每个提交都保存在 Gerrit 使用的引用中，例如像 refs/changes/34/12234/1 这样的引用。在审阅者审查您的更改并批准后，这些参考将被合并到真正的分支中。如果审稿人认为它不合格，则 ref 被拒绝。您必须修改它或重置为以前的提交，进行新的提交，然后再次推送。将创建一个新的 ref 以供审查。 Github 中的 pull-request 并不完全相同，但非常相似。

   在这种情况下，即使是非快进推送，您的推送也将始终成功，因为您实际上并未推送到真正的分支。 Gerrit 带领您创建其他 refs。如果你一次推送 10 个提交，将创建 10 个 refs，并且都是依赖的。您可以将它们从最老的到最年轻的一一合并。如果有任何冲突，您可以修复它，或者跳过它并重新设置其继任者。

   如果您推送一个提交并在前一个提交被批准和合并后推送下一个，其他团队成员可以在您的两次推送之间推送和合并他们的提交。同样，您可能有更多失败的机会，因为您的下一次合并总是可能引发冲突。两次推送的间隔时间越长，失败的机会就越大。当然，在每次推送之前添加git pull 或git pull --rebase 会降低这种可能性，因为大多数潜在的冲突都可以在本地修复。但并非所有事情都可以避免，因为每当要合并一个 ref 时，真正的分支可能已经被其他人在一秒钟前更新了。

   实际情况更复杂，差异可能很大。

Answer 2

在最终结果中：否。在此期间，多次推送会更快地将中间提交放在那里。但是在第 10 次推送与单次推送结束时，您将推送 10 次提交。

这很容易测试自己。

但是，如果您的计算机在您进行单次提交之前崩溃了，那么您将失去比增量推送更多的工作。
或者，其他贡献者可能有更多的合并冲突，或者至少在访问您的增量更改方面有更大的延迟。

如果您进行了 10 次更改，每次更改一次提交，而不是一次提交中进行 10 次更改，那么您会有所不同。