假设我有一个分支case xyz，在这里我为case xyz“实现hello world”工作。
在开发过程中，我添加了调试输出等，这些输出不应该是最终提交的一部分。
我能做如下事情吗：
分支到case xyz调试并仅在那里提交调试代码。
偶尔将case xyz debug合并到case xyz中。
提交应该进入最后一个补丁的内容以防xyz。
最后，“反向合并”case xyz debug，即删除来自该分支的所有更改，这与它们何时合并到case xyz无关。换句话说，这应该相当于从case xyz debug还原所有合并。
我知道，在还原合并提交时，git不会忘记合并，也就是说，它仍然认为您已经合并，所以您只能通过还原还原来重新合并。因此，只有在删除xyz调试时，才需要最初提交的所有更改，如何记录这些更改是无关紧要的。不过，如果我也能做如下事情，那就太好了：
Git签出案例XYZ
Git签出案例xyz完成
git“反向合并”case xyz调试
因为我可能想继续开发/调试：
Git签出案例XYZ
更改文件
git commit-am“哦，忘了什么”
Git签出案例xyz真的完成了
git“反向合并”case xyz调试
我希望我的意图是明确的。如果这能实现，但以完全不同的方式，我也会很高兴。
最佳答案
我经常通过交互重新调整来做这类事情，作为我正常工作流程的一部分。我有包括调试日志记录、临时测试更改（例如，测试计时问题的线程睡眠调用、故意抛出异常以测试错误处理代码）、硬编码值以使在我的应用程序中进行端到端测试更容易，而不必在ui中输入值等的提交。我将这些类型的内容保存在独立的提交中；通过根据自己的约定，如果提交日志消息是全大写的，则表示不应将提交推送到远程。
当我准备“反向合并”这些更改（删除它们）时，我会通过一个交互式的rebase来执行此操作：
git rebase -i <id of branch point>
我只是删除了包含所有caps消息的提交。
（实际上，您可以将其用于其他目的，例如对它们重新排序，使它们都位于分支的开头，这对于
git commit --amend'调整实际工作很有用，或者将它们重新排序到末尾，这在您希望将branch-point..<id of last real commit>推送到远程时很有用，使“调试”提交保持完整并位于当前历史行的末尾。）知道什么是
<id of branch point>可能会有点痛苦；在我的工作流中，我不想在删除调试提交的同时将分支重新定位到末尾，例如master；因此，我保留了一个本地浮动标记，用作引用点，我只需调用rebase（这可能会让人困惑，但您可以随意选择命名它）。如果这看起来工作太多，使用git rebase -i `git merge-base HEAD master`可能是您的一个选择。（我理解有人认为这是一种危险的做法，但我不认为它们特别有说服力；有无数种方法可以让你用单片机自杀。）您应该考虑将
git rebase --abort和git reflog的某些组合作为您的“转义图案填充”，以防您意外地删除包含超过调试代码的提交。）高温高压
关于git - “反向 merge ”分支，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/12492881/