背景：一个代码仓库存在两个版本同时开发的场景，比如当前基于 develop 分支，拉了两个分支 dev_1.0 和 dev_1.1 。现在 dev_1.0 的功能开发完成了，测试也测试了，现网上线了。但是 dev_1.0 的分支没有合并到 develop ，导致 dev_1.1 上线的时候的代码没有包含 dev_1.0 的代码。
一般研发写完代码之后，只要测试不反馈问题，他们也不会去管后续的流程。最开始是组内通知大家，要记得把代码合并到 develop 。但是一个项目有好几个开发人员，靠人去做这件事情确实要花时间，你要跟进这个项目的进度。所以单纯的靠研发去做这件事情，也确实不合理。
现在的问题是，缺一个流程去做这件事情：代码上线之后把代码合并到 develop ，这件事情由谁来做，怎么做？
请教一下大家的公司是怎么做类似的事情的？
第 1 条附言 · 23 天前
看了大家的意见，是发生产的时候要把代码合到 develop ，然后重新打包。我们这边是，测试测完之后，测试负责把他验证过的包推到生产环境。另外还有一个问题，发生产其实是先发灰度，比如现在基于 dev_1.0 打了包，发了灰度，然后有问题，还是会在 dev_1.0 上面继续开发并合并代码。
46 条回复 • 2024-10-17 05:39:47 +08:00
 |
1
sss15 23 天前
当然是组长了，发生产的时候就要合并分支了
|
|
2
sss15 23 天前  1
打包要从 develop 分支打包，不在 dev_1.1 上打包
|
 |
3
Str0Dytomh 23 天前
组员提合并请求合并到 dev,上线用 dev 的代码
|
 |
4
ljtfdt 23 天前
dev_1.0 开发完成之后要合并到 develop 分支上，然后从 develop 分支发布上线
|
 |
5
huijiewei 23 天前 4
为啥要起 dev 1.0 1.1 这种混淆的名字呢
dev main 这是雷打不动的 2 个分支 其他起名一律就叫 feature 或者 fix ，这种分支是不允许打包上线的。只能合并到上游 |
 |
6
BeforeTooLate 23 天前
生产代码不在 develop 分支，直接 dev_1.0 就可以发布上线？
|
 |
7
j1132888093 23 天前
上线分支一定是一条固定的分支
比如基于 main 拉出了两条开发分支，测试的时候可以各个环境用各个功能的开发分支，上线的时候一定是先合并到 main 分支，然后用 main 分支上线 |
 |
8
xiaogu2014 23 天前
```测试也测试了，现网上线了。但是 dev_1.0 的分支没有合并到 develop ```
不允许非生产分支的代码部署到 prod 。 cicd 的流程不明确。 |
 |
9
Ayanokouji 23 天前
这题不会，就从分支名和基于 develop 分支开发，管理就够乱的。
我们 master 和 feature 分支管理，参考 workflow 。 |
|
10
Ayanokouji 23 天前
@Ayanokouji #9 打错了，gitflow 模型
|
 |
11
AFlash 23 天前
首先，一个版本先确定要更新的功能列表，然后，根据功能建分支开发，如果模块间相对独立，可以在测试环境分别部署测试，如果存在前后依赖就需要都完成再测试。在上线前，需要将所有的功能合并到主分支，然后做回归验证，确定符合预期再上线。
|
 |
12
csys 23 天前
所有的代码改动，无论是新功能开发，还是线上 bug 修复，都先进主干分支，再进发布分支
|
 |
13
dylanqqt 23 天前
dev_1.0 是基于 dev 拉下来的，你最后上线应该合并到 dev 上去，上线 dev 的代码
|
 |
15
mark2025 23 天前
要么人工来操作合并。要么使用 gitlab ，github 走 issue+ MR/PR 流程（半自动合并）
|
 |
16
sagaxu 23 天前
基于 develop 开发新功能分支 dev_1.0/ dev_1.1...，然后 dev_*上线了，那自然应该把 dev_*合并回 develop ，谁开发谁负责合并回去，因为如果此时有冲突，只有负责这个新分支的人能处理。
|
|
17
mark2025 23 天前
如果不是多版本并发模式，而是单版本滚动模式，那就规定上线代码必须从 main 主分支拉出。任何新功能、fix 都必须从 main 分出，测试完毕后合并回主分支。
|
 |
18
bzw875 23 天前
测试验证通过了合并到 master / main 分支，develop 发生产不对经吧。 你看看 git 的 workflow 。分支规范是 feat-, bugfix
|
 |
19
vaynecv 23 天前
组长来操作合并，merge 代码到 develop ，我在公司就是做这个事情的。人工操作起来确实挺繁琐的，但是不会出什么大问题，这个人需要熟悉系统工程，有冲突了也可以解决；也尝试过给开发人员各自操作，但是会出现问题，或者难以管理
|
 |
20
deplives 23 天前
这里，其实你的 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 打包上线 |
 |
21
maokg 23 天前
release 和 develop 分支，这样取名我感觉好一些
|
 |
22
dalaoshu25 23 天前
这难道不是最基本的产品质量管理流程？生产那边任何上线的东西都应该是只能出自 master 分枝，甚至会有一些组织单独做一个 release 分支提交生产上线。怎么能让开发人员自己就随随便便把 develop 乃至自己手头的东西提交给生产呢？
|
 |
23
wangyzj 23 天前
你的开发流程问题还挺多的
如果功能拆分的好，那么少一个分支不影响业务，就是缺功能，但为什么没 merge ，leader ，测试和产品都有锅 站会，周会，双周会都没发现吗？ 如果拆分的不好，那么就会有 bug ，测试不过，那就没法上线 应该需要一个工具把迭代管理起来，feature 和 code 做个关联 |
 |
24
yhnbgfd 23 天前
dev_1.0 开发 - dev_1.0 测试 - 合并到 develop - develop 测试(期间可能还有其他 bug 或功能已经合并在 develop 了) - 打包发版
或者 dev_1.0 开发 - 同步 develop - dev_1.0 测试 - 合并到 develop - 打包发版 |
 |
25
nekochyan 23 天前
我们 QA 都是固定在 master 上测试并上线，上线前都会通知大家自己把功能合并到 dev ，然后组长统一合并到 master ，所以不存在你说的 dev_1.0 功能上线了还没有合并到 dev 的问题；而且第一次见直接用 dev_1.0 上线的
|
 |
26
oliveira 23 天前
你们公司的开发流程混乱到我都不知道怎么吐槽。
理论上正常的分支命名： release 分支：发布分支，用于打包，发布上线； dev_x 分支：开发分支，用于开发； 理论上正常的开发流程： 1. 基于 release 分支新建 dev_x 分支； 2. 开发完成后建立 Merge Request 将 dev_x 分支代码合并到 release 分支； 3. 等所有开发分支合并完成后，用 release 分支打包上线。 |
 |
27
reoah2 23 天前
为什么 dev1.0 能直接上线？不应该合到 dev 里头再发吗？ dev2.0 发之前再去合 dev 就行了
|
 |
28
msg7086 23 天前
我司是这样的。
所有要在这个版本发布的 PR 全部合到 master 上，下个版本发布的 PR 全部禁止合并。 版本冻结以后 fork 出 release 分支，所有的 hotfix 都先合到 master 然后 cherrypick 到 release 分支，这步 cherrypick 需要上级领导审批。 fork 出 release 分支以后，之前禁止合并的 PR 就可以全部合并进 master 了。 |
 |
29
admol 23 天前 4
### 基本概念
- 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 分支流程类似，不重复说明。 这是我们的分支流程管理，仅供参考 |
 |
30
wu00 23 天前
gitflow
githubflow gitlabflow 三选一 |
 |
31
lizy0329 23 天前
看懂了，他部署代码是用 FTP 的
|
 |
32
zjsxwc 23 天前
看似是 git 分支问题，
其实人的管理问题， 各自为战 的结果。 |
 |
33
ruandao 23 天前
偶然性事件具体处理
重复性事情，流程化自动处理 不管由谁来做都是错的，因为换了团队这个问题是否还会再犯 你需要思考下个项目会不会出现同样的问题，要怎样避免问题一而再再而三的发生，然后你会去思考怎么自动化去规避这个问题 |
 |
34
felbryiozzzz 23 天前
我们小组的管理方式，https://blog-8xn.pages.dev/team-management/git.html ，写的比较啰嗦，但是实际执行起来很简单
|
 |
35
renmu 23 天前 via Android
研发不来合并冲突了谁解决？
|
 |
36
quicksandznzn 23 天前
上线提个 pr merge 到 main 在发
|
|
37
ruandao 23 天前
你可以试试找研发负责人、测试负责人，或者运维负责人去推动，一般来说小组长不一定能够推得动自动化
|
 |
38
KKKKKKKKKKKKKKKK 23 天前
 ，看看 gitflow 的流程吧 |
 |
39
ray2023 23 天前
@admol 很详细的流程, 还有个疑问想确认下, 就是多个组员在 feature-xx 分支开发的时候, 是每个人 check-out 新的分支, 比如 feature-xx-张三,feature-xx-李四, 还是说都在 feature-xx 分支开发
|
 |
40
Cu635 23 天前
等等，版本 1.0 和 1.1 是为啥会分叉出来，2 个并行开发的？
不应该是 1.0 一个 tag （ milestone ），之后在 1.1 一个 tag 么？ 2 个 tag 都在 develop 分支上的。 这不是 git 管理问题不是流程问题，纯属能力不过关，软件工程知识不合格造成的混乱。 |
|
41
admol 23 天前
@ray2023
得看是不是在开发同一个功能，如果明确是同一个功能要一起上线的，那可以共用一个 feature 分支。 如果不是或者不确定，最好是每个功能 feature 一个独立的 feature 分支。 这样上线的时候也可以很好的控制哪些功能可以上线（将 feature 分支合并到 release 分支），未测试完或者需要延期的也可以随时拿掉（不合并 release ）。 就算已经合并了 release 分支，其中某个功能不准备上线了，那也可以将之前的 release 分支删掉，然后重新合一个新的 release 分支。 所以最好是每个要上线的功能独立一个 feature 分支。 |
 |
42
ily433664 23 天前 1
发布到线上的包，肯定是要合到同一个分支
我们是这么用的 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 发布到各环境 |
 |
43
IAmSimon 23 天前
要不发生这种事情，要保证两点:
1. 上线前的代码都应该校验是否合并最新的 master 2. 上线后要及时合并代码到 master 为了做到这两点： 1. 公司需要一套比较完整的发布流程工具； 2. 没有的话，最好还是每次发版，除了发版的组员外，组长都要跟进，发布前发布后都要在 |
 |
44
GotKiCry 23 天前
用其他工单管理和 git 关联起来。定期 1 周或者 2 周合并指定工单需求。
|
 |
45
Jtyczc 22 天前
还能说什么，找下家吧，这公司迟早炸
|
 |
46
xuanbg 22 天前
1 、dev_1.0 合并回 develop
2 、将 develop 合并到未完成的 dev_1.1 ，或者 dev_1.1 变基到 develop ，使得 dev_1.1 包含最新的代码 |
Select Language