有人将变基或重置推送到已发布的分支后，如何恢复/重新同步？

Question

我们都听说过，永远不应该对已发表的作品进行变基，这是危险的，等等。但是，我还没有看到任何发布的方法来说明如何处理变基发布的情况。

现在，请注意，只有当存储库仅由已知的（最好是一小群）人克隆时，这才是真正可行的，这样无论谁推动变基或重置都可以通知其他人，他们下次需要注意拿来（！）。

如果您在 foo 上没有本地提交并且它会被重新设置，我见过的一个明显的解决方案将起作用：

git fetch
git checkout foo
git reset --hard origin/foo

这将简单地丢弃 foo 的本地状态，以支持其根据远程存储库的历史记录。

但是，如果一个人对该分支进行了重大的本地更改，该如何处理这种情况呢？

Answer 1

在大多数情况下，在推送变基后恢复同步实际上并不那么复杂。

git checkout foo
git branch old-foo origin/foo # BEFORE fetching!!
git fetch
git rebase --onto origin/foo old-foo foo
git branch -D old-foo

IE。首先，您为远程分支最初所在的位置设置一个书签，然后使用它来重播从该点开始的本地提交到重新定位的远程分支。

变基就像暴力：如果它不能解决你的问题，你只需要更多。 ☺

当然，如果您查找预变基 origin/foo 提交 ID 并使用它，您当然可以在没有书签的情况下执行此操作。

这也是您处理在获取之前忘记创建书签的情况的方法。不会丢失任何内容 - 您只需要检查远程分支的引用日志：

git reflog show origin/foo | awk '
    PRINT_NEXT==1 { print $1; exit }
    /fetch: forced-update/ { PRINT_NEXT=1 }'

这将打印 origin/foo 在最近一次更改其历史记录的提取之前指向的提交 ID。

然后你可以简单地

git rebase --onto origin/foo $commit foo

Answer 2

我想说 git-rebase 手册页的 从上游 rebase 恢复 部分几乎涵盖了所有这些。

这实际上与从您自己的变基恢复没有什么不同 - 您移动一个分支，并将历史记录中包含该分支的所有分支变基到新位置。

Answer 3

从 git 1.9/2.0 Q1 2014 开始，在重写的上游分支上重新建立基础之前，您不必标记以前的分支源，如 亚里士多德 Pagaltzis 的答案：
请参阅 提交 07d406b 和 提交 d96855f ：

在使用 git checkout -b topic origin/master 创建的 topic 分支上工作后，远程跟踪分支 origin/master 的历史记录> 可能已被倒回并重建，导致了这种形状的历史：

<前><代码> o---B1
/
---o---o---B2--o---o---o---B（来源/主站）
\
B3
\
派生（主题）

其中 origin/master 曾经指向提交 B3、B2、B1，现在它指向B，当 origin/master 位于 B3 时，您的 topic 分支就在其之上启动。< /p>

该模式利用origin/master的reflog找到B3作为分叉点，从而可以将topic在更新后的 origin/master 之上重新建立：

$ fork_point=$(git merge-base --fork-point origin/master topic)
$ git rebase --onto origin/master $fork_point 主题

这就是为什么 git merge-base 命令有一个新选项：

--fork-point::

查找分支（或导致的任何历史记录）从另一个分支（或任何引用）分叉的点。

这不仅会查找两个提交的共同祖先，而且还会考虑 的引用日志，以查看历史记录是否导致 < ;commit> 从分支 的早期版本分叉出来。

---

“git pull --rebase”命令使用“base”分支（通常是远程-跟踪分支）该分支的工作是基于的，以应对“基础”分支被倒带重建的情况。

例如，如果历史记录如下所示：

• “base”分支的当前尖端位于 B，但之前的 fetch 观察到其尖端曾经是 B3，然后B2 然后 B1
  在到达当前提交之前，并且
• 在最新“基础”之上重新建立的分支基于提交 B3，

它尝试通过“git rev-list --reflog base”的输出来查找B3（即B，< code>B1、B2、B3），直到找到当前提示“派生（主题）”。

在内部，我们有 get_merge_bases_many() 可以一次性计算此值。
我们希望在 Derived 和虚构的合并提交之间建立一个合并基础，该提交是通过合并“base (origin/master)”的所有历史提示而产生的。
当这样的提交存在时，我们应该得到一个结果，它与“base”的引用日志条目之一完全匹配。




---

Git 2.1（2014 年第 3 季度）将添加使此功能更加强大的功能：请参阅 commit 1e0dacd 通过 John Keeping (johnkeeping)

正确处理我们具有以下拓扑的场景：

    C --- D --- E  <- dev
   /
  B  <- master@{1}
 /
o --- B' --- C* --- D*  <- master

其中：

• B' 是 B 的修复版本，与 B 补丁不同；
• C* 和 D* 分别与 C 和 D 补丁相同，如果应用于顺序错误；
• E 在文本上依赖于 D。

git rebase master dev 的正确结果是 B 被识别为 dev 和 master 的分叉点，因此 C、D、E 是需要重播到 master 上的提交；但 C 和 D 与 C* 和 D* 补丁相同，因此可以删除，这样最终结果是：

o --- B' --- C* --- D* --- E  <- dev

如果未识别分叉点，则将 B 选取到包含 B' 的分支上会导致冲突，并且如果补丁相同的提交不存在正确识别，然后将 C 选择到包含 D（或等效的 D*）的分支上会导致冲突。

---

“git rebase”的“--fork-point”模式在 2.20 时代用 C 重写命令时出现了退化，已在 Git 2.27（Q2）中得到纠正。 2020）。

请参阅 提交 f08132f（2019 年 12 月 9 日），作者：Junio C Hamano (gitster)。
^{（由 Junio C Hamano -- gitster -- 合并于 提交fb4175b，2020年3月27日）}

变基：--fork -点回归修复

^{签字人：Alex Torok
[jc：改进了修复并使用了 Alex 的测试]
签署人：Junio C Hamano [电子邮件受保护]}

"git rebase --fork-point master”过去工作正常，因为它内部调用“git merge-base --fork-point”知道如何处理短引用名称并在调用底层 get_fork_point() 函数之前将其 dwim 为完整的引用名称。

在用 C 重写该命令后，情况不再如此，因为直接对 get_fork_point() 进行的内部调用不会显示短引用。

将“git merge-base”中使用的“dwim the refname argument to the full refname”逻辑移动到底层的 get_fork_point() 函数，以便该函数的另一个调用者“git rebase”的实现与修复此回归的行为方式相同。

---

对于 Git 2.31（2021 年第一季度），“< code>git rebase --[no-]fork-point"^(man)" 获得了一个配置变量rebase.forkPoint，这样用户就不必继续指定非默认设置，

请参阅 commit 2803d80（2021 年 2 月 23 日）< a href="https://github.com/alexhenrie" rel="nofollow noreferrer">亚历克斯·亨利 (alexhenrie)。
^{（由 Junio C Hamano -- gitster -- 合并于 提交 682bbad，2021 年 2 月 25 日）}

rebase：为<添加一个配置选项代码>--无叉点

^{签字人：Alex Henrie}

一些用户（包括我自己）希望默认关闭此功能，因为它可以默默地删除提交。

git config 现在包含在其 手册页：

rebase.forkPoint

如果设置为 false，则默认设置 --no-fork-point 选项。