Git：分支回滚前合并更改

Question

我已经陷入了很深的困境。

我在master分支上进行了重构更改，显著减少了功能。(我意识到这是一个错误。)

这开始引起问题，因为使用该更改后的程序是不可行的，但我已经在master上提交了进一步的、无关的改进。

所以，我撤销了master上的重构更改，并基于还原之前的提交新建了一个分支(比如说restructure)。

现在的问题是，master上已经有了更多有价值的提交，我想将它们合并到restructure中以便于开发。但是git merge尝试应用最初重构的撤销——糟糕!

我现在不确定该怎么办，我觉得现在做出的错误决定可能会严重复杂化以后回到master的合并过程。

更进一步让事情变得复杂的是，restructure分支已经被推送了。然而，如果可以解决所有问题，我不介意使用git push --force;只有少数人自那以后拉取了存储库。

我认为真正的解决方案可能无法回答所提出的问题——这绝对感觉像一个XY Problem场景——但我必须在标题中放入something :) 注意: 我意识到所有这些都是糟糕的git工作流的症状，这肯定足以激励我将来更加正确地处理事情。然而，我不能追溯地取消错误的行为，所以我的问题仍然存在 :)

- ehird

Answer 1

如果您还没有推送主分支（master），即使已经推送，也可以强制推送并重写历史记录，只需在主分支中使用 git rebase -i 命令并删除重构提交本身，而不是还原然后从主分支创建 restructure 分支（因为您最终会合并它）并在其上工作。

- manojlds

---

谢谢！这个完美地解决了问题；master确实已经被推送了，但我认为现在使用单个--force比已经存在的问题更少干扰... - ehird

Answer 2

你可以使用git cherry-pick命令将你想要的提交从主分支(master)复制到新分支中。它只会复制指定哈希标签中所包含的更改内容。请查看git-cherry-pick命令的手册。

- tpg2114

---

是的，我之前尝试过这个方法，它确实会将正确的更改带到“重构”中，但在尝试将事物合并回“主分支”时（仅在本地进行，以检查樱桃拣选是否破坏了任何东西），一切似乎比以前更加崩溃。不可否认，这可能是一个与所提出问题完全不同的问题... - ehird

一旦你从主分支中挑选出好的提交记录，就将主分支重置（不是还原）到重构之前的提交记录。只要你没有推送主分支，你可以安全地删除最后一个好的提交记录之后的所有提交记录。然后，主分支的末尾将对应于重构的开始，因此当你合并它们时，你应该得到想要的结果。 - tpg2114

毋庸置疑，在你开始永久删除提交之前，请备份此存储库 :) - tpg2114

但是，除了重构之外，在master上进行重构后的所有提交都应该留在master上；我只想将它们也拉到restructure中。不幸的是，更改已经被推送了，但大约有5个人拉取存储库，所以我认为最简单的方法可能是消除原始的重构提交和还原并使用git push --force重新提交... - ehird

好的，这样想吧——在重新架构之前，你需要回到主分支，删除所有在此之前的内容，然后将那些你一开始从重新架构中精选出来的好的提交记录挑选出来。把重新架构看作是那些好的提交记录的临时存放地，也是重新架构的永久家园。 - tpg2114

我最终按照manojlds的建议，在master上进行了一次变基，因为这似乎更直接且同样“具有破坏性”，但我认为那种方法也可以正常工作。不过还是感谢你们的帮助，这帮助我确切地找出了问题所在，并学会了如何一般性地解决这些问题。如果Stack Overflow认为我够受欢迎，我会给你点赞的 :) - ehird