请教一下各位有没有这么用版本控制的

[aa514758835]

比如一个项目有很多文件夹，配置文件，源码等。源码都用的主分支，配置文件根据哪个项目用哪个分支的配置文件。 就想问一下实际真有人这么用吗？

[xiaogu2014]

```不应该用多个分支来作为不同的 source of truth 。```

可以说下更多的 context 为啥要这么做。 写不同的配置文件不行吗。

[foolishcrab]

新开一个文件夹放配置不是比新开分支好维护吗？配置加个 key 还得疯狂切分支？

[joyhub2140]

开发阶段我们是在 master 主分支罗列所有的配置文件，然后分支再指定用哪个配置文件。

不过，生产环境的配置和源代码和二进制分发包分离，直接配置到服务器里，也就和分支什么没关系了。

[aa514758835]

我从未见过这么使用的，然后为了这么使用需要做很多额外开发工作我就觉的这个方向有问题，明显是把问题复杂化了。

理论上用分支肯定是整个切的，然后有需要去合并到主分支，基本都是这么用的。

我感觉为什么这么做你们应该知道了，属于不会开车指导会开车的。

[snake2004]

@xiaogu2014 如果不同项目的配置文件都在一个分支里，不同项目间都能看到别的项目的配置，无法实现项目间的权限控制。

[dylanqqt]

听你说就感觉很繁琐

[dzdh]

这时候就显示出来环境变量的重要性了

laravel / go / rust 都有 dotenv 吧

[snake2004]

@aa514758835 如果不按项目分支，某个项目下版本就从主分支下，然后要改配置为某个项目，毕竟所有项目配置都在一个分支里，运行时用哪个项目配置要指定。如果按项目分支，就直接从项目分支同步后不用改直接可以运行。

[newaccount]

看起来怎么那么像是传统 ERP 的版本管理方式呢
master 作为核心代码一直往前走，有客户购买就切个分支出来，这个分支的起点不一定是 master
之后这个分支会做一些针对这个客户的定制开发，开发的结果不会合并回 master ，因为没有意义
如果有些功能需要从 master 到分支，会采取类似 cherry pick 的方式，但分支还是保持各自独立
不好说对错，以前 vss/svn 很多公司都是这么玩的
现在 git 怎么弄合适还真不清楚，不在这种类型的行业做了

[lasuar]

你自己都察觉不合理了，还问。

[aa514758835]

@lasuar 多问不好吗？

[jim9606]

最好别这么用。
可以每个分支都有全套源码+专属配置，也可以单分支源码仓库+多分支配置仓库。
我能想到强行用同一个仓库的理由是你想白嫖一个按仓库数限额的 VCS 托管平台。

[aa514758835]

@jim9606 了解~~

[snake2004]

@jim9606 你这所谓每个分支有全套源码+专属配置，不就是从主分支检出不同项目的分支么，生成的分支必然是有建立分支时的全套源码。

[IvanLi127]

这... 如果有用 git submodule 来处理的话，应该有吧...这似乎前提是放在单独的目录里。

反正我不会这么用，好麻烦

[weeei]

这种情况适合使用 fork ，这样就需要多个仓库。你现在这种做法只不过是不想 fork 而采用的简单方案。没啥问题。

[xiaogu2014]

@snake2004 项目见的权限控制可以放在不同的 repo 里面。
以及放在不同分支里就可以实现项目间的权限控制了吗。。。。

[snake2004]

@xiaogu2014 服务端可用 hook 实现

[location123]

repo ？

[simen513]

配置通过代码生成，传不同参数就生成不同的配置，这样就可以都放在一个 repo 中。