背景：一个代码仓库存在两个版本同时开发的场景，比如当前基于 develop 分支，拉了两个分支 dev_1.0 和 dev_1.1 。现在 dev_1.0 的功能开发完成了，测试也测试了，现网上线了。但是 dev_1.0 的分支没有合并到 develop ，导致 dev_1.1 上线的时候的代码没有包含 dev_1.0 的代码。
一般研发写完代码之后，只要测试不反馈问题，他们也不会去管后续的流程。最开始是组内通知大家，要记得把代码合并到 develop 。但是一个项目有好几个开发人员，靠人去做这件事情确实要花时间，你要跟进这个项目的进度。所以单纯的靠研发去做这件事情，也确实不合理。
现在的问题是，缺一个流程去做这件事情：代码上线之后把代码合并到 develop ，这件事情由谁来做，怎么做？
请教一下大家的公司是怎么做类似的事情的？

看了大家的意见，是发生产的时候要把代码合到 develop ，然后重新打包。我们这边是，测试测完之后，测试负责把他验证过的包推到生产环境。另外还有一个问题，发生产其实是先发灰度，比如现在基于 dev_1.0 打了包，发了灰度，然后有问题，还是会在 dev_1.0 上面继续开发并合并代码。

当然是组长了，发生产的时候就要合并分支了

打包要从 develop 分支打包，不在 dev_1.1 上打包

组员提合并请求合并到 dev,上线用 dev 的代码

dev_1.0 开发完成之后要合并到 develop 分支上，然后从 develop 分支发布上线

为啥要起 dev 1.0 1.1 这种混淆的名字呢devmain这是雷打不动的 2 个分支其他起名一律就叫 feature 或者 fix ，这种分支是不允许打包上线的。只能合并到上游

生产代码不在 develop 分支，直接 dev_1.0 就可以发布上线？

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

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

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

＃9 打错了，gitflow 模型

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

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

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

至于谁做这件事情，建议是偏技术，对功能模块、模块间数据交互都比较了解，甚至这个人可以在合并代码做代码审查，总之这个人可以对整个服务负责。

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

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

如果不是多版本并发模式，而是单版本滚动模式，那就规定上线代码必须从 main 主分支拉出。任何新功能、fix 都必须从 main 分出，测试完毕后合并回主分支。

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

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

这里，其实你的 dev 分支其实就是 master dev_1.0 和 dev_1.1 就算 feature/1.0 feature/1.1我司的流程是 从 master checkout 出来 feature/1.0 feature/1.1 (不一定一定从 master checkout ，只要是 feature 包含 master 的代码即可)然后 feature/1.0 开发完成，如果他不依赖 feature/1.1 里面的功能，则测试完成上线就直接合并到 master 线上打包发布 master 然后 feature/1.1 merge master ，1.1 开发完成在 merge 到 master 打包上线

release 和 develop 分支，这样取名我感觉好一些

这难道不是最基本的产品质量管理流程？生产那边任何上线的东西都应该是只能出自 master 分枝，甚至会有一些组织单独做一个 release 分支提交生产上线。怎么能让开发人员自己就随随便便把 develop 乃至自己手头的东西提交给生产呢？