12

I have a config.php which suppose to be different in content in different branches, e.g. testing and master.

I have asked in another question (Prevent merging a file from master with Git) that how to prevent this file from merging.

But I am wondering, is this the correct way to do so?

I believe this is quite a common use case to have different config files in different environments and you want the config to keep tracked, right?

Community
  • 1
  • 1
Ryan
  • 10,041
  • 27
  • 91
  • 156

4 Answers4

6

For a config file, one solution is to not version it (that way, no merge issue!)

You would use a content filter driver:

content filter driver

You would version:

  • one value file (for master environment)
  • one value file (for dev environment)
  • one template file (with placeholder variables like @PORT_NUMBER@)
  • one 'smudge' script able, based on the current branch, and based on the content of the checked out file (here the template file) to generate the actual config file (which remains 'private', ie not-versioned).
  • one 'clean' script able to detect any value changes in the private config file, and store those changed values back in the (versioned) value files.
Community
  • 1
  • 1
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
4

The classic way to do this is to have a default config file called config.yml-dist (let's pretend that your original file is called config.yml) ; you add the original file in .gitignore, and version only the dist one.
After you deploy your app or re-clone the project, simply cp config.yml-dist config.yml, and change the settings you want.

This method is used by many people I met in the PHP industry.

But, there's one I like much more and that I find cleaner: using environment variables. Example:

username: <%= ENV['MONGOID_USERNAME'] %>
password: <%= ENV['MONGOID_PASSWORD'] %>
database: <%= ENV['MONGOID_DATABASE'] %>

This way, you'll have one single versioned configuration file and won't have to edit a single one.

Samy Dindane
  • 17,900
  • 3
  • 40
  • 50
2

You can have the master branch not contain that file, and only have it in the branches -- that'd be the easiest way.

Alternatively, and assuming the master configuration is reasonably stable, or else this'd be a big pain -- commit the config.php changes in each branch and then always pull with rebasing when you get changes from master so that the configuration changes are reapplied each time.

michel-slm
  • 9,438
  • 3
  • 32
  • 31
1

Why wouldn't you store all the environment-specific config files in the main repo? Then, either during build or deployment process, you would take whatever configuration file is relevant. There are lot of different ways of implementing it, depending onyour build/deployment tool, but any way you do it I think it is be better than having it in branches.

My opinion is that you definitely want the config files to be stored in version control and deployed using a deployment tool, so you wouldn't have old versions hanging around due to lack of updates or manual error.

Usually there exists a folder structure like

/configurations/test/properties/
/configurations/prod/properties/

and the deployment tool uses them per environment as requested. Any confidental information such as passwords can be either hashed or encypted: tehcnologies like ansible vault support this directly.

eis
  • 51,991
  • 13
  • 150
  • 199
  • Usually it is a very bad idea put a config file with sensible information (passwords, ...) in a repo. – macjohn Nov 08 '12 at 11:22
  • @macjohn depends. first of all, your repo can be sensitive as such, only shown to internal developers who both should and also need to have access to that information. second, if the information truly is sensitive, it doesn't have to contain *actual* information - it can contain encrypted values, decrypted per environment-specific key, it can contain environment keys that point to the actual information etc. – eis Nov 08 '12 at 11:37
  • My opinion is that having the environment configuration, such as server names, in for example environment variables is worse idea. You don't have the visibility for change, you don't have access to previous versions etc. I was maybe a bit misleading in that all environment-specific configs should be in the main repo, as in sensitive (like passwords) should have probably other measures in place also. – eis Nov 08 '12 at 11:48
  • after five years, I still agree with my approach. Nowadays when we have ansible with vault this has become trivial. Basic approach however hasn't changed. – eis Nov 10 '17 at 14:23