我目前正在尝试在我的团队中设置开发流程并阅读GitFlow。它看起来很有趣,但我可以发现一些问题。
让我们假设以下情形:
我们完成了功能F1
,F2
和F3
,并将这些功能合并到develop
分支中。基于此,我们创建了一个release
分支。
如果我们想摆脱功能F3
,我们该怎么办?
看看这张图片以获得更好的主意。
答案 0 :(得分:6)
这确实是git-flow的弱点。我认为有很多方法可以解决这个问题,其中没有一个是完美的。
一种方法是简单revert
来自F3的合并提交。
git checkout <release-branch>
git revert --mainline 1 <hash-of-f3-merge-commit>
--mainline 1
(简-m 1
)告诉git相对于它的第一个父级恢复合并提交的更改,这是在其中合并更改的分支在我们的例子中,这将是develop
。
另一方面,当您将release
分支合并回develop
时,这会导致问题,因为这也会合并恢复。您可能必须将功能(F3)重新合并到develop
。
此方法使您的发布分支基于最新状态master
而不是develop
。
git checkout -b master <release-branch>
从这里开始,您可以cherry-pick
要在发布中包含的每个功能。再次使用--mainline
选项。
git cherry-pick --mainline 1 <hash-of-f1-merge-commit>
git cherry-pick --mainline 1 <hash-of-f2-merge-commit>
另外,您可以merge
将功能分支到发布分支而不是cherry-pick
,这将导致相同的结果但是在更混乱的历史中(这可以使用{{ 1}}选项后跟--squash
,但之后您已经有效地完成了git commit
)。
cherry-pick
如果每个版本仅包含一小部分已开发的功能,那么替代版本库方法并不是那么糟糕,但如果您想要发布大量功能则很难使用。< / p>
我个人更喜欢后一种方法,因为它会在没有恢复和重复合并提交的情况下产生更清晰的历史记录。