什么是主分支和发布分支？
我的英语不够理解 git flow
为了我的理解.
Master branch 适用于可由用户在市场上下载的现成产品.
但是有一个release branches我没有想法这些分支是为谁发布的？
发布给客户？还是质量保证？
min*_*nas 60
一旦develop获得了足够的发布功能(或预定的发布日期即将到来),您就可以将发布分支从发布中分离出来.创建此分支将启动下一个发布周期,因此在此之后不能添加任何新功能.只有错误修复,文档生成和其他面向发布的任务才能进入这个分支(包括测试).一旦准备好发布,该版本将合并到主服务器并标记版本号.此外,它应该合并回到开发中,自发布以来可能已经取得了进展.
使用专用分支准备发布使一个团队可以完善当前版本,而另一个团队继续为下一个版本开发功能.它还创建了明确定义的开发阶段(例如,很容易说,"本周我们正在为4.0版做准备"并实际在存储库的结构中看到它).
更多信息这里的分支机构
- 您使用什么来创建此图？ (8认同)
- @RicardoTribaldos，在这种情况下你不允许合并，而且，还有 github 或 gitlab 或任何其他服务的部分，你可以在其中配置要合并的规则以及人们可以合并的分支。还有代码审查。 (2认同)
小智 14
正如V.Driessen在原帖中所解释的那样:
Master是一个永久的分支,总是反映生产就绪状态.所以是的,它适用于可由用户在市场上下载的现成产品.
Release是一个临时支持分支,支持准备新的生产版本.这意味着主要是由minas指出的bug修复,文档等.
在您链接的图表中,是,master用于发布给用户的"现成产品".(不是每个人都用master这种方式.)
在图中,每次团队准备新的"现成产品"版本时,他们都会创建一个新的"发布"分支.虽然他们正在准备发布,但他们没有为"发布"分支添加任何新功能 - 添加新功能可能会导致新的错误,他们正试图让"发布"版本在上市之前尽可能稳定.他们确实将"提交"添加到"发布"分支以修复在最终测试期间发现的任何问题,弄清楚粗糙点等.因此创建"发布"分支标记"功能冻结"点 - 他们决定只有他们已经开发的功能将进入下一个公开发布.
一旦他们准备好使用新版本的产品上市,他们就会将"发布"分支合并到master标签中,用于构建可公开下载的产品.(如果他们发布版本1.0,他们可能会标记提交1.0,依此类推.)
与此同时,当他们处理新功能时,他们会创建新的"功能"分支(分支出来develop)并提交给他们.当新功能正在运行时,它们会将其分支合并回来develop.develop总是向前迈进.
- 感谢您的详细回答，请澄清有关此步骤的更多信息：“他们将“发布”分支合并到主分支中，并标记用于构建可公开下载产品的提交。” 这个版本（由 *master* 构建）是否必须由 QA 再次测试（最终）？导致通过合并、环境配置可能会发生意外情况... (2认同)
- @ThinkTwiceCodeOnce 这取决于您的工作流程的详细信息。如果您“仅”允许 master 通过合并发布分支来向前推进，那么永远不应该在不在最新发布分支上的“master”上进行提交。或者，您可以直接将提交添加到“master”，但这样做时，请确保它们始终被精心挑选到下一个发布分支。将提交添加到“master”并且“不”将它们添加到下一个发布分支是没有意义的。 (2认同)
| 归档时间： |
|
| 查看次数： |
34816 次 |
| 最近记录： |