请教一个 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，应该是这样才对吧？

[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 这样的代码永远都是会最后上生产了，测试才有机会测试这样的最终打死不修改版。