Branching: different config files for release/development

I've inherited a project and we are using git. We have a number of environments (dev, test, prod). The previous team basically recreated everything on each instance, using the same accounts, passwords, sid, etc. The only thing that changed was the hostname mappings in /etc/hosts. So that it would connect to a different database server.

Now, this creates a problem, because I can't, for example copy a schema so that a developer can run an experiment using the same database instance as the main development server. I basically have to create a new database instance on another host, and change /etc/hosts to point to that new server.

While this is currently a working setup, I'm trying to find a way to maintain different config files for each instance. ie: Different versions of applicationConfig.xml depending on the branch. I'm guessing one could argue that keeping database credential in the repo is not such a great idea, but lets just ignore that for a second.

Another situation that might warrant having a different version of a file could be debugging. Say I'm using a javascript logger framework, and I add debug code that I wouldn't want to ship with a production release. I don't want to have to add the logger stuff when developing/testing and then remove it again before releasing. One might forget to do it.

What's the proper way to deal with different "versions" of a file for different branches? Is there a way to have a branch that remains in sync with the latest code on master, but with a few config/code files changed? I don't expect it to remain in sync automatically, but I'd like to be able to not merge the config files (or parts of them), while not ignoring them completely (?). For example: don't merge lines 6,7 (db username and password), but do merge the other changes to the files.

It sounds like you should read up on git attributes. Check out the section at the bottom of this page

This is helpful if a branch in your project has diverged or is specialized, but you want to be able to merge changes back in from it, and you want to ignore certain files. Say you have a database settings file called database.xml that is different in two branches, and you want to merge in your other branch without messing up the database file.

As you already said, storing the config settings inside your code isn't a good idea. Especially, your developers shouldn't even know the credentials for the production database, in my opinion.

What we do here is that on each server we have predefined environment variables pointing to a configuration file that has the necessary credentials. Since we are using Java here, this is a file like database.properties and this file is never inside a version control system.

This also makes it possible to have different settings and different credentials on each server