git - 用于管理频繁发布的 git-flow 的替代方案

Question

我想知道人们正在使用什么 git 分支/发布策略，并且会推荐具有以下要求的项目:

1. 频繁发布(每周发布系列)
2. 能够随时进行热修复
3. 产品变化频繁的相当复杂/大型项目

我们已经尝试使用 Git-flow 进程 ( http://nvie.com/posts/a-successful-git-branching-model/ )，但有两个主要问题:

1. 我们在发布分支期间的任何时候测试的代码与将要发布的内容不完全相同(自发布以来分支需要在最后与 master merge )
2. 重构更改很难处理，并且在发布分支与 master merge 时经常会导致 merge 冲突。

是否有适合这种情况的其他 git 工作流，或者其他人如何使用 Git-flow 克服这些问题？

Answer 1

The code we test against at any point during the release branch isn't exactly the same as what will be released (since the release branch needs to get merged with master at the end)

这没有意义。发布分支和主分支之间的 merge 本质上应该只是快进 - 你的主分支应该由你的发布决定，而不是相反。

Refactoring changes are hard to deal with and will often result in merge conflicts when the release branch merges with master.

请参阅上面的发布分支指示主分支。此外，只要您不对分支分离点之前的任何提交进行 rebase ，您就可以在开发时尝试对您的功能分支进行 rebase 。

在将你的分支 merge 到 develop 之前，你应该将 develop 分支 rebase 到 feature 分支之上，这样当你将 feature 分支 merge 到 develop 时，你会得到一个没有 merge 冲突的快速 merge 。您应该在开发期间定期执行此操作(可能每天一次到一周一次，具体取决于存储库中的提交量)。

如果您在功能完成后进行重构，并且您只是在重构开发分支，那么，是的，您应该预料到 merge 会很困难。

但是，当您将发布分支 merge 到主分支或开发到发布分支时出现 merge 问题，表明没有正确遵循链接流程。