git merge PR 之前还原的提交（但不是所有还原的提交）

Posted 2023-02-21

【中文标题】git merge PR 之前还原的提交（但不是所有还原的提交）

【英文标题】：git merge PR of previously reverted commits (but not all the reverted commits)

【发布时间】：2021-11-02 03:54:02

【问题描述】：

我查看了多个对我的情况不起作用的类似问题和回复。

最近，"Github does not recognize…" 2017 年

我有这样的情况

分支 A -> B B（添加 100 次提交） B -> C（添加 1 个提交） B（添加另外 100 个提交） 意外：B 通过 PR 合并到 A（w/200 次提交） 补救措施：恢复该 PR（1 次提交）

愿望

：将 C 合并到 A

想法/尝试

PR (C -> A) 没有看到变化 侧边栏：PR (A -> C) 将尝试从 C 恢复相关更改 - 这定义了所需的努力，但相反 创建 C'，从 A 变基 C，PR 看不到更改（因为合并/还原不涉及 C） 无法还原还原（above link 中的选项 1），这将包括不需要的 B 内容 我必须挑选樱桃吗？ ？？？ （还原的 PR 不会列出所有提交，只显示 99，然后在“显示全部”时失败）

这是一个解决方案/解决方法吗：

重命名 A -> D； D 之后可能不会被使用 重命名 C -> A 如果是这样，那么 B 会离开哪里，B 的工作最终需要转移到 A 中？

加分问题，跟进上述解决方法

如果您有 Azure git 分支策略，它们属于

分支

还是

分支名称

？

---

对于那些需要混凝土的人：

A - master B - develop C - 1.3 发布分支 D - 1.2 发布（目前不作为分支存在，只是标签 1.2.0，...，可能不会使用）

---

注意：在我们的环境中，公司已将分支机构 A 锁定，因此我无法直接 push -f 访问它，也无法在服务器上 git reset --hard。

如果这些是选项，我会立即这样做。

在这件事上搁浅了，下次我会知道（希望永远不会发生）我会立即联系 DevOps 团队，以临时访问所需的分支，并以他们想要的方式使用工具。提交的还原是非常不可取的。

【问题讨论】：

你是如何还原的？

当你说要将 C 合并到 A 时，是否要引入 B 的 100 次提交？

这个问题有更新吗？如果答案能给你一些帮助，请随时告诉我。只是提醒this。

@Schwern 还原是在 Azure 的服务器上完成的；右侧的三点菜单中有一个菜单项可以“恢复” PR。多提交 PR 被单次提交还原。

【参考方案1】：

让我们画出您的存储库，以便我们都在同一个页面上。

分支 A -> B B（添加 100 次提交） B -> C（添加 1 个提交） B（添加另外 100 个提交）

我不会写出 100 次提交，2 次就可以了。

1 - 2 - 3 [A]
         \
          4 - 100 - 5 - 200 [B]
                \
                 7 [C]

意外：B 通过 PR 合并到 A（w/200 次提交）

1 - 2 - 3 ------------------ M [A]
         \                 /
          4 - 100 - 5 - 200 [B]
                \
                 7 [C]

补救措施：恢复该 PR（1 次提交）

1 - 2 - 3 ------------------ M - R [A]
         \                 /
          4 - 100 - 5 - 200 [B]
                \
                 7 [C]

现在问题是你的 A 历史被 B 的所有这些垃圾污染了，然后是一个巨大的回归。这会引起各种头痛。

我建议通过在合并和还原之前将 A 重置为 force pushing 来清理您的历史记录。

git checkout A git reset --hard A~2 git push --force-with-index。

A~2 是 A 之前的第二次提交，仅在其第一个父母之后。这将是上图中的提交 3。

做完这些，你又回到了傻瓜之前。

1 - 2 - 3 [A]
         \
          4 - 100 - 5 - 200 [B]
                \
                 7 [C]

愿望：将C合并到A

取决于这意味着什么。

C 是否依赖于它在 B 中的部分？要合并 4 和 100 吗？然后合并 C。合并 C 后，将 B 重新定位到 A。

$ PR(C->A)
$ git checkout A
$ git pull
$ git checkout B
$ git rebase A

1 - 2 - 3 -----------[A]
         \           / \
          4 - 100 - 7   5 - 200 [B]

C 中的那个提交是独立的吗？ Cherry 将其拾取到 A 上并合并。

$ git rebase --onto A C~ C
$ git checkout A
$ git merge --no-ff C
          7' [C]
         / \
1 - 2 - 3 -- [A]
         \
          4 - 100 - 5 - 200 [B]

---

最后一条建议，如果你真的将 200 次提交放在一个分支中，那么你的分支就太大了。把你的工作切成小块。考虑采用Feature Branch 或Gitflow 工作流程。

【讨论】：

是的，200 次提交是夸大其词，但我想指出，那里的工作量不适合挑选（但是由于一些工作，我们确实达到了 100 次提交的限制）应该被压扁但没有）；取决于“将 C 合并到 A”的含义：是的，我想要合并 4、100 和 7；你的步骤对我来说很有意义，谢谢 - 我只需要暂时取消对 A 分支的限制（不允许使用git push -f）。

@bshirley Cherry pick 将接受一系列提交，因此提交的数量无关紧要。