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

Question

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

• 案例 1:进行 10 次提交，最后一次推送
• case 2:一次commit一次push，每次commit重复10次

Answer 1

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

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

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

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

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

3. merge 策略只允许 merge/ rebase pull 请求。

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

   在这种情况下，即使是非快进推送，您的推送也总是会成功，因为您实际上并没有推送到真正的分支。 Gerrit 带头 push 创建其他引用。如果一次推送 10 个提交，将创建 10 个引用，并且所有引用都是依赖的。您可以将它们从最年长的到最年轻的一一 merge 。如果有任何冲突，您可以修复它，或者跳过它并重新定位他们的继任者。

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

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