进行多次提交和单次推送v / s之间是否有任何区别，每次提交和推送

Question

如果我们执行以下两种情况，git repo是否存在差异：

• 案例1：最后做10次提交，最后一次推送
• 案例2：执行一次提交和推送，每次提交重复步骤10次

Answer 1

在最终结果中：否。在此期间，多次推送会使中间提交更快。但是在第10次推送与单曲的结束时，你将推送10次提交。

这很容易测试自己。

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

如果你做了10次更改，每次更改一次提交，而单次提交中有10次更改，那么你会有所不同。

Answer 2

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

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

   区别在于您运行push命令的次数。最终的代码和历史将在两个方面相同。

2. 不止一个贡献者和政策允许直接推送。

   如果您通过一次推送推送10次提交，则由于非快进推送而导致快速推送或失败，因此成功。如果您推送一个提交，则由于非快进推送，您有更多机会失败。在您的两次推送之间，远程分支可以由其他贡献者更新，这使得您的本地分支与远程分支分开，并且在您执行获取和合并/ rebase之前，您的下一次推送将失败。 “fetch and merge / rebase”可以在单个命令git pull或git pull --rebase中完成。

3. 合并策略仅允许合并/转换拉取请求。

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

   在这种情况下，即使是非快进推送，您的推送也会一直成功，因为您实际上并没有推送到真正的分支。 Gerrit引领您创建其他裁判。如果你一次推送10次提交，将创建10个引用并且所有引用都是相关的。您可以将它们从最旧到最小的一个一个地合并。如果存在任何冲突，您可以修复它，也可以跳过它并为其后继者进行修改。

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

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