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

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

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

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

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

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