36

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.

robertrv
  • 695
  • 2
  • 11
  • 16
  • That is available with Git 2.23 (Q3 2019): https://stackoverflow.com/a/57031395/6309 – VonC Jul 14 '19 at 21:51

2 Answers2

36

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.

XzAeRo
  • 566
  • 5
  • 11
rtn
  • 127,556
  • 20
  • 111
  • 121
1

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

klaustopher
  • 6,702
  • 1
  • 22
  • 25
  • 1
    Yeah. I agree with you on not having the database info in the repo (it was not our call, we inherited the project form another company). In this case, though, we are a three-man team and we all do dev and server setup. So, it's pretty hard to keep the database accounts from the development team. I'd like to spend some time on consolidating and fixing configs, but it's hard to convince the client it's worth it when "it works". – robertrv Mar 09 '12 at 16:55
  • 2
    Why mustn't the developers know the credentials of the production database? is it because they might go rogue some day and mess it up? – kotAPI Jun 01 '18 at 06:06
  • 1
    @Legolas it has mostly to do with data protection. You should always make sure the least people possible have access to the real user data. Why does a developer need to know the credentials to the production database? Does she need it for developing? Of course, that's different when your developers are also the guys running the infrastructure. But as a general thought: Keep secrets to the smallest group you can. – klaustopher Jun 05 '18 at 13:39