请教 git 管理的一个问题

[yujianwjj]

背景：一个代码仓库存在两个版本同时开发的场景，比如当前基于 develop 分支，拉了两个分支 dev_1.0 和 dev_1.1 。现在 dev_1.0 的功能开发完成了，测试也测试了，现网上线了。但是 dev_1.0 的分支没有合并到 develop ，导致 dev_1.1 上线的时候的代码没有包含 dev_1.0 的代码。

一般研发写完代码之后，只要测试不反馈问题，他们也不会去管后续的流程。最开始是组内通知大家，要记得把代码合并到 develop 。但是一个项目有好几个开发人员，靠人去做这件事情确实要花时间，你要跟进这个项目的进度。所以单纯的靠研发去做这件事情，也确实不合理。

现在的问题是，缺一个流程去做这件事情：代码上线之后把代码合并到 develop ，这件事情由谁来做，怎么做？

请教一下大家的公司是怎么做类似的事情的？

[admol]

@ray2023
得看是不是在开发同一个功能，如果明确是同一个功能要一起上线的，那可以共用一个 feature 分支。
如果不是或者不确定，最好是每个功能 feature 一个独立的 feature 分支。

这样上线的时候也可以很好的控制哪些功能可以上线（将 feature 分支合并到 release 分支），未测试完或者需要延期的也可以随时拿掉（不合并 release ）。
就算已经合并了 release 分支，其中某个功能不准备上线了，那也可以将之前的 release 分支删掉，然后重新合一个新的 release 分支。

所以最好是每个要上线的功能独立一个 feature 分支。

[ily433664]

发布到线上的包，肯定是要合到同一个分支

我们是这么用的
dev-xxx：开发中的版本，从 master 分支 checkout （开发各自操作）
dev：dev-xxx 分支完成后，统一合到 dev ，发布到开发环境（开发各自操作）
test：开发完成后将 dev-xxx 合到 test ，发布到测试环境（开发各自操作）
release：测试通过后将 dev-xxx 合到 release ，发布到生产环境（组长操作）
master：上线完成后，将 release 合到 master
bug-fix：线上 bug 在该分支修复，修复后按流程合到 dev 、test 、release 发布到各环境

[IAmSimon]

要不发生这种事情，要保证两点:
1. 上线前的代码都应该校验是否合并最新的 master
2. 上线后要及时合并代码到 master

为了做到这两点：
1. 公司需要一套比较完整的发布流程工具；
2. 没有的话，最好还是每次发版，除了发版的组员外，组长都要跟进，发布前发布后都要在

[GotKiCry]

用其他工单管理和 git 关联起来。定期 1 周或者 2 周合并指定工单需求。