请教 git 管理的一个问题

[yujianwjj]

背景：一个代码仓库存在两个版本同时开发的场景，比如当前基于 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 上面继续开发并合并代码。

[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 打包上线

[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 管理问题不是流程问题，纯属能力不过关，软件工程知识不合格造成的混乱。

[admol]

@ray2023
得看是不是在开发同一个功能，如果明确是同一个功能要一起上线的，那可以共用一个 feature 分支。
如果不是或者不确定，最好是每个功能 feature 一个独立的 feature 分支。

这样上线的时候也可以很好的控制哪些功能可以上线（将 feature 分支合并到 release 分支），未测试完或者需要延期的也可以随时拿掉（不合并 release ）。
就算已经合并了 release 分支，其中某个功能不准备上线了，那也可以将之前的 release 分支删掉，然后重新合一个新的 release 分支。

所以最好是每个要上线的功能独立一个 feature 分支。

[ily433664]

发布到线上的包，肯定是要合到同一个分支

我们是这么用的
dev-xxx：开发中的版本，从 master 分支 checkout （开发各自操作）
dev：dev-xxx 分支完成后，统一合到 dev ，发布到开发环境（开发各自操作）
test：开发完成后将 dev-xxx 合到 test ，发布到测试环境（开发各自操作）
release：测试通过后将 dev-xxx 合到 release ，发布到生产环境（组长操作）
master：上线完成后，将 release 合到 master
bug-fix：线上 bug 在该分支修复，修复后按流程合到 dev 、test 、release 发布到各环境

[IAmSimon]

要不发生这种事情，要保证两点:
1. 上线前的代码都应该校验是否合并最新的 master
2. 上线后要及时合并代码到 master

为了做到这两点：
1. 公司需要一套比较完整的发布流程工具；
2. 没有的话，最好还是每次发版，除了发版的组员外，组长都要跟进，发布前发布后都要在

[GotKiCry]

用其他工单管理和 git 关联起来。定期 1 周或者 2 周合并指定工单需求。