有没有这样做多次提交，并推

Question

独推V/S每次提交沿之间的差额是否有混帐回购的差异，如果我们做了以下2种情况：

• 案例1：做10个提交和在结束
• 壳体2的单个推：做一个提交和一推，重复步骤10次，每次提交

Answer 1

在最终结果是：号在此期间，所述多个推将使中间人更早提交。但在第10次推出vs单曲结束时，您将推出10次提交。

这很容易测试自己。

但是，如果您的计算机在进行单次提交之前崩溃，那么与增量推送相比，您将失去更多工作。
或者，另一位贡献者可能会遇到更多合并冲突，或者至少在获取您的增量更改时遇到更大的延迟。

如果您进行了10次更改，每次提交一次提交，而单次提交更改为10次，那么您将有什么区别。

Answer 2

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

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

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

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

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

3. 合并策略仅允许合并/重新绑定请求。

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

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

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

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