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

[firhome]

生产环境--> 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，应该是这样才对吧？

感谢各位的回复，可能我没把我们现在的状态说清楚。。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，这样理解对吗？

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

[qq73666]

git flow 了解下

[MrUser]

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

[LiuJiang]

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

[hosaos]

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

[nicevar]

不就是 cherry-pick 的问题

[lincleejun]

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

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

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

[ferock]

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


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

[Woodywuuu]

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

[otakustay]

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

[menyakun]

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

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

[momocraft]

revert

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

[msg7086]

重做 test 分支。

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

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

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

[iConsLii]

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

[WubWoofWolf]

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

[zqx]

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

[asuraa]

推荐 git flow
这个玩意很好用

[enenaaa]

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

[xiaoyaojc]

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

[firhome]

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

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

[ferock]

@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]

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

[firhome]

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

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

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

[ferock]

@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]

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