请教大家一个测试环境代码合并的问题

1 天前

j0hnj

我们服务分为生产环境和测试环境；

我们的开发流程是，研发将自己的开发分支合并到测试分支（第一次合并），上线到测试环境，准出之后，提交 PR 将 feat 合并到 master 分支（第二次合并），然后上线到生产环境。

问题在于第一次合并是普通的 merge commit （因为开发中需要持续修改、持续合并），第二次合并是 squash merge (为了让主线更清晰）。这样时间长了之后，再从 master 拉开发分支，合并到测试分支的时候很容易冲突，很难解决。需要经常手动用 master 强制覆盖测试分支，强制覆盖就需要所有在测试中的 feature 再次合并到测试分支，比较麻烦。

想了解下这个问题有没有好的解决办法？

1141 次点击

所在节点

git

17 条回复

chairuosen

1 天前

两条并行的永久存在的分支(dev,master)就会出这个问题。
就像写业务时，同一份数据放两边分开维护，最后一定会莫名其妙不一致。
解决办法就是测试分支是临时的，但是同时测多个需求需要多套测试环境，或者一次版本迭代统一一个测试分支来测，测完就删

yiqiao

21 小时 57 分钟前

只有 dev 和 master 只适用个人开发吧。
用 git flow 工作流呢？
https://nvie.com/posts/a-successful-git-branching-model/

AntiFraud

21 小时 52 分钟前

工作流不对，所有代码在个人开发分支开发，开发完成验收通过后，将当前版本代码合并到测试分支。当前版本代码在测试分支验收完成后，合并到 master 分支。所有人新开发分支，从测试分支拉取。

securityCoding

21 小时 48 分钟前

采用 github 那种 fork 方式就好了，合并分支发起 rebase mr

lepig

21 小时 45 分钟前

我们简单粗暴

1. 所有开发直接在 develop ，然后功能搞好了本地合并到 test 然后 push 到远程 test(也就是测试服务器所拉取的分支)。

2. 测试没问题，直接本地或者运维(我)来本地再次合并到 release ，然后在 push 到远程的 release(也就是生产拉的分支)

3. 我直接登录生产服务器，直接 git pull ，齐活。

有运维的直接让运维搭建一个 jenkins 或类似的工具来部署。万一有问题可以随时撤回版本

wu00

21 小时 36 分钟前

github flow / gitlab flow
小团队 rebase ，就是简单粗暴 master 分支为主，不管你是 dev/pre/prod 任何分支都基于 master rebase
各种临时发、临时不发、hotfix 都可以用 cherry pick 去搞

InDom

21 小时 27 分钟前

首先不推荐 #3 从测试分支开新功能分支的方案.

其次你遇到的问题应该是很难避免的, 到最后总会有测试分支与生产分支有较大的差异的情况.

rarpainting

21 小时 13 分钟前

这个在团队之前也经常遇到，现在的话就是放弃 squash merge 了，现在一个版本改动的代码太多了，经不起这种合并出错的风险

williamx

20 小时 49 分钟前

“再从 master 拉开发分支，合并到测试分支”

这个流程应该是不对的。

sampeng

20 小时 5 分钟前

其实是团队有多少人啊。。5 人以下的开发 team 都在一个分支里开发是死不了人的。。。

STtree

19 小时 39 分钟前

我们团队用的是所谓 chunck based 开发方式，所有 pr 最后 merge 到一个分支上，在这个分支的某个 commit 上打 release tag ，这个 release tag 会部署到各个环境上，测出问题来了就移动 release tag 的位置，实在不行的话 revert pr 。

STtree

19 小时 28 分钟前

chunck based => trunk based ，不好意思打错了