1
qq73666 2019-08-08 09:48:02 +08:00 1
git flow 了解下
|
2
MrUser 2019-08-08 09:51:11 +08:00 1
你需要 git flow 中的 release 分支,线上 bug 的分支名叫 hotfix,git flow 确实很适合你们
|
3
LiuJiang 2019-08-08 09:53:43 +08:00 1
git flow 就好了
release 测试分支和预发布分支 master 主分支 feature 功能开发分支 hotfix 热修复分支 |
4
hosaos 2019-08-08 09:57:15 +08:00 1
我们的做法是 多个开发分支 branch-a ,branch-b 合并到一个分支提测,某个分支的功能测试通过后单独发布然后合并到 master,bug 实在自己的开发分支修改然后合并到 test 测试
|
5
nicevar 2019-08-08 10:14:53 +08:00 1
不就是 cherry-pick 的问题
|
6
lincleejun 2019-08-08 10:42:41 +08:00 1
一方面是 git flow 解决你分支管理的问题
另外一方面你提到的是开发完毕后合并到 test 分支, 实际是不是该增加功能测试和集成测试?具体某个分支的功能测试完毕后才能进测试分支,测试分支做集成、回归。 针对问题,这个问题由于是合并到 test 的, 用 git revert 指定的 merge 节点就好了啊 |
7
ferock 2019-08-08 10:46:14 +08:00 1
已经合进 test,突然某个 branch 在 test 环境测试不通过,或者不上线。 请问这个时候怎么办呢?
比如:branch-a , branch-b ,branch-c 依次合进 test, 其中 branch-b 暂时不要了。 这种模式下,无解。 只能通过代码屏蔽掉对应的功能,因为 branch-b 代码已经在 test 里了,剥离出来又需要重新测试一遍,如果这时候 test 分支已经往前走了很远了,那更无法剥离。 |
8
Woodywuuu 2019-08-08 10:56:53 +08:00 1
小团队短流程建议用 TBD,之前强推 git flow,上手成本和操作成本都略高,选择最适合的,不要被技术绑架。
现在是用 TBD+pr 的方式,运行良好。 |
9
otakustay 2019-08-08 11:05:14 +08:00 1
git flow 根本不解决“分支需要合在一起才能完整测试”的场景,和楼主的需求对不上啊
这事情如果分支不能单独测,必须合入后做集成测试,那上不了线就只能 revert 掉了,没啥办法 |
10
menyakun 2019-08-08 12:06:11 +08:00 1
branch-b 不要了之后,之后的 commit 还要保留?
git rebase, 然后 drop 掉 branch-b 的 commit,不过这样的话,集成测试就要重做了 |
11
momocraft 2019-08-08 12:11:37 +08:00 1
revert
听你描述更像是代码结构或管理问题,都不是 git 能解决 |
12
msg7086 2019-08-08 12:51:59 +08:00 1
重做 test 分支。
与其说是把 a b c 合并到 test 去测试,不如说新建一个 test-abc 去测试 abc 三个分支。如果 b 不要了,那无非就是重建一个 test-ac 去重测 ac 功能而已。 Git 底下,分支只是一个会动的书签( Tag 则是一个不太会动的书签),不要去想着一个分支就是一个分支。分支可以随时随地新建,随时随地删除的。 如果 test-abc 分支上有额外的改动提交,那么重做 test-ac 分支以后再把提交给 Rebase/Cherry Pick 过去就行了。 |
13
iConsLii 2019-08-08 12:58:31 +08:00 via Android 1
不能从 test 上拉新的功能分支把,我们都是从 master 上新拉分支
|
14
WubWoofWolf 2019-08-08 14:26:47 +08:00 1
git flow 虽然繁琐,但长期迭代还是比较清晰的
|
15
zqx 2019-08-08 14:48:03 +08:00 via Android 1
test 分支是什么?难道你们的代码还区分测试和生产吗?我的意思是,只有环境才区分测试和生产吧?代码也要测试一套,生产一套?
|
16
asuraa 2019-08-08 14:51:02 +08:00 1
推荐 git flow
这个玩意很好用 |
17
enenaaa 2019-08-08 15:05:14 +08:00 1
branch 合并到 test 之后,branch 就不再继续使用了。 新 bug 在 test 上修复。
|
18
xiaoyaojc 2019-08-08 15:11:20 +08:00
每次开发从 master 拉分支 branch a,然后都在 a 分支上开发,联调发到 dev 分支,提测合到 test 分支,如果上线,a 合到 master。
|
19
firhome OP |
20
ferock 2019-08-09 10:41:39 +08:00 1
@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 这样的代码永远都是会最后上生产了,测试才有机会测试这样的最终打死不修改版。 |
21
msg7086 2019-08-09 10:49:34 +08:00
(说句实话,我觉得有些东西真的没办法只靠文字表述,最好是面对面教……这是我教人 Git 到现在最大的感受了。)
|
22
firhome OP @ferock 非常感谢回复,你说的我理解了。但是还有两个问题需要帮忙解答一下。
1. 合到 develop 分支后,出行 bug 是在哪个分支呢?直接 develop 分支 还是 feature 分支,又或者 拉个 release 出来改? 2. 因为测试域名对应了 develop 分支的内容,那拉出来的 release 分支做回归测试的话,是不是还得部署一个该 release 分支的域名来让测试测?(因为测试同学机器上没有安装开发环境) |
23
ferock 2019-08-09 13:02:39 +08:00
@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 ?毫无意义啊。 但还是那句话,国内公司基本没法按照这个流程来。 |