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

[gy0624ww]

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

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

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

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

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

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

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

请大佬解惑

[gy0624ww]

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

[gy0624ww]

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

[goodboy95]

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

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

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

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

[594duck]

@gy0624ww 你这系统没做 soa 吧。

[MaxFang]

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

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

[Still4]

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

[gy0624ww]

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

[flyBlackElephant]

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

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

[shilianmlxg]

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

[MarioLuo]

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

[MarioLuo]

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

[358515041]

TFS 路过…

[sampeng]

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

[sampeng]

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

[yangbonis]

找个懂的，依赖反转。

[realpg]

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

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

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

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

然后 C 进来

[yangbonis]

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

[afx]

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

[cassyfar]

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

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

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

[palmers]

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

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