使用 git 处理不同的配置

Question

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

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

另一方面，如果我在 git 中将文件签入为“true”，可能会发生今天发生的事情，我浪费了好几个小时试图了解为什么邮件无法正常工作，因为我忘记了我有为我的开发环境更改此选项。

我可以通过什么方式使用 git 处理这些“生产与开发”配置问题？

Answer 1

每个配置都有一个分支。

例如，您可以有一个production 分支和一个dev 分支。

在production 分支上，只需提交一次以更改配置文件，然后像使用master 分支一样使用dev 分支。

部署过程变成

在开发中：

• git checkout 生产
• git 合并开发
• git push origin 生产

在生产中：

• git pull origin 生产

或者拆分你的配置文件

并且可能会添加一些运行时测试以在正确的时间选择好的测试。

Answer 2

我有一个类似的问题并使用以下解决方案，它可能有点繁重，但可以很好地将“私有”数据与公共项目分开。

我们的想法是不要将您的配置文件放在您的普通 git 存储库中，而是放在一个私有的存储库中。 理想情况下，您希望私有 repo 成为公共 repo 的子模块，但您必须以另一种方式进行（对公共 repo 隐藏私有 repo）。

为此，我创建了一个 private 存储库，其中包含我的配置文件。然后我创建一个包含public 的子模块，并添加一个指向配置文件的链接。

目录结构如下：

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

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

当一个新的开发者到来时，他只是分叉了开发分支和公共内部的工作，就好像没有伞形项目一样。像往常一样拉推。

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

希望很清楚。