在非 main 分支上使用 continuous deployment，真的好吗？

main 分支是啥？

意思是内测版没资格部署，测试不需要线上测

@sutra github 默认主分支就叫 main 分支，再无 master ```

这个问题有歧义，main/master 分支不一定就对应的是 production environment，得先定义你用的是什么分支模型。

那万一这个 repo 有 prod branch 呢？这个 branch 是不是 dev or prod 是自己定义的，并不是约定俗成的。

当然，在大多数 case 里 master branch 的确是 prod 。

我们都在 master 分支上搞～

@GeruzoniAnsasu #2 什么意思？不太明白。

@sutra #4 我指的 main 分支就是 production environment，公司的其他项目组有 dev 分支的概念（我这个小组不使用这种方式），也就是在测试环境运行的，那么 dev 分支有必要做 continuous deployment 吗？

@janxin #6 也就是只有 main 才做 continuous deployment ？ merge request 被合并之后自动触发生产环境的部署？

我们用的 release-vX.Y.Z，咋就不行了，main/master 分支只是最新的代码

@thet #10 我在附言中补充了我提出这个疑问的原因。

@JasonLaw 不是，你提问的情况看上去开发时仅两个分支在工作：发布分支和开发分支；实际上如果分支还包含预发分支等其他功能分支的话，预发分支或其他需要部署的功能分支是可以作为 CD 部署的对象的，用作预发或者内部集成测试等功能需求。当然这跟开发分支需要进行持续部署没有关系。

1. 太频繁的 commit 污染可以用 squash 解决

2. 每个 branch 应当建立单独的测试实例
比如
dev 分支有一个 dev.example[.]com 的记录
然后 fix-issue-42 有一个 fix-issue-42.example[.]com 的记录
内网泛域名索引，然后根据 Host 头响应

这种做法倒没什么不对的；道听途说，过于庞大的项目根本不能在合理时间内本地编译，都是丢专门的编译服务器的，改两三行代码，然后编译一天。

但是我看着觉得你这是不是缺乏自动化测试？
理应当不用 CD，CI 先跑通再说啊

@no1xsyzy #14 你说的对，完全没有自动化测试，很多修改都没有相应的测试代码。

就看你的 dev env 是否需要用来给别人用了，如果需要给别人用，那就 CD 呀。

test env 肯定是要给别人用的，那肯定要 CD，不然手工搞多累。

服务频繁不可用？
如果测试环境是共用的话，这样当然不好。如果是每个人自己的测试环境的话倒是没关系。

至于频繁 commit，这算啥问题？ Git 历史重写就好了。