Question

假设我有一个分支案例-xyz，我在案例#xyz，“实施Hello World”的工作。

在开发期间，我添加了调试输出等，这些不应该是最终提交的一部分。

我可以执行以下操作：

分支到case-xyz-debug并仅在那里提交调试代码。
偶尔将case-xyz-debug合并到case-xyz。
在case-xyz中提交应该进入最终补丁的内容。
最后，“反向合并”case-xyz-debug，即删除来自该分支的所有更改，与它们何时合并到case-xyz无关。换句话说，这应该等同于从case-xyz-debug恢复所有合并。

我知道在还原合并提交时，Git不会忘记合并，即它仍然认为您已经合并，因此您只能通过还原恢复来重新合并。因此，只需要删除最初在case-xyz-debug中提交的所有更改，记录的内容是无关紧要的。但是，如果我还可以执行以下操作，那就太好了：

git checkout case-xyz
git checkout case-xyz-done
git“reverse-merge”case-xyz-debug

因为我可能想继续开发/调试：

git checkout case-xyz
更改文件
git commit -am“哎呀，忘记了什么”
git checkout case-xyz-really-done
git“reverse-merge”case-xyz-debug

我希望我的意图很明确。如果这可以实现，但以完全不同的方式，我也会感到高兴。

Answer 1

我通过交互式变基作为常规工作流程的一部分来做这件事。我提交的内容包括调试日志记录，临时测试更改（fe线程睡眠调用以测试计时问题，故意抛出异常以测试错误处理代码），硬编码值使我更容易在我的应用程序中进行端到端测试而无需在UI等中输入值。我将这些事物保存在隔离的提交中;根据我自己的约定，如果提交日志消息全部为大写，则表示不应将其推送到远程的提交。

当我准备“反向合并”这些更改（删除它们）时，我会通过交互式rebase来实现：

git rebase -i <id of branch point>

我只是删除了包含所有大写消息的提交。

（你实际上可以将它用于其他目的，例如重新排序它们以便它们都在分支的开头，这对于git commit --amend实际工作很有用，或者将它们重新排序到结束，当你想将branch-point..<id of last real commit>推送到遥控器时，这可能很有用，让你的“调试”提交保持原样，并保留在当前历史记录的末尾。）

知道<id of branch point>是什么可能有点痛苦;在我的工作流程中，我不想将我的分支重新命名为f.e. master，同时我删除了调试提交;出于这个原因，我保留了一个本地浮动标记，我将其用作参考点，我只需要调用rebase（这可能会让人感到困惑，但您可以根据自己的喜好选择命名）。如果这似乎太多工作，使用git rebase -i `git merge-base HEAD master`可能是你的选择。

（我理解这是一个危险的做法的论点，但我发现它们并不特别引人注目;有一百万种方法可以用SCM射击自己。你应该考虑{{{{{ 1}}和git rebase --abort将成为您的“逃生舱”，以防您意外删除包含超过调试代码的提交。）

HTH

“反向合并”一个分支

1 个答案: