集成器工作流程，fetch-rebase-push 对于远程存储库安全吗？

Question

我正在使用集成器工作流程管理 git 存储库。 换句话说，我从同事那里提取提交，并将它们推送到受祝福的存储库。

我希望在大多数情况下保持提交历史记录呈线性，因此在集成更改时可以进行 rebase 而不是 merge 吗？ 这是一个示例：

git fetch coworker
git checkout coworker/master
git rebase master
git checkout master
git merge HEAD@{1}
git push

我担心远程存储库在执行下一次 git pull 时会发生什么情况。 git 是否能够处理此问题，或者 coworker 存储库在 pull 期间是否会失败，因为提交在 origin 上的顺序不同>？

更新：我最初的示例是从“master”重新建立“coworker”分支的基础。 我的意图恰恰相反，将“同事”提交置于主提交之上。 所以我更新了这个例子。

Answer 1

您肯定不想按照您的建议进行操作，它会将 master 分支重新设置为您同事的 master 分支。 根据您同事的 master 的基础，您可能最终会经常倒回中央 master。

您可能想做的恰恰相反，在将同事的 master 合并到 master 之前对其进行 rebase。

git fetch coworker
git checkout coworker/master
git rebase master
git checkout master
git merge HEAD@{1}
git push

但我仍然不推荐这个。 您的同事将必须解决您如何重新调整他们的更改的问题。 大多数时候，这可能是微不足道的，他们可以放弃自己的提交来支持你的提交，但这仍然是他们可能需要手动检查的事情。

就我个人而言，我建议直接合并他们的提交。 如果您觉得它们基于太旧的 master 版本，并且合并将变得不必要的复杂或基于不合理的旧提交，那么让他们重新调整其 master 的基础并重新获取。 然后至少他们知道您要合并什么，并且解决代码中的任何冲突。

另外，我要警告不要追求不必要的线性历史。 合并并行开发的开发人员分支可以让您更真实地再现历史。 如果您在合并之前对开发人员的提交进行变基，那么您将不再拥有准确表示该开发人员修复和提交的代码状态的提交记录。 这可能并不常见，但可能会发生两个提交交互产生错误，但不是合并冲突。 如果你不重新设定基准，你就会得到更准确（也更公平！）的“指责”。

Answer 2

关于 git 的大量文档和教程中的绝大多数都清楚地表明，rebase 只能在私有分支上使用，而不能被其他人看到。 在你的模型下，我会非常害怕莫名其妙的失败或不得不在其他副本上重复工作。 避免！

Answer 3

正如“合并中的休战中提到的vs. rebase war？”文章，（强调我的）

也许传统变基最严重的问题是它阻碍协作。
在变基前后从存储库中提取内容的人会遇到冲突，因为这两个历史相互矛盾。 因此，标准警告“不要在已发布的存储库中变基”，可以将其改写为“不要在以后可能想要变基的工作上进行协作”。

即使它因为缺乏冲突而“有效”，如果您必须在 rebase 期间解决任何重要的合并，它也可能会导致一些麻烦：

M0----M1----M2
\
 \
  \
   B1----B2

M0----M1----M2
            \
             \
              \
               B1'---B2'

您的（之前发布的）分支的 SHA-1 被重写，您的同事将有很难将该分支合并到他们的环境中。

Answer 4

对于简单的情况来说，这将是可接受的工作流程。 当您的同事执行 git pull 时，实际上是先执行 git fetch，然后执行 git merge。 Git 非常擅长进行合并，并且能够毫无问题地解决简单的情况。

但是，如果您必须在 git rebase 步骤中执行任何工作来解决冲突，那么您的同事在拉取时可能必须再次执行该工作。 之所以会发生这种情况，是因为在变基之后你的提交顺序看起来与他们的有很大不同。

如果您习惯了非线性历史记录，Git 可能能够更好地管理此工作流程（因为这就是它的设计目的）。

Answer 5

我对这个工作流程做了一些简单的测试。 我同意查尔斯的帖子，但想添加一些其他信息。

优点

• 工作流程不会中断用户从您的公共存储库中提取数据。
• 它使您可以更好地控制拉入主线的提交。
• 更容易跟踪主线分支的功能历史记录。 如果您必须执行合并提交（标准工作流程）来拉取多个更改，则合并提交会将所有新提交的修改分组到单个提交中。 这打破了“一次提交一项功能”的习惯。

缺点

• 在您从中提取更改的存储库上，“原始”提交仍然会显示。 这可能会给贡献者带来困惑，除非他们知道您在做什么。 我想解决这个问题的一种方法是让贡献者在拉取并重新设置基础后丢弃他们的开发分支。
• 如果远程存储库在您变基后没有丢弃它们的开发分支，那么它会使主分支历史记录难以与远程分支一起跟踪。
• 变基后，您将丢失提交中的原始作者姓名。 （也许有一种手动方法可以解决这个问题。）这使得跟踪谁提交了每个更改变得更加困难。