这是一个创建于 2254 天前的主题，其中的信息可能已经有所发展或是发生改变。
生产环境--> 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，应该是这样才对吧？
测试环境--> 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，应该是这样才对吧？
第 1 条附言 2019-08-09 10:03:51 +08:00
感谢各位的回复，可能我没把我们现在的状态说清楚。。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，这样理解对吗？
我真正要改的是 让测试同学 正确浏览某个分支的 问题把？
有点不理解抽象出来的 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，这样理解对吗？
我真正要改的是 让测试同学 正确浏览某个分支的 问题把？
 | 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 PRO 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 PRO 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 PRO @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 ？毫无意义啊。 但还是那句话，国内公司基本没法按照这个流程来。 |
Select Language