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

Question

如果我们执行以下两种情况，git repo 是否有区别:

• 情况 1:进行 10 次提交并在最后进行一次推送
• 情况 2:进行一次提交和一次推送，每次提交重复该步骤 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 到真正的分支中。如果审稿人认为不合格，则该裁判被拒绝。您必须修改它或重置为以前的提交，进行新的提交，然后再次推送。将创建一个新的引用进行审查。 Github 中的 pull 请求并不完全相同，但非常相似。

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

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

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