假设我有一个分支 case-xyz，我在其中处理案例 #xyz，“实现 Hello World”。
在开发过程中，我添加了调试输出等，这些不应成为最终提交的一部分。
我可以做类似下面的事情吗:
- 分支到 case-xyz-debug 并只在那里提交调试代码。
- 偶尔将 case-xyz-debug merge 到 case-xyz。
- 在 case-xyz 中提交应该进入最终补丁的内容。
- 最后，“反向 merge ”case-xyz-debug，即删除来自该分支的所有更改，与 merge 到 case-xyz 的时间无关。换句话说，这应该等同于从 case-xyz-debug 中恢复所有 merge 。
我知道在还原 merge 提交时，Git 不会忘记 merge ，也就是说，它仍然认为你已经 merge 了，所以你只能通过还原还原来重新 merge 。因此，只需要删除最初在 case-xyz-debug 中提交的所有更改，如何记录是无关紧要的。但是，如果我也可以执行以下操作，那就太好了:
- git checkout case-xyz
- git checkout case-xyz-done
- git "反向 merge "case-xyz-debug
因为我可能想继续开发/调试:
- git checkout case-xyz
- 更改文件
- git commit -am "哎呀，忘了东西"
- git checkout case-xyz-really-done
- git "反向 merge "case-xyz-debug
我希望我的意图是明确的。如果能以完全不同的方式实现这一点，我也会很高兴。
最佳答案
作为我正常工作流程的一部分，我经常通过交互式 rebase 来做这类事情。我提交的内容包括调试日志记录、临时测试更改(例如线程 sleep 调用以测试计时问题、故意抛出异常以测试错误处理代码)、硬编码值，以便更轻松地在我的应用程序中进行端到端测试，而无需在 UI 中输入值等。我将这些事情保存在独立的提交中；按照我自己的惯例，如果提交日志消息全部大写，则表示不应将提交推送到远程。
当我准备好“反向 merge ”这些更改(删除它们)时，我会通过交互式 rebase 这样做:
git rebase -i <id of branch point>
我只是删除了包含所有大写消息的提交。
(您实际上可以将其用于其他目的，例如将它们重新排序以便它们都位于分支的开头，这对于 git commit --amend 'ing 您的实际工作很有用，或者将它们重新排序到末尾，这可以当你想将 branch-point..<id of last real commit> 推送到远程时很有用，让你的“调试”提交完好无损并在当前历史行的末尾。)
知道 <id of branch point> 是什么可能有点痛苦；在我的工作流程中，我不想将我的分支重新定位到 f.e. 的末尾。 master ，同时删除调试提交；出于这个原因，我保留了一个本地 float 标签，我将其用作引用点，我将其简单地称为 rebase(这可能会造成混淆，但您可以选择任意命名)。如果这看起来工作量太大，使用 git rebase -i `git merge-base HEAD master` 可能是您的一个选择。
(我理解关于这是一种危险做法的论点，但我不认为它们特别有说服力；使用 SCM 有上百万种方法可以搬起石头砸自己的脚。您应该考虑 git rebase --abort 和git reflog 将成为你的“逃生舱口”，以防你不小心删除了包含超过你的调试代码的提交。)
HTH
关于git - "Reverse-merge"一个分支，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/12492881/