简体繁体 English

为什么 Git Flow 建议将功能分支合并到开发分支而不是发布分支

[英]Why Git Flow suggests that merging feature branches to dev branch instead of release branch

原文 2021-01-25 00:42:05 4 1 git/ merge/ version-control/ git-flow

We want to switch to Git flow but i have some concerns because there are two different teams using same repository.我们想切换到 Git 流程，但我有一些担忧，因为有两个不同的团队使用相同的存储库。 team A want to use dev branch for committing however team B creates feature branches and works there.Team A should make live deployments almost every days of week, in other hand team B prepares weekly release packages for deployments.团队 A 想要使用开发分支进行提交，但是团队 B 创建功能分支并在那里工作。团队 A 应该几乎每周的每一天都进行实时部署，另一方面，团队 B 准备每周发布包进行部署。

in this case it may be hard for us that merging feature branches to both dev and release branches.在这种情况下，我们可能很难将功能分支合并到 dev 和 release 分支。 Thats why i want to merge the feature branches to the release branches directly.这就是为什么我想直接将功能分支合并到发布分支。 Also we may want to park the release branches for a while on demands.However git flow does not suggest merging feature branches to the release branch.此外，我们可能希望根据需要将发布分支停放一段时间。但是 git 流程不建议将功能分支合并到发布分支。 According to flow we should merge our feature branches to dev branch, after that we may create/update release branch from dev.根据流程，我们应该将我们的功能分支合并到 dev 分支，之后我们可以从 dev 创建/更新发布分支。

Long story short i will need to update the dev and release branches with each other just before deployment, or something like that.长话短说，我需要在部署之前相互更新开发和发布分支，或者类似的东西。 it seems doesn't make sense.这似乎没有意义。

so, what the best way to manage this situation on git flow.那么，在 git 流上管理这种情况的最佳方法是什么。

1 个解决方案

The answer is quite simple:答案很简单：

Team A does not want to use feature branches → they want to use a branching & merging model different from Git Flow.团队 A 不想使用功能分支 → 他们想使用不同于 Git 流程的分支和合并 model。
Team B wants to merge feature branches directly to the release branch because of team A → they want to use a branching & merging model different from Git Flow.团队 B 想要将功能分支直接合并到发布分支，因为团队 A → 他们想要使用不同于 Git 流程的分支和合并 model。

Conclusion: Don't use Git Flow, just use Git.结论：不要使用 Git 流，只使用 Git。

I am saying this, assuming everyone is trained in using plain vanilla Git and not just an abstraction layer like Git Flow.我这么说，假设每个人都接受过使用普通 Git 而不仅仅是像 Git Flow 这样的抽象层的培训。 Actually, Git Flow is not a product but a branching & merging model, like I said before.实际上，Git Flow 不是一个产品，而是一个分支和合并 model，就像我之前说的。 The Git add-on with the same name or several IDE integrations of the Git Flow model are just syntactic sugar. Git 插件具有相同的名称或多个 IDE 集成 Git 流 Z20F35E630DAF394D8F4 是语法糖。 If you want to deviate, don't use it.如果你想偏离，不要使用它。

Somewhat unrelated technically, just thinking aloud as a seasoned (~15 years) agile coach: It says something about team culture and collaboration of two teams contributing to the same product and committing to the same repository that they cannot find a common strategy with regard to SCM and release cycles.在技术上有点不相关，只是作为一名经验丰富（约 15 年）的敏捷教练大声思考：它说明了团队文化和两个团队的协作，他们为同一个产品做出贡献并致力于同一个存储库，他们无法找到关于以下方面的共同策略SCM 和发布周期。