请教 git 管理的一个问题

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

› Pro Git

› Atlassian Git Tutorial

› Pro Git 简体中文翻译

› GitX

这是一个创建于 71 天前的主题，其中的信息可能已经有所发展或是发生改变。

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

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

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

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

第 1 条附言 · 71 天前

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

46 条回复 • 2024-10-17 05:39:47 +08:00

sss15

71 天前

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

sss15

71 天前

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

Str0Dytomh

71 天前

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

ljtfdt

71 天前

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

huijiewei

71 天前

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

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

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

BeforeTooLate

71 天前

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

j1132888093

71 天前

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

xiaogu2014

71 天前

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

Ayanokouji

71 天前

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

Ayanokouji

71 天前

@Ayanokouji #9 打错了，gitflow 模型

AFlash

71 天前

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

csys

71 天前

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

dylanqqt

71 天前

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

AFlash

71 天前

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

mark2025

71 天前

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

sagaxu

71 天前

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

mark2025

71 天前

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

bzw875

71 天前

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

vaynecv

71 天前

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

deplives

71 天前

这里，其实你的 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

71 天前

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

dalaoshu25

71 天前

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

wangyzj

71 天前

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

yhnbgfd

71 天前

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

nekochyan

71 天前

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

oliveira

71 天前

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

reoah2

71 天前

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

msg7086

71 天前

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

admol

71 天前

### 基本概念

- 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

71 天前

gitflow
githubflow
gitlabflow
三选一

lizy0329

71 天前

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

zjsxwc

71 天前

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

ruandao

71 天前

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

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

felbryiozzzz

71 天前

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

renmu

71 天前 via Android

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

quicksandznzn

71 天前

上线提个 pr merge 到 main 在发

ruandao

71 天前

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

KKKKKKKKKKKKKKKK

71 天前

，看看 gitflow 的流程吧

ray2023

71 天前

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

Cu635

70 天前

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

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

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

admol

70 天前

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

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

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

ily433664

70 天前

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

我们是这么用的
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

70 天前

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

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

GotKiCry

70 天前

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

Jtyczc

70 天前

还能说什么，找下家吧，这公司迟早炸

xuanbg

70 天前

1 、dev_1.0 合并回 develop
2 、将 develop 合并到未完成的 dev_1.1 ，或者 dev_1.1 变基到 develop ，使得 dev_1.1 包含最新的代码