【问题标题】:git rebase on a feature branch already pushed to remotegit rebase 基于已推送到远程的功能分支
【发布时间】:2021-09-17 03:57:06
【问题描述】:

假设我在本地有功能分支,FB。 FB 在提交时与 master 发生了分歧,比如 CC。 FB 还有几个提交,比如 FBC1,FBC2.FB 被推送到远程存储库,然后合并到 master。所以远程master有FBC1,FBC2,然后之前和之后还有几个提交。

现在,如果我将远程提交拉到本地,那么我的本地主机现在拥有 CC-MC1-MC2-FBC1-FBC2-MC3-MC4,而 FB 拥有 CC-FBC1-FBC2。所以master和FB都有提交FBC1,FBC2。

现在如果我在 FB 上 rebase master,那会是什么行为?

【问题讨论】:

  • 你为什么不试试看呢?
  • 我觉得什么都不会发生,因为如果我理解正确的话,FB已经是master的祖先了。

标签: git rebase


【解决方案1】:

tl;dr: 它将做 rebase 所做的事情,即在目标分支之上重放源分支中但不在目标分支中的所有(非合并)提交.

首先让我们考虑与您所问的相反的情况:如果我们将FB 重新设置为master 会怎样? FB 中的每个提交都已经在 master 中,因此它将在 master 之上放置 0 个提交。结果是FB 将被重置为与master 完全相同。

现在问你的问题,如果我们将master 重新设置为FB,则在master 但不在FB 上的每个(非合并)提交都将在FB 之上重播。您的示例仅显示了合并提交,但大概是在分支 FB 的合并提交之前和之后的那些合并提交在合并中引入了其他一些提交?在这种情况下,所有这些提交都将在没有相应的合并提交的情况下重播,并且在提交 FB2 之后,图形将被修改为线性。 (这假设没有冲突并且变基成功。)

要查看哪些提交将被重放并随后在 master 上“重新排列”,您可以运行以下命令:

git log FB..master --no-merges

这显示了master 中所有不在FB 中的提交,减去合并提交。

【讨论】:

    【解决方案2】:

    我不认为它会做任何事情,因为当您尝试重新设置分支时,git 会尝试找到所涉及的分支之间的最后一个共同祖先......并且此时修订是 FB 的尖端所以 git看到没有什么可以变基的。

    【讨论】:

      猜你喜欢
      • 2012-03-24
      • 2011-09-10
      • 2016-07-08
      • 2022-10-20
      • 1970-01-01
      • 2013-06-10
      • 2017-02-23
      • 2012-07-25
      • 1970-01-01
      相关资源
      最近更新 更多