请教 git 管理的一个问题

[yujianwjj]

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

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

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

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

[sss15]

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

[sss15]

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

[Str0Dytomh]

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

[ljtfdt]

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

[huijiewei]

为啥要起 dev 1.0 1.1 这种混淆的名字呢

dev
main
这是雷打不动的 2 个分支

其他起名一律就叫 feature 或者 fix ，这种分支是不允许打包上线的。只能合并到上游

[BeforeTooLate]

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

[j1132888093]

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

[xiaogu2014]

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

[Ayanokouji]

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

[Ayanokouji]

@Ayanokouji #9 打错了，gitflow 模型

[AFlash]

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

[csys]

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

[dylanqqt]

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

[AFlash]

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

[mark2025]

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

[sagaxu]

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

[mark2025]

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

[bzw875]

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

[vaynecv]

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

[deplives]

这里，其实你的 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 打包上线