Git合并先前恢复的提交的PR(但不是所有恢复的提交) [英] git merge PR of previously reverted commits (but not all the reverted commits)

问题描述

我已查看了多个类似的问题和答复，但这些问题和答复对我的情况都不起作用。

最近一次是在2017年"Github does not recognize…"

我遇到的情况是

• 分行A&>B
• B(添加100个提交)
• B-&>C(添加1个提交)
• B(再添加100个提交)
• 事故：B通过PR合并到A(w/200提交)
• 补救措施：还原PR(w/1 Commit)
• 愿望：将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的工作最终需要转移到A，那将会是什么情况？

加分问题，以上解决办法的后续

• 如果您有Azure Git分支策略，它们属于分支还是属于分支名称？

---

对于需要混凝土的人：

• A-master
• B-develop
• C-1.3发布分支
• D-1.2版本(目前不作为分支存在，只是标记1.2.0，…，而且很可能不会使用)

---

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

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

在此问题上搁浅后，我将知道下一次(希望永远不会发生)我将立即联系DevOps团队，以获得对所需分支的临时访问权限，并以希望使用的方式使用工具。恢复提交非常不可取。

推荐答案

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

• 分行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之前的第二个提交，仅在其第一个父级之后。这将是上图中的Commit 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中的那个COMMIT是单独的吗？把它挑到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工作流。

这篇关于Git合并先前恢复的提交的PR(但不是所有恢复的提交)的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！