请教大家有关 git 工作流的问题

最好就是各个分支分别对应独立的测试环境啊，如果条件限制只有一个环境，那就只能 merge 到一个分支上测试，不同分支上代码之间可能存在的逻辑冲突你只能容忍, 这不是技术问题，这是个基本的逻辑问题吧

听上去并不是 git 流程的问题。试着让前端可以通过修改配置文件等手段监听不同的端口吗？这样就不需要覆盖了。
如果 ABC 三个需求会造成 conflict, 合并到测试分支时解决 conflict 还是合并到 master 解决 conflict，conflict 始终存在。如果需求之间没有什么关系，那肯定是分别做 3 个 PR 来做 master merge 会更清晰点。

@lululau 先不考虑逻辑冲突的问题，如果合并到一个分支测试，怎么上线呢。B 需求要上线了，A 还没测完。这时候得手动摘出来到上线分支吧，那么之前的版本就丢失了啊，而且手动摘如果需求大而复杂的话不保证出错？

个人观点：测试可以直接使用各个需求分支进行测试，当需求测试通过后，统一合并到唯一的测试分支

@monkeylyf 如果前端只是改配置文件的话，只有一个环境，还是测试只能同时测 1 个需求。现在是多个测试同时分别测 ABC 三个需求，那么就要多个前端环境了。来回部署环境费时费力，感觉不是正道

而且上面说了，3 个 PR，前提是这 3 个 PR 都给测试同时测，那么怎么独立环境，又绕回去了

@gy0624ww 似乎你已经知道答案了。

@taogen 前后端分离的，单独部署的，前端就一套对应后端多个分支，也只是同一时间测一个需求啊
那只能前端也版本控制，后端也版本控制。但是测试服务器就 1 台，测试 A 测试切 A 分支，测试同学 B 就测不了了

@monkeylyf 不知道啊。。。

我觉得这个是普遍存在的问题，就像知道各位是怎么处理，我借鉴下

@gy0624ww 多个测试要同时测试多个需求，那只能前后端每个需求各部署一套（不同端口）。一台测试服务器支撑不了多套应用部署，就加服务器。

把这三个相关的需求分给一个开发呗，反正不是不能同时上线吗，这样就避免冲突了，这个开发根据上线的优先级顺序进行开发。
另外，没有本地测试通过的代码不能提交这个基本约定可以保证程序正常运行。

@tealover007 开发肯定自测才提交的，但是有些特殊的边界情况还得测试来测啊。 就一个项目分给一个人不现实啊，其他人干啥去。。

@taogen 那一个需求就一台测试服务器也不现实啊

你这个问题啊，充钱就能解决

使用 docker 部署，a,b,c 需求分别对应不同的端口，行不行

有时候有些难缠的问题还是得靠人来解决，要么需求合并，要么测试排序， 搞在一起只会更乱。

如 1 楼所说 确实逻辑问题 事情要有先后

要让测试环境部署不麻烦（容器化），这样无论是同时只有一个环境（内部说一下，一个测好了就切到另一个，测完在切下面一个或切回去）还是多个环境都不麻烦。

典型的瞎理解 敏捷开发造成的版本控制 问题.

楼主你自己画一个版本控制图，类似这样的 http://img.mukewang.com/55768d5e00016c4b12400430.png

你看看你画的出来么。按照你的逻辑从 Master 分出来的，还要随时测，全挤一个点上去了，工程性上行不通。

哪怕是敏捷开发也不能这么瞎搞

当然你要强行瞎搞也行，一台服务器安装 crtix xenserver 虚拟机，虚拟出几台前端，你们瞎开发，测试瞎部署同时跟着瞎测。

然后如果是三个开发做三个版本对应一个测试就是群殴，怎么个群殴法呢。

办公室是不停的叫唤（甲，测试快测我的。乙，测试你测我的不要理甲 。丙，测试这包华子拿去，你先测我的别理那二个傻 x)

你要知道在软件工程里，不能这么干的。

你自己后面的回复已经把答案说守了。

至于某个教你用 Docker 解决的，或者后面叫你用 K8s 的，建议你加入特别关注好好看看他们平时是干什么活的。需求和工程都不理解 瞎扯

@594duck 可是需求场景就是这样的啊，现实情况哪允许你一个一个开发。你的意思是需求 A 测完先上线的，把代码再合到 master 和其他测试分支，是么。

@594duck 我现在就是想知道有没有这种情况的最佳实践，根据大家的经验，权衡各种因素，就这么做最合理

话说我们这里是有 develop, release, master 三个大分支，后端每一个需求开一个 feature 分支，做完一些就合到 develop，前端去对接。开发这边感觉没问题，而且剩余时间足够，大概率能发版了，就合到 release 让测试去测。

一般情况下，release 不会有太大问题，稍微改改就能合 master （改的时候一般在 feature 上改，改完再合到 develop 和 release ）。

如果真的有太大问题了，某一个 feature 没法上 master 了，那就把能上 master 的 feature 合到 master 发版。

发完版之后，删掉原来的 release，在 master 上切出一个新的 release 分支。

@gy0624ww 你这系统没做 soa 吧。

感觉可以从管理上来缓解这个问题呀。
A B C 是否是要在一次发布上发布，是的话，可以切一个公共 feature 分支 X，ABC 都合上去，使用 X 分支测试；不是话，就按功能发布顺序测试，假如是 A 先发布，就 A 分支先测试和主分支发布，B 发布前肯定是要合并主分支的代码整个测试的，有冲突也是 B 来解决。

如果功能涉及到可能冲突的，肯定要么是合并一起测试，要么是发布一个再合并测试下一个呀。

不是可以本地环境开发吗，那就在哪开发在哪起服务测啊
公用测试机会有问题，我改完代码要重启，其他人功能测一半怎么办

@MaxFang 不考虑冲突问题，测试是同时测的，环境分前端和后端。

这个应该不是 git 工作流问题，而是多版本测试环境管理的问题

1 、该种情况在我们公司的处理方案是通过 docker 搭建多个测试环境，不同测试环境的域名不一致（使用通配域名），例如 test1 、test2 。根据访问域名的不同，来指向不同的测试环境进行测试。
2 、另外关于环境中的前后端问题：
2.1 不同测试环境有测试需求所涉及的代码仓库，将仓库分支切到开发分支即可
2.2 如果使用的前端都是 master，可以将该仓库的访问打到一个公共地址对应的仓库上去（避免每个仓库都存在相同的代码）

之前遇到个问题，两个同事共同用到一个文件，而且每个人都把这个文件改的面目全非，相当于每一行都有改动，merge 合并错误，请问下这种情况怎么处理呢

@shilianmlxg 只能手动解决冲突，相关开发沟通下，类似的情况也会发生在代码重构时，尽量避免同时存在多个差异过大的分支

推荐用同一个测试分支，小需求又独立，出现冲突手动处理下问题也不大。长久考虑整两套测试环境，内网台式机搭建便宜

TFS 路过…

楼上的都没提到一个问题，从工程性来说。分开测，你怎么保证三个功能没互相影响？就凭一张嘴还要测试干什么？合并在一起再测一遍？我认为在测试中，一个项目有且仅有一个环境即可。

我虽然是运维，我也支撑多环境部署。但我也曾经是开发。从整个工程链路的全盘角度来说，多分支测试浪费大量的人力物力只是为了满足测试方赶紧完成自己的工作任务，满足开发结束提测休息。那全局来看，谁来管整个项目质量到底如何呢？

找个懂的，依赖反转。

针对同一个代码片段的互相有影响修改，竟然可以分别独立测试？难道最终这不是要合并到一起运行的？

显然要规定合并顺序，ABC 约定好合并顺序，假设 A B C 的顺序

A 首先他的 base 就是原始代码，进行一次测试，测试通过合并进主线或者合并进新分支 Atested

测试通过后合并进主线，由 B 在另外测试分支，解决冲突合并成 A+B(Atested)，预提交进 Bpretest，测试人员通过 Bpretest 分支进行测试，测试通过合并进主线或者合并进新分支 ABtested

然后 C 进来

软件不是功能的堆砌，而是组织，要加需求先重构。

三个需求提出时间比较短，上线时间可能不同，按照我们的做法是先对需求和团队人力做评估，然后明确上线时间和上线需求。开发可以并行开发，到时需要上线什么需求就擦该分支合并入专门的发布分支，测试组只关心发布分支的内容。我们不会单独测试某个分支，一切需求都需求合并入发布分支才接受测试，这样可以从流程上保证工程质量，才不会无谓地浪费时间。

初一看，这不是一个因为只有一台测试机，而无法同时跑 3 个代码版本的问题吗？ Docker 解决。

细想下，我感觉是开发流程的问题。一般都是本地开发然后测试，然后提交代码审查，然后合并进测试环境，测试环境可以只有一个， 只用测 master branch，最后再到生产环境。

你的问题是混淆了开发环境和测试环境，测试环境上不应该测试还未开发完整的代码。

我理解你的问题是 测试开发资源都非常紧张， 要尽可能的利用开发和测试资源快速完成这三个需求， 但是这三个需求设计的功能点重叠部分较多 并行开发冲突很多 现在三个需求都开发完了 又不能串行测试 需要并行测试 然后上线时间待定 根据老大或上头资源协调的情况定 是吧？

如果没理解错的话， 我的建议是： 前后端都使用个合并分支 将这三个需求合并到一个分支上发布 这期间肯定需要解决冲突，然后期间如果遇到 bug 修复， 优先在 ABC 三个需求对应的分支上修改然后合并到发布分支 测试， 后面如果上线 AB 则将 AB 分支代码合并测试上线 目前我能想到的办法就是这个， 这里面风险是比较大的 因为稍微不注意就会合错代码， 在开发的时候代码尽量做到需求上的物理隔离， 这样因为冲突导致代码合并错乱的几率会降低

确实是一个普遍问题，目前我们部署了 10 个前端环境，后端是一个，因为后端多数是增加接口不会有兼容或者冲突问题，能解决 95%的场景了，剩余 5%就资源协调吧

@realpg 恩 涉及冲突的可以安排先后顺序进行测试，不考虑有冲突。每个需求都是独立且同时开发的。然后几乎同时测试，但是测试周期和上线日期不同

@afx 那就是说同一时间只有一个需求进行测试，开发并行开发完成后，依此合并分支提测。那么剩下时间只能等待了

懒得弄多环境的话，让测试连开发电脑测试。

谈谈我在我司的实践。
1. 服务器部署：
前端目录：将项目目录复制为 f1 、f2 、f3 ....
后端目录：将项目目录复制为 b1 、b2 、b3 ....
nginx 配置 f1.test.xx.com f2.test.xx.com f3.test.xx.com / b1.test.xx.com 、b2.test.xx.com 、b3.tes.xx.com 到对应目录。ps. 如果后端只想用一个域名，可以。b.test.xx.com/1/api，然后 nginx 把 1 解析到对应目录，去掉 1，rewrite 一下 URI

2. 前端(客户端)配置后端环境
前端开发一个切换环境的组件，提供入口给测试同学输入数字切换环境。
例如安卓，长按某个页面元素，跳转到命令框输入，测试同学输入数字 n，那么把 n 保存到文件 /localStorage，后面发起
api 调用时，只需将数字拼接到 host 或 path，就能调用不同环境。并且，前端需要将“测试环境 1/2/3”标注在页面显眼的地方，让测试同学清除现在身处哪个环境。
后面后端水平扩展多个环境都可以，测试同学可以随意切换不同环境，不需前端改代码

PS. 前端发布线上版本的话，注意要将这个组件移除（编译脚本实现）

3. 测试同学 /产品
需要给这两位同学简单培训使用方法。并且在某个功能测试时，需要发布测试须知：
xx 功能，前端环境：2，后端环境：5


抛砖引玉~

@foam 恩，多谢 很有启发