这是一个创建于 3140 天前的主题，其中的信息可能已经有所发展或是发生改变。
是这样的.我有两个分支.master 和 dev.dev 主要是开发用的.然后 master 是用来线上正式使用的.一般是 dev 开发测试完直接合并到 master 分支上.
但是有这样的问题.就是有一些配置文件 dev 分支和 master 是不一样的,因为 dev 是用来本地开发等,而 master 是用于线上发布的.所以配置是线上的配置.这样每次合并 dev 分支到 master 都要修改下配置.或者 dev 提交的时候把配置部分给回滚掉.然后再提交合并到 master.
每次这样都感觉好烦.请问下大家有没有什么好一点的解决方案.
但是有这样的问题.就是有一些配置文件 dev 分支和 master 是不一样的,因为 dev 是用来本地开发等,而 master 是用于线上发布的.所以配置是线上的配置.这样每次合并 dev 分支到 master 都要修改下配置.或者 dev 提交的时候把配置部分给回滚掉.然后再提交合并到 master.
每次这样都感觉好烦.请问下大家有没有什么好一点的解决方案.
 | 1 bt 2017-03-06 16:38:25 +08:00  1 设置环境变量然后读取对应的配置文件？ |
 | 2 QAPTEAWH 2017-03-06 16:46:44 +08:00 弄三个分支： dev 、 master 、 master_with_conf 。 dev 搞完后 merge 到 master 上，再把 master_with_conf rebase 到 master 上。 ------master---master_with_conf \ / .--dev-- |
 | 3 huweitxdy 2017-03-06 16:47:47 +08:00 线上配置和本地开发的配置文件应该分成 2 个独立的文件，线上的那个文件只存在 master 里就可以了 |
 | 4 BigUncleLee 2017-03-06 16:48:34 +08:00 把配置文件添加到.ignore 文件中 |
 | 我目前了解的比较不错的方案： 1 、 env.example 入仓库，部署实例后 mv 成 env ，不要 add 这个 env 。 2 、约定好 env 的存放位置，只要在工程目录之外的就行，比如 /var/project/env ，然后程序里去读这个位置的 env ，绕开 env 入仓库的问题。 我们目前在用方案 1 。 |
 | 7 hekunhotmail 2017-03-06 16:53:40 +08:00 切换 env 还要修改整个配置文件？ 做个开关吧，开关文件存一些全局环境变量， 两个配置文件， dev.cfg ， release.cfg ， env 不同读取不同的 |
 | 8 donghui 2017-03-06 16:53:56 +08:00 不同配置分成不同的文件夹 或者配置与代码分离 |
 | 9 game3108 2017-03-06 17:14:23 +08:00 配置文件为啥不 ignore 呢？ |
 | 10 cxbig 2017-03-06 17:16:57 +08:00 配置文件分 2 类： 1. 几乎是静态、无敏感信息的 做成模板文件上传，如.env.prod 、.env.staging ，部署或本地开发酌情选用并 cp 到.env ，.env 加 gitignore 2. 带有敏感信息的 不上传 repo ！可以做成特定模板，在部署的时候通过所使用的语言将占位符替换成敏感信息直接部署到服务器 可参考 Capistrano （基于 erb 模板）或 Ansible （基于 Jinja2 模板）的配置信息部署方案 |
 | 11 zhustec 2017-03-06 17:45:32 +08:00 via Android 设置 2 个配置文件 production.config development.config 代码里根据环境读取相应配置文件，环境可用环境变量指定，可以设置不指定环境时默认为 production 或者 development |
 | 12 irory 2017-03-06 17:49:32 +08:00 每个环境对应单独配置文件呀 ... |
 | 13 zero1234888 2017-03-06 17:54:42 +08:00 1.首先建立站点工作模式（ dev,beta,release ）把你的一堆配置项变成一个配置项 2.把这个配置项摘出来放进一个 baseSetup.config 里面保证除了必要的大改之外不会被动到 3. git update-index --assume-unchanged PATH 在 PATH 处输入要忽略的文件,把这个文件忽略掉,省得每次 git status 的时候跳出来烦人…… |
 | 14 GOOD21 2017-03-06 17:56:09 +08:00 目前在用的方案： link dev.conf 和 pro.conf 同时提交到版本库， conf.conf 加入 ignore 开发环境： ln -nsf dev.conf conf.conf 线上环境： ln -nsf pro.conf conf.conf |
 | 15 sarices 2017-03-06 17:58:51 +08:00 配置应该忽略的啊，然后线上部署的时候自动部署配置文件，而不是 push 到服务器上 |
 | 17 LinusTor OP @zero1234888 非常感谢.git 的这个命令还真没用过.等会儿研究下. |
 | 18 xiaowei4895 2017-03-06 18:03:47 +08:00 个人觉得 git 的分支，只是文件版本的管理，不适合用来做环境的区分。 建议用打包脚本或者环境变量来进行环境的区分。 |
| 19 LinusTor OP @cxbig 嗯嗯.是的哈.一些数据库连接字符串等还是不能传 repo 的.除非仓库本来就是 private 的. 但是对于 py 的代码.部署的话也只是更新下仓库.重启下服务等.不会设计到部署编译. 貌似使用系统环境变量是不错的办法.这样也不会污染代码仓库.线上线下环境变量配置不同的就可以了. |
| 20 LinusTor OP @sarices 配置文件如果忽略的话.拉新的仓库时候都要复制粘贴配置文件.而且如果配置文件修改了别人更新也是个麻烦事. |
 | 21 crayygy 2017-03-06 18:10:59 +08:00 via iPhone 我一般的解决方法是加到 ignore ，不过 Rails 给我一个启发，可以存同一个文件， production 和 development 分别用文件内的不同数据就好了。调用的时候声明一下当前环境再决定加载哪部分。 |
| 22 sarices 2017-03-06 18:12:09 +08:00 @liangliangyy 配置文件别人也能修改那个是你们管理的问题了，部署我觉得最起码应该停止网站切换到维护模式，更新代码，然后更新配置文件等等，最后再重新开启。 |
 | 23 scriptB0y 2017-03-06 18:12:25 +08:00 我在 django 的做法是： settings 里面根据环境不同的配置（例如 debug ），使用从别的文件 import 的方式。这个文件本地、服务器各一份， gitignore 忽略。 另外，不要用 master 发布，从 master checkout 一个 release 分支，每次觉得可以发布就用 release 分支从 master 合并， 并且打上 tag ，这样可以保证快速回滚。 |
 | 24 nicevar 2017-03-06 18:18:42 +08:00 这个需求与 git 没多大关系，不管你是做前段后端还是客户端开发，测试和正式环境都能通过配置来解决的， maven 的 properties 、 gradle 的 build variant ，尽量配置成不依赖特定环境的最省事 |
| 25 LinusTor OP @sarices 嗯哈 抱歉没表达清楚.我说的是在开发时候.配置文件更新了.然后别人开发的时候为了代码同步环境统一.肯定也要更新配置文件.这样如果没有在仓库里面的话只能靠手动更新了. |
| 26 LinusTor OP |
 | 27 bearzk 2017-03-06 18:31:56 +08:00 我的方法是 production, staging, local 都有不同的 config 文件,根据 env 使用一种, local config 被 `.gitignore` 忽略 还有推荐使用 gitflow https://github.com/petervanderdoes/gitflow-avh `master`, `develop`, `feature/*` 管理起来比较方便 也有方便的 release 流程 |
 | 28 TIGERB 2017-03-06 18:46:15 +08:00 部署的时候初始化不同环境的配置文件么 |
 | 29 Waterm 2017-03-06 18:56:15 +08:00 @bearzk 我也是用这种方法的。这样一来可以灵活配置自己本地的调试环境，二来进行多人协作时别人也能区分清楚。如果是做些个人小项目直接 gitignore 吧。 |
 | 30 SoloCompany 2017-03-06 21:01:56 +08:00 出发点就不对，代码分支不应该和配置沾上任何关系，如果你的配置足够复杂，可以把配置单独建一个 repo 如果只是简单的配置，而且不存在敏感数据，可以所有配置都放到源码里面，执行的时候根据执行环境动态决定加载哪一套配置 |
| 31 cxbig 2017-03-06 21:34:20 +08:00 @sarices 现在比较推崇无缝部署，如 Capistrano 等自动部署工具或 Blue-Green-Deployment 等策略。切换到维护模式越少越好。 |
 | 32 Felldeadbird 2017-03-07 12:24:55 +08:00 开发的版本库不要和配置有任何直接的挂钩。否则团队其他成员一旦不知情下修改了。那些配置信息也被同步到生产环境中，将会带来严重的影响。 |
 | 33 ubear1991 2017-03-07 13:18:51 +08:00 用不同的配置文件。 master 就用 master 结尾的， dev 就用 dev 结尾的。 |
Select Language