请教 git 管理的一个问题

[yujianwjj]

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

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

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

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

[maokg]

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

[dalaoshu25]

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

[wangyzj]

你的开发流程问题还挺多的
如果功能拆分的好，那么少一个分支不影响业务，就是缺功能，但为什么没 merge ，leader ，测试和产品都有锅
站会，周会，双周会都没发现吗？
如果拆分的不好，那么就会有 bug ，测试不过，那就没法上线
应该需要一个工具把迭代管理起来，feature 和 code 做个关联

[yhnbgfd]

dev_1.0 开发 - dev_1.0 测试 - 合并到 develop - develop 测试(期间可能还有其他 bug 或功能已经合并在 develop 了) - 打包发版
或者
dev_1.0 开发 - 同步 develop - dev_1.0 测试 - 合并到 develop - 打包发版

[nekochyan]

我们 QA 都是固定在 master 上测试并上线，上线前都会通知大家自己把功能合并到 dev ，然后组长统一合并到 master ，所以不存在你说的 dev_1.0 功能上线了还没有合并到 dev 的问题；而且第一次见直接用 dev_1.0 上线的

[oliveira]

你们公司的开发流程混乱到我都不知道怎么吐槽。
理论上正常的分支命名：
release 分支：发布分支，用于打包，发布上线；
dev_x 分支：开发分支，用于开发；
理论上正常的开发流程：
1. 基于 release 分支新建 dev_x 分支；
2. 开发完成后建立 Merge Request 将 dev_x 分支代码合并到 release 分支；
3. 等所有开发分支合并完成后，用 release 分支打包上线。

[reoah2]

为什么 dev1.0 能直接上线？不应该合到 dev 里头再发吗？ dev2.0 发之前再去合 dev 就行了

[msg7086]

我司是这样的。
所有要在这个版本发布的 PR 全部合到 master 上，下个版本发布的 PR 全部禁止合并。
版本冻结以后 fork 出 release 分支，所有的 hotfix 都先合到 master 然后 cherrypick 到 release 分支，这步 cherrypick 需要上级领导审批。
fork 出 release 分支以后，之前禁止合并的 PR 就可以全部合并进 master 了。

[admol]

### 基本概念

- master：线上理论上最稳定的代码版本，不允许直接修改提交代码。
- release 分支：上线前预发布环境分支，不允许直接修改提交代码，上线完成验收通过后合并到 master 分支，打 tag 。
- dev 分支：开发环境分支，不允许直接修改提交代码。
- test 分支：测试环境分支，不允许直接修改提交代码。
- feature 分支：基于 master 分支 checkout 的分支，用于开发新的功能需求。允许直接修改提交代码。开发完成后合并到 dev 分支，提测时合并到 test 分支，上线前合并到 release 分支。
- hotfix 分支：基于 master 分 支创建，对线上版本的 bug 进行修复，流程和 feature 开发类似。

### 开发流程说明：

1. 收到需求，基于 `master` 分支 checkout 新的 feature 分支：`feature/00001`
2. 开发阶段：
1. 开发完成后，将 `feature/00001`分支合并到 `dev` 分支。
2. 发布开发环境 `dev` 分支。
3. 提测阶段：
1. 提测时，将 `feature/00001`分支合并到 `test` 分支。
2. 提测后测试反馈的 bug ，继续基于`feature/00001`分支进行修改，修改完成后再次将分支合并到 `dev` 分支和 `test` 分支。
3. 发布测试环境 `test` 分支
4. 预发布阶段：
1. 基于 master checkout 新的 release 分支：`release-xxx`
2. 确定要上线的功能版本，将对应的 feature 分支：`feature/00001`合并到 `release-xxx` 分支
3. 提测后测试反馈的 bug ，继续基于`feature/00001`分支进行修改，修改完成后再次将分支合并到 `dev` 、 `test` 和 `release-xxx` 分支。
4. 发布预发布环境`release-xxx`分支
5. 上线发布阶段：
1. 上线发布`release-xxx`分支
2. 验收通过，将 `release-xxx` 分支合并到 `master` 分支，打上版本 tag 。
3. 删除`release-xxx`、`feature/00001`分支

hotfix 流程和 feature 分支流程类似，不重复说明。



这是我们的分支流程管理，仅供参考

[wu00]

gitflow
githubflow
gitlabflow
三选一

[lizy0329]

看懂了，他部署代码是用 FTP 的

[zjsxwc]

看似是 git 分支问题，
其实人的管理问题，
各自为战 的结果。

[ruandao]

偶然性事件具体处理
重复性事情，流程化自动处理

不管由谁来做都是错的，因为换了团队这个问题是否还会再犯
你需要思考下个项目会不会出现同样的问题，要怎样避免问题一而再再而三的发生，然后你会去思考怎么自动化去规避这个问题

[felbryiozzzz]

我们小组的管理方式，https://blog-8xn.pages.dev/team-management/git.html ，写的比较啰嗦，但是实际执行起来很简单

[renmu]

研发不来合并冲突了谁解决？

[quicksandznzn]

上线提个 pr merge 到 main 在发

[ruandao]

你可以试试找研发负责人、测试负责人，或者运维负责人去推动，一般来说小组长不一定能够推得动自动化

[KKKKKKKKKKKKKKKK]

，看看 gitflow 的流程吧

[ray2023]

@admol 很详细的流程, 还有个疑问想确认下, 就是多个组员在 feature-xx 分支开发的时候, 是每个人 check-out 新的分支, 比如 feature-xx-张三,feature-xx-李四, 还是说都在 feature-xx 分支开发

[Cu635]

等等，版本 1.0 和 1.1 是为啥会分叉出来，2 个并行开发的？

不应该是 1.0 一个 tag （ milestone ），之后在 1.1 一个 tag 么？ 2 个 tag 都在 develop 分支上的。

这不是 git 管理问题不是流程问题，纯属能力不过关，软件工程知识不合格造成的混乱。