请教 git 管理的一个问题

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


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

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

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

组长来操作合并，merge 代码到 develop ，我在公司就是做这个事情的。人工操作起来确实挺繁琐的，但是不会出什么大问题，这个人需要熟悉系统工程，有冲突了也可以解决；也尝试过给开发人员各自操作，但是会出现问题，或者难以管理

测试验证通过了合并到 master / main 分支，develop 发生产不对经吧。 你看看 git 的 workflow 。分支规范是 feat-, bugfix

基于 develop 开发新功能分支 dev_1.0/ dev_1.1...，然后 dev_*上线了，那自然应该把 dev_*合并回 develop ，谁开发谁负责合并回去，因为如果此时有冲突，只有负责这个新分支的人能处理。

要么人工来操作合并。要么使用 gitlab ，github 走 issue+ MR/PR 流程（半自动合并）

dev_1.0 是基于 dev 拉下来的，你最后上线应该合并到 dev 上去，上线 dev 的代码

所有的代码改动，无论是新功能开发，还是线上 bug 修复，都先进主干分支，再进发布分支

首先，一个版本先确定要更新的功能列表，然后，根据功能建分支开发，如果模块间相对独立，可以在测试环境分别部署测试，如果存在前后依赖就需要都完成再测试。在上线前，需要将所有的功能合并到主分支，然后做回归验证，确定符合预期再上线。

这题不会，就从分支名和基于 develop 分支开发，管理就够乱的。
我们 master 和 feature 分支管理，参考 workflow 。

```测试也测试了，现网上线了。但是 dev_1.0 的分支没有合并到 develop ```
不允许非生产分支的代码部署到 prod 。
cicd 的流程不明确。

上线分支一定是一条固定的分支
比如基于 main 拉出了两条开发分支，测试的时候可以各个环境用各个功能的开发分支，上线的时候一定是先合并到 main 分支，然后用 main 分支上线