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

[gy0624ww]

工作中遇到的情景是这样的

多人开发同一个项目，比如有 ABC 三个需求。（有可能涉及更改同一个文件） 这三个需求是提出间隔比较短，有一段时间是并行一起开发的，同时参与测试，但是上线日期可能不同。

首先，从 master 拉出各自的分支。每个人各自现在自己的本地环境开发，做完后把各自的分支打包到测试环境给测试。 测试人员也是多名，但是目前测试机就只有 1 台。

现在的问题就是前后端分离，后端是 go，打包的名字都叫 main，都是 80 转发到某一个端口（项目固定比如 8080 ） 前端一套环境，后端一套，然后多个需求就会面临 A 需求有时候就会把 B 需求的 main 覆盖掉才能进行测试。

不知道大家有没有遇到这种情况，都是怎么处理的。

之前想过大家都把分支合到一个测试分支 比如 develop,但是这个分支包含了多个需求，有可能不同需求直接会相互影响，测试测完之后，要根据上线的顺序再手动把改的代码合并到 master，这样容易出错，而且手动合并到分支也会造成版本记录的丢失。

也有想过每个需求都单独部署个独立的端口给前端，那么前端也需要同样根据不同需求部署多套，显然这样也很麻烦。

请大佬解惑

[lululau]

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

[monkeylyf]

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

[gy0624ww]

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

[taogen]

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

[gy0624ww]

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

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

[monkeylyf]

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

[gy0624ww]

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

[gy0624ww]

@monkeylyf 👀 不知道啊。。。

[gy0624ww]

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

[KuroNekoFan]

确实是普遍存在的问题，如果不能确保不同开发者之间同一时间只修改不同的业务，那就只能创建 N 个测试环境了

[taogen]

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

[tealover007]

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

[gy0624ww]

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

[gy0624ww]

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

[ismumu]

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

[lplk]

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

[soulmt]

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

[robot1]

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

[weakish]

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

[594duck]

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

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

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

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

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

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

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

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

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

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