使用git处理不同的配置

时间:2014-06-25 14:30:51

标签: git development-environment production-environment

我正在做一个Laravel 4项目,在mail.pjp上有一个选项,您可以在其中假装发送电子邮件,但实际上您将其本地登录到文件中。这对开发很有用。

我遇到的问题是版本控制。如果我签入,此选项为" true",那么我冒着更新生产服务器的风险,如果我不小心,它可能会禁用电子邮件。

另一方面,如果我在git中检入文件为" true",它可能发生在今天发生的事情,我失去了几个小时试图理解为什么邮件不能正常工作因为我忘记了我必须为我的开发环境更改此选项。

我可以用什么方式处理这些"生产与开发"配置问题与git?

2 个答案:

答案 0 :(得分:0)

为每个配置分配一个分支。

例如,您可以拥有production分支和dev分支。

production分支上,只需进行一次提交即可更改配置文件,然后使用dev分支,就像使用master分支一样。

部署过程变为

开发:

  • git checkout production
  • git merge dev
  • git push origin production

关于制作:

  • git pull origin production

或拆分配置文件

也许可以添加一些运行时测试来在合适的时间选择好的。

答案 1 :(得分:0)

我遇到了类似的问题并使用了以下解决方案,该解决方案可能有点重,但可以很好地将“私有”数据与公共项目分开。

我们的想法是不将您的配置文件放在普通的git存储库下,而是放在私有存储库中。 理想情况下,您希望私有仓库是公共子仓库的子模块,但您必须以另一种方式执行此操作(隐藏公共仓库的私有仓库)。

为此,我创建了一个包含我的配置文件的private repo。然后我创建一个包含public的子模块,并添加一个指向配置文件的链接。

目录结构如下:

private + (private git repo)
        |
        +- config.conf
        |
        +- public + (public git repo)
                  |
                  + config -> ../config.conf
                  |
                  + src 

然后我在两个版本的私人仓库上有一个devel和一个production分支 配置文件。但我从来没有碰过这些目录。

当一个新的开发人员到来时,他只是将开发分支和公众内部的工作分开,就好像没有伞项目一样。只需正常拉动。

当您需要部署时,只需转到生产计算机并更新public子模块。 如果您需要更新生产配置文件,只需在生产计算机上更新它并推送它。或者,您可以在本地切换到production分支,进行必要的更改并将它们推送到生产服务器。

希望它很清楚。