不懂就问:git 的 release 分支本身是从 develop 分支分出去的，为什么不能直接删除掉还要再合并一次？

用 git flow 的话，release 上应该会有 bug fix

就像一楼说的有 bugfix 需要合并，不过我不喜欢合并，pick 过来比较好，而且有些 fix 不一定是需要的

@aragakiyuii 我看教程，release 一般都是稳定发行版，也就是说正常来说测试结束了才会发行。
而且，release 一般不合并 bugfix，只有 master 分支和 develop 分支才合并 bug 呀。有点稀里糊涂了

@optional release 被 master 合并后，我直接删掉这个分支可以吗？

@solider245 要看你的 Release Model 如果你要同时支持多个版本 Release 分支就必须留着 而且还会有 bugfix 合并
比如 Release v1.0 分支 但是 master 已经到 v2.0 了
就算你 Release v1.0 分支 之前已经合并到 master 了
但是还是有可能有 hotfix 要进 v1.0 分支啊 除非这个版本不再支持

如果是线上项目或者是敏捷项目 只需要支持一个最新版 那么 Release 分支就没必要了 加上 Release Tag 就好

我的管理习惯是，release 分支一定会保留，而开发是放在 master 分支上，一旦 master 中的内容可以被测试并且发布了，就在 release 分支上使用 git merge master --no-ff，一定要保留合并的记录，因为我的 release 分支是要被打包到 docker image 里用于发布的。如果是 hotfix 且 master 上有在开发到一半，那么应该是要从 master 分支被 release 合并的那次提交 checkout 出来，hotfix 测试完成后，release 合并这次 hotfix 的提交发布新版本。然后，在一个合适的时候（可能是下一次 release，也可以是下一个功能的开始），把 hotfix 合并到 master 上。如果 hotfix 时 master 上没有开发到一半的提交，则直接在 master 上做这次 hotfix 的修改，完成后就再在 release 分支上合并 master 分支过来。

这有啥好问的，你如果能保证你的 release 总是只包含 develop 的内容，那自然可以删除，因为即使 merge 也没有什么变更。

分支只是指向一串提交头部的一种可变指针。
Git 本质上是一大串提交互相连接，分支帮助你定位节点进行操作，删掉不删掉并不是很重要的事情。
关键是把修改的提交合并到正确的地方。

Release 分支也好 master/dev 分支也好，要看你们具体的分支定义的。
通常 Release 分支上只保留 bugfix，master 和 dev 分支则是 bugfix 和 new feature 都有。
这个不同的项目，不同的公司，都有不同的约定，按照你们自己的约定去做就行了。

有句土话叫 一千个读者眼里有一千个哈姆雷特。你描述的问题应该算分支策略，没有绝对的可以或者不可以，很多书或者文章描述的是作者自己的习惯，习惯的人多了就成了规范

这应该是个命名暧昧，你这个 release 分支既然还要往 /从主分支合并新东西，那它其实并不是“release ”，而是“release and maintenance”。如果只是版本发布，那是不变的，只需要打标签而不需要开分支。

你看这个工作流应该是继承 cvs/svn 的“主干＋多个维护分支”工作流。

https://juejin.im/post/5b3dfc316fb9a04fc4369ef3

这里的 release 章节能解答你的问题。

Git Flow 显得有点复杂。我除了自己玩，没有在项目中使用。

目前还是喜欢 Github Flow （使用 Fork 方式），Master 永远是最新的稳定代码（开发全部走 Branch，PR 合并前，经过 CR，和 CI 回归测试，稳定可靠），要 Release 一个版本也简单，直接在 Master 找个版本打 Tag，tag 再触发 CI 任务自动部署到生产环境。小团队 Tag 环节省了，直接合并到 Master 就部署了。

了解一下流程就行了。然后通过开发实战按需使用，当需求来的时候不知不觉就用上了。

我个人的经历就是十几年前大家开发好都是打包发给其他人覆盖，遇到冲突用文件对比工具处理；
后来发现 svn 很好用就用上了，那时候感觉很舒爽，质的飞跃；
再后来 git 流行了，对比了下发现比 svn 更好，然后就换了 git ；

用了 git 之后，刚开始 master 一把梭，后来发现开发人多了，加上开始流行敏捷开发项目需要时不时迭代上线了，就多开了 develop 分支，保持 master 为测试过的生产环境版本；

再后来发现 develop 分支都不够用了，就开始细分了 bugfix 分支，搞完合并到 develop 和 master ；有些比较独立的新功能或实验性功能，并且不急着上线的就开了 feature 分支去搞，搞完感觉 ok 的合并到 develop ；然后一个版本搞完了要给测试人员测试，但是 develop 还在开发新功能，于是就弄了 release 分支给测试去用，测出来 bug 直接在上面改。

就这样不知不觉按需逐个用上了，然后某一天发现一个文章说 git flow 流程，看完发现这不就是已经用上了的流程吗？

@xinple 原来是这样，有时候还会在 release 上测试。我看很多文章说 release 已经是稳定版了