Git - 如何找到可能包含已恢复提交的分支？答案

【问题标题】：Git - how to find branches that may contain commits which were reverted?Git - 如何找到可能包含已恢复提交的分支？
【发布时间】：2016-07-28 19:38:30
【问题描述】：

我们最近从 SVN 切换到 Git（使用 gitflow），我正在进行一些检查，以确保在公共分支上进行的任何还原也可以在从上述分支中删除的分支中还原可能已经获取要恢复的提交的公共分支。

下面的简单示例。 f1 在提交 X 时从开发中删除。提交 A、B 和 C 在 f1 上进行，f1 在提交 Y 中合并回开发。f2 在提交 Z 时从开发中删除。提交 D 和 E 在f2。通过使用“git revert -m1”恢复 f1 合并提交，不会在开发时恢复 f1 的所有更改。现在，如果 f2 合并到 development，它仍然会包含 f1 的更改，并将它们添加回 development。

                               |reverts f1 
 develop-> X---o---o---Y---Z---R---P <- merge f2 to develop picks up f1
            \         /     \     /
        f1-> A---B---C  f2-> D---E

我一直在使用 'git branch -r --contains' 来查找包含此提交的任何其他分支。

我想知道的是，我怎样才能使它变得更好？如何以编程方式检查任何其他可能包含来自 f1 的提交的分支？有没有办法自动恢复其他分支的提交？基本上，我需要确保 f1 不能通过任何其他分支（例如 f2 在它们被恢复之前拾取 f1 提交）返回开发。

编辑：为了在将修复添加到分支后最终将 f1 提交合并回开发，我将重新设置为 A、B、C 以及修复提交创建新提交。所以，在 rebase f1 之后会有 A'、B'、C'，并修复提交 F 和 G。

【问题讨论】：

标签： git version-control merge git-flow

【解决方案1】：

好吧，在您的示例中，没有必要将 R 分支到 f2。您不会合并 E 中文件的状态，而是合并 f2 中所做的更改。所以 A、B 和 C 仍然会在 P 中被排除在外，而 R 不会被挑选到 f2 中。

为了证明这一说法，这里有一个命令链，可以准确再现您可以执行和查看的场景：mkdir test && cd test && git init && git checkout -b develop && touch X && git add X && git commit -m X && git branch f1 && touch o1 && git add o1 && git commit -m o1 && touch o2 && git add o2 && git commit -m o2 && git checkout f1 && touch A && git add A && git commit -m A && touch B && git add B && git commit -m B && touch C && git add C && git commit -m C && git checkout - && git merge f1 -m Y && touch Z && git add Z && git commit -m Z && git checkout -b f2 && touch D && git add D && git commit -m D && touch E && git add E && git commit -m E && git checkout - && git revert HEAD~ -m 1 -n && git commit -m R && git merge f2 -m P && gitk

【讨论】：