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

[solider245]

如题，最近学习 git 发现这个 release 分支有点搞不明白。本身 release 分支就是从 develop 分支分出去的，为什么不能直接删掉，而是要先和 develop 合并一次后再删除呢？

[aragakiyuii]

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

[optional]

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

[solider245]

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

[solider245]

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

[yyfearth]

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

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

[mattxlee]

我的管理习惯是，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 分支过来。

[wd]

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

[msg7086]

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

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

[jzphx]

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

[passerbytiny]

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

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

[acthtml]

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

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

[hantsy]

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

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

[xinple]

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

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

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

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

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

[solider245]

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