代码之家 › 专栏 › 技术社区 › cmcginty

集成器工作流程,远程回购的fetch rebase push安全吗?

integrator rebase workflow git

cmcginty · 技术社区 · 15 年前

我正在使用集成器工作流程管理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”重新设置为“同事”分支。我的目的是相反的,把“同事”的承诺放在主人的头上。所以我更新了这个例子。

5 回复 | 直到 15 年前

CB Bailey 15 年前

你肯定不想按你的建议去做,这会使 master 分支到你的同事的 主人 主人 是基于你可能会经常倒带中央 主人 .

你可能想做的是相反的,在将你的同事的主人合并成主人之前,重新平衡它。

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

不过,我还是不推荐这个。你的同事必须解决你如何重新平衡他们的变化。大多数时候,这可能是微不足道的,他们可以抛开自己的承诺而支持你的承诺,但这仍然是他们可能需要手动检查的东西。

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

另外,我也要小心不要瞄准不必要的线性历史。合并并行开发的开发人员的分支,可以更真实地表示历史。如果在合并之前重新设置开发人员的提交,那么您将不再拥有一个提交记录,该记录准确地表示开发人员修复并提交的代码的状态。这可能不太重要,但可能会发生两个提交交互产生一个bug,而不是合并冲突。如果你不重新平衡,你会得到一个更准确(更公平!)。责备。

Norman Ramsey 15 年前

关于git的大量文档和教程中的绝大多数都清楚地表明,REBASE只能用于私有分支,而不能用于其他人可以看到的内容。在你的模型下,我会非常害怕莫名其妙的失败,或者不得不在其他复制品上重复工作。避免!

VonC 15 年前

如“中所述” A truce in the merge vs. rebase war? “文章(强调我的)

也许传统的再平衡最糟糕的问题是 阻止协作 .
在重新平衡之前和之后从存储库中提取数据的人将经历冲突,因为这两个历史相互矛盾。因此,标准的警告是“不要在已发布的存储库中重新设置基”,这可以改写为“不要在以后可能希望重新设置基的工作上协作”。

即使它由于缺乏冲突而“起作用”,但如果您必须在重新设置期间解决任何重要的合并,它也可能会导致一些问题:

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

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

您(以前发布的)分支的sha-1正在重写,您的同事很难在其环境中合并该分支。

Greg Hewgill 15 年前

对于一般情况,这将是一个可接受的工作流。当你的同事,做一个 git pull ,这真的是一个 git fetch 其次是 git merge . Git非常擅长进行合并,能够解决简单的问题而不产生任何问题。

但是,如果您必须在 git rebase 步骤,那么你的同事可能要做那项工作 再一次 当他们拉的时候。这将发生,因为您的提交顺序看起来与它们的提交顺序在REBASE之后大不相同。

如果您对非线性历史感到满意,Git可能能够更好地管理此工作流(因为这正是它设计用来处理的)。

cmcginty 15 年前

我对这个工作流程做了一些简单的测试。我同意查尔斯的观点,但我想补充一些其他信息。

赞成的意见

工作流不会破坏从公共回购中提取的用户。
它使您能够更好地控制被拉入主线的提交。
更容易了解主线分支的功能历史。如果必须执行合并提交(标准工作流)才能在中提取多个更改,则合并提交将所有新提交的修改分组为单个提交。这打破了“一个提交一个特性”的习惯用法。

欺骗

在您从中提取更改的回购上,“原始”提交仍将显示。这可能会给贡献者增加困惑,除非他们知道你在做什么。我想解决这一问题的一种方法是让贡献者在您拉动并重新调整它之后扔掉它们的dev分支。
如果远程repo在您重新平衡之后不丢弃它们的dev分支,那么它会使主分支历史很难沿着远程分支进行跟踪。
在REBASE之后,您将在提交时释放原始作者的名称。(也许有一种手动的方法来解决这个问题。)这使得跟踪提交每个更改的人变得更加困难。