9

有很多关于在 git 中“撤消”合并是多么不容易的话题。简短版本：如果您撤消合并提交，它还会告诉 git 将来永远不要合并这些更改。

在进行合并时我可以做些什么来减轻这个问题吗？在很多情况下，撤消合并真的非常有用，只是在软件开发的正常过程中，更重要的是，在需要回滚更改时控制发布分支的状态。

编辑

我在这篇文章中看到了解决方案，并没有真正将其视为解决方案，更多的是对问题的解释。这个需要

  1. 总是使用 --no-ff
  2. 当您想要恢复依赖于它们的代码时，请记住所有未完成的合并（这可能是未来的几个小时、几天、一周或几个月……）

我想要的是

这是它在 Subversion 中的工作方式。假设我有一个名为“release-candidate”的分支，它是我们在登台服务器上运行的，也是我们尝试功能的地方。假设我合并到功能 A 分支中。在 Subversion 中，它是一个变更集，所有文件的所有历史都被合并。假设我们不喜欢它，所以我们想把它拿出来。我们只需撤消那个单一的变更集，而不必考虑其他任何事情。我们可以在将来的任何时候将功能分支 A 合并回来，而不必记住我们曾经将它合并并取出。

我希望能够尽可能接近该流程。我想优化“将来不必记住东西”，即使它使事情在某种程度上采取了更多步骤。（这可能是不可能的......）

4

1 回答 1

11

更新：

一个更容易使用每个功能的分支的工作流程在这里：http ://dymitruk.com/blog/2012/02/05/branch-per-feature/

（问题的SVN部分最后已经回答）

是的，这是您如何重新引入您取消合并的功能。考虑以下历史（假设您已经“撤消”了合并）：

x---x----x--x---x--M--U--L
     \            /
      x--x--x--x-F

F 是功能分支，M 是合并，U 是当您取消合并该功能时相反，L 是最新提交。

以下是您的选择：

  1. 还原 U（无需--force推动）：

    x---x----x--x---x--M--U--L--^U
    \            /
     x--x--x--x-F

  2. 将 F 重新设置为 L （然后合并--ff-only F'）（无需--force推送）：

    x---x----x--x---x--M--U--L
     \            /       \
      x--x--x--x-x         x'--x'--x'--x'--F'

  3. 将 F 重新设置为 L （然后合并--no-ff F'- 保留您的新分支点）（无需 --force 推送）：

    x---x----x--x---x--M--U--L-------------------M2
     \            /       \                 /
      x--x--x--x-x         x'--x'--x'--x'--F'

  4. rebase -i head^^并从列表中删除 U （--force需要推送）：

    x---x----x--x---x--M--L
     \            /
      x--x--x--x-F

  5. rebase --onto M^1 L^ L摆脱合并和取消合并。现在您可以稍后重新合并 F。

                      L'
                 /
x---x----x--x---x--M--U--L
     \            /
      x--x--x--x-F

要压缩所有功能提交，请--squash在初始合并上使用修饰符。我会让你的想象力来研究历史上的样子。我不建议这样做是有原因的。了解您如何使某个功能发挥作用以及它采取了哪些步骤是有价值的。后续合并会更容易，因为 Git 可以检查某个文件为何看起来如此的历史记录。将提交压缩在一起会丢失该信息。

还有一些额外的缺点可能会或可能不会影响您利用 rerere 历史记录的能力。

我建议始终在 master 中使用空白合并标记发布的内容。这是通过与--no-ff选项合并来完成的。您永远不会在 master 上工作，并且唯一完成的提交就是那些合并 - 没有代码更改提交。在 QA 分支中，您标记标记您发布时间点的提交。所以当你这样做时git merge --no-ff rc-12.2，你会自动生成一个提交注释“merged rc-12.2”。

查看 git-flow。

希望为您提供更多详细信息。

于 2011-01-19T22:07:49.950 回答