为什么 Git Flow 建议将功能分支合并到开发分支而不是发布分支
Why Git Flow suggests that merging feature branches to dev branch instead of release branch
我们想切换到 Git 流程，但我有些担心，因为有两个不同的团队使用同一个存储库。
团队 A 想使用开发分支进行提交，但是团队 B 创建功能分支并工作 there.Team A 应该几乎每周的每一天都进行实时部署，而团队 B 则每周为部署准备发布包。
在这种情况下，我们可能很难将功能分支合并到开发和发布分支。这就是为什么我想直接将功能分支合并到发布分支。此外，我们可能希望将发布分支暂时搁置 demands.However git 流程不建议将功能分支合并到发布分支。根据流程，我们应该将我们的功能分支合并到开发分支，之后我们可以 create/update 从开发中释放分支。
长话短说，我将需要在部署之前相互更新开发和发布分支，或类似的事情。好像说不通。
那么，在 git 流程上管理这种情况的最佳方法是什么。
答案很简单：
- 团队 A 不想使用功能分支 → 他们想使用不同于 Git Flow 的分支和合并模型。
- 由于 A 队的原因，B 队希望将功能分支直接合并到发布分支 → 他们希望使用不同于 Git Flow 的分支和合并模型。
结论：不用Git流，就用Git.
我这么说，假设每个人都接受过使用普通香草 Git 的培训，而不仅仅是像 Git Flow 这样的抽象层。其实，Git Flow 不是一个产品，而是一个分支合并模型，就像我之前说的。具有相同名称的 Git 附加组件或 Git 流模型的多个 IDE 集成只是语法糖。想走偏就别用
在技术上有些无关，只是作为一名经验丰富（约 15 年）的敏捷教练大声思考：它说明了团队文化以及两个团队为同一产品做出贡献并致力于同一存储库的协作他们找不到关于 SCM 和发布周期的通用策略。
我们想切换到 Git 流程，但我有些担心，因为有两个不同的团队使用同一个存储库。 团队 A 想使用开发分支进行提交，但是团队 B 创建功能分支并工作 there.Team A 应该几乎每周的每一天都进行实时部署，而团队 B 则每周为部署准备发布包。
在这种情况下，我们可能很难将功能分支合并到开发和发布分支。这就是为什么我想直接将功能分支合并到发布分支。此外，我们可能希望将发布分支暂时搁置 demands.However git 流程不建议将功能分支合并到发布分支。根据流程，我们应该将我们的功能分支合并到开发分支，之后我们可以 create/update 从开发中释放分支。
长话短说，我将需要在部署之前相互更新开发和发布分支，或类似的事情。好像说不通。
那么，在 git 流程上管理这种情况的最佳方法是什么。
答案很简单：
- 团队 A 不想使用功能分支 → 他们想使用不同于 Git Flow 的分支和合并模型。
- 由于 A 队的原因，B 队希望将功能分支直接合并到发布分支 → 他们希望使用不同于 Git Flow 的分支和合并模型。
结论：不用Git流，就用Git.
我这么说，假设每个人都接受过使用普通香草 Git 的培训，而不仅仅是像 Git Flow 这样的抽象层。其实，Git Flow 不是一个产品，而是一个分支合并模型，就像我之前说的。具有相同名称的 Git 附加组件或 Git 流模型的多个 IDE 集成只是语法糖。想走偏就别用
在技术上有些无关，只是作为一名经验丰富（约 15 年）的敏捷教练大声思考：它说明了团队文化以及两个团队为同一产品做出贡献并致力于同一存储库的协作他们找不到关于 SCM 和发布周期的通用策略。