7

问题是关于git-flow方法的一些边缘案例

我有一些典型的 git-flow 历史,如下所示:

      o---o---o---o [release-3.5.0]
     /
----o---o---o---o---o [development]

Git-flow 告诉我们将release-3.5.0分支合并到开发中,然后发布准备就绪。所以,最终我们会得到所有的变化,在发布分支到开发分支。

      o---o---o---o 
     /             \
----o---o---o---o---o [development]

现在想象一下,我们在发布分支上有一个提交'X',这是我们在开发分支中想要的,例如它是某种黑客/修补程序,或者已经以更理智的方式在开发中修复(即通过提交 Y)

      o---X---o---o [release-3.5.0]
     /
----o---o---o---Y---o [development]

那么,主要问题是如何处理这种情况?如何防止此提交(或提交)重新投入开发?

4

3 回答 3

7

虽然推荐rebase和/或合并/恢复/壁球的答案会起作用,但我个人认为更好的答案是:

git checkout development
git merge --no-commit release-3.5.0
# make whatever changes you need to fixup the "hack" and/or clean up any conflicts
git commit
于 2013-06-24T15:00:54.570 回答
3

在这种情况下,您总是希望完全合并发布(类似)分支。所以确保没有遗漏任何东西。

但在合并期间,您可以自由修改内容——包括删除或重做一些更改。对于您的示例情况,合并分支,恢复您不喜欢的提交,并将恢复为合并提交的压缩。显然在该操作的合并提交消息中记下。

如果修复程序已经在开发中,合并将跳过它,或者您通过选择开发版本来解决冲突。

关键是您希望历史显示为您的第二个数字,以及最有意义的状态。

于 2013-06-24T10:14:30.477 回答
1

你有几个选择:

1) 使用git rebase -i

在这种模式下,您可以在开发分支上重新设置发布分支并排除第 X 次提交。

警告在这种情况下,您将弄乱现有的克隆存储库。

2) 使用git cherry-pick

在这种模式下,您将有可能一一选择提交。

3)git rebase -i在单独的分支上使用并在之后合并它,如本答案中所述:Is it possible to exclude specific commits when doing a git merge?

于 2013-06-24T10:04:46.920 回答