请教一个 git 分支管理的问题。

请不要在回答技术问题时复制粘贴 AI 生成的内容

This topic created in 2475 days ago, the information mentioned may be changed or developed.

生产环境--> master

测试环境--> test

现在我们每次开发都是从 test 上拉分支 branch-a, branch-b, branch-c .....

开发完毕以后合到 test 分支一次迭代可能有多个 branch。

[然后测试若有 bug 就直接在 test 环境更改了]

测试完毕 test 合进 master。

现在的问题是，已经合进 test，突然某个 branch 在 test 环境测试不通过，或者不上线。请问这个时候怎么办呢？

比如：branch-a , branch-b ,branch-c 依次合进 test，其中 branch-b 暂时不要了。

另外，合进 test 的分支若要改 bug，应该还是在原来分支改，改完再合进 test，应该是这样才对吧？

Supplement 1 Aug 9, 2019

感谢各位的回复，可能我没把我们现在的状态说清楚。。git flow 我昨天也看了一下。

有点不理解抽象出来的 release 分支的作用。。

我们现在的分支

master ---> 对应 www.abc.com
（发布的时候服务器上的 git，通过 ci 脚本自动拉取 master 分支内容编译，Nginx 映射到 dist 目录）

test ---> 对应 test.abc.com
（发布的时候服务器上的 git，通过 ci 脚本自动拉取 test 分支内容编译，Nginx 映射到 dist 目录）

branch --> 开发本地 local.abc.com （本地 web 服务）

现在的问题是 branch 开发完成以后，需要测试同学看，但是测试同学不可能自己安装一套开发环境，所以我们需要把 branch 合到 test 上进行发布，这样测试才能看。测试测完成之后，把 test 合到 master 上发布。

所以就导致了某阶段很多 branch 在 test 上。然后 [要发布就得一起发布] 这种问题

--------------------------------------------------

昨天看了那个 git flow 的工作流以后，我是不是认为是这样？

branch 合到 test，然后 test 拉出 release 来进行 bug 修复。这个时候测试环境 test.abc.com 应该对应的是这个 release 分支？

release 通过之后，分别合到 test 和 master，这样理解对吗？

我真正要改的是让测试同学正确浏览某个分支的问题把？

test

分支

branch-b

branch-c

24 replies 2020-12-16 09:44:27 +08:00

qq73666

Aug 8, 2019

git flow 了解下

MrUser

Aug 8, 2019

你需要 git flow 中的 release 分支，线上 bug 的分支名叫 hotfix，git flow 确实很适合你们

jchencode

Aug 8, 2019

git flow 就好了
release 测试分支和预发布分支
master 主分支
feature 功能开发分支
hotfix 热修复分支

hosaos

Aug 8, 2019

我们的做法是多个开发分支 branch-a ,branch-b 合并到一个分支提测，某个分支的功能测试通过后单独发布然后合并到 master，bug 实在自己的开发分支修改然后合并到 test 测试

nicevar

Aug 8, 2019

不就是 cherry-pick 的问题

lincleejun

Aug 8, 2019

一方面是 git flow 解决你分支管理的问题

另外一方面你提到的是开发完毕后合并到 test 分支，实际是不是该增加功能测试和集成测试？具体某个分支的功能测试完毕后才能进测试分支，测试分支做集成、回归。

针对问题，这个问题由于是合并到 test 的，用 git revert 指定的 merge 节点就好了啊

ferock

PRO

Aug 8, 2019

已经合进 test，突然某个 branch 在 test 环境测试不通过，或者不上线。请问这个时候怎么办呢？
比如：branch-a , branch-b ,branch-c 依次合进 test，其中 branch-b 暂时不要了。

这种模式下，无解。
只能通过代码屏蔽掉对应的功能，因为 branch-b 代码已经在 test 里了，剥离出来又需要重新测试一遍，如果这时候 test 分支已经往前走了很远了，那更无法剥离。

Woodywuuu

Aug 8, 2019

小团队短流程建议用 TBD，之前强推 git flow，上手成本和操作成本都略高，选择最适合的，不要被技术绑架。
现在是用 TBD+pr 的方式，运行良好。

otakustay

Aug 8, 2019

git flow 根本不解决“分支需要合在一起才能完整测试”的场景，和楼主的需求对不上啊
这事情如果分支不能单独测，必须合入后做集成测试，那上不了线就只能 revert 掉了，没啥办法

menyakun

Aug 8, 2019

branch-b 不要了之后，之后的 commit 还要保留？

git rebase, 然后 drop 掉 branch-b 的 commit，不过这样的话，集成测试就要重做了

momocraft

Aug 8, 2019

revert

听你描述更像是代码结构或管理问题，都不是 git 能解决

msg7086

Aug 8, 2019

重做 test 分支。

与其说是把 a b c 合并到 test 去测试，不如说新建一个 test-abc 去测试 abc 三个分支。如果 b 不要了，那无非就是重建一个 test-ac 去重测 ac 功能而已。

Git 底下，分支只是一个会动的书签（ Tag 则是一个不太会动的书签），不要去想着一个分支就是一个分支。分支可以随时随地新建，随时随地删除的。

如果 test-abc 分支上有额外的改动提交，那么重做 test-ac 分支以后再把提交给 Rebase/Cherry Pick 过去就行了。

iConsLii

Aug 8, 2019 via Android

不能从 test 上拉新的功能分支把，我们都是从 master 上新拉分支

WubWoofWolf

Aug 8, 2019

git flow 虽然繁琐，但长期迭代还是比较清晰的

zqx

Aug 8, 2019 via Android

test 分支是什么？难道你们的代码还区分测试和生产吗？我的意思是，只有环境才区分测试和生产吧？代码也要测试一套，生产一套？

asuraa

Aug 8, 2019

推荐 git flow
这个玩意很好用

enenaaa

Aug 8, 2019

branch 合并到 test 之后，branch 就不再继续使用了。新 bug 在 test 上修复。

xiaoyaojc

Aug 8, 2019

每次开发从 master 拉分支 branch a，然后都在 a 分支上开发，联调发到 dev 分支，提测合到 test 分支，如果上线，a 合到 master。

firhome

Aug 9, 2019

@qq73666
@MrUser
@LiuJiang
@hosaos
@nicevar
@lincleejun
@ferock
@Woodywuuu
@otakustay
@menyakun
@momocraft
@msg7086
@iConsLii
@WubWoofWolf
@zqx
@luodaoyi
@enenaaa
@xiaoyaojc

感谢各位的回复，我补充了内容。大家看看我理解有问题吗？

ferock

PRO

Aug 9, 2019

@firhome #19

看了一下你的问题，给 2 点建议

1. 一般不叫 test 分支，而是叫 develop 分支，其实并不是纠结名字，而是，这个分支上的功能实现，就是所谓的 [开发版]
2. 其实都是要测 3 次的，不管是功能第一次合并到在 develop ( test ) 上，还是最后拉出的 release 上。
- 第一次测试，代码自测无问题，feature 分支。
- 第二次测试，合并到 develop 分支，和其他功能一起测试。
- 第三次测试，拉出的 release 分支，可能会在 develop 分支上截取某个时间点，作为 release，上面 A 功能满足，B 功能可能没有。需要最后回归测试一下。

终告：国内公司不会遵循这种流程，因为太多的项目做了一半要砍掉。所以，从 git-flow 的流程上来说，无解！
但，实际操作中，他们最后会选择：
A 功能自己测。
B 功能自己测。
C 功能自己测。

生产上最后的情况，A 发布，B 不发布，C 发布，怎么办？
大家都上生产，出问题了就是事故，不出问题，下班回家。A+C-B 这样的代码永远都是会最后上生产了，测试才有机会测试这样的最终打死不修改版。

msg7086

Aug 9, 2019

（说句实话，我觉得有些东西真的没办法只靠文字表述，最好是面对面教……这是我教人 Git 到现在最大的感受了。）

firhome

Aug 9, 2019

@ferock 非常感谢回复，你说的我理解了。但是还有两个问题需要帮忙解答一下。

1. 合到 develop 分支后，出行 bug 是在哪个分支呢？直接 develop 分支还是 feature 分支，又或者拉个 release 出来改？

2. 因为测试域名对应了 develop 分支的内容，那拉出来的 release 分支做回归测试的话，是不是还得部署一个该 release 分支的域名来让测试测？（因为测试同学机器上没有安装开发环境）

ferock

PRO

Aug 9, 2019

@firhome #22

1. 按照 git-flow 流程 hotfix 是从 master 拉取的。完成发布后合并到 develop 和 master 内。

解释一下版本号
x.y.z

x = 大版本号，上一版本和下一版本并不兼容
y = 小版本号，上一版本和下一版本理应考虑兼容
z = hotfix 号，解决各种 bug 问题。

2. 按照你说的情况，是的！但按照 git-flow 规范，某个时间只应存在一个 release 版本。
比如当前是 1.1 的 release，你还在测 1.2 的 release ？毫无意义啊。

但还是那句话，国内公司基本没法按照这个流程来。

simonlu9

Dec 16, 2020

@firhome 我也遇到这个问题，想问下最后是怎么解决的。