0

I'm developing from a home office and the rest of the team is onsite. Currently my environment is setup with local copies of the databases such that everything works provided I change all my connection strings from something like:

data source=server\instance

To:

data source=.

The problem is after every local merge I have to re-apply the same changes to a bunch of files.

My goal is find out if there's a nice way to leverage Git ability to merge changes from revisions to easily re-apply these changes.

As a first step I committed to my local copy just the changes to my config files. My first thought was I could Cherry-Pick that commit to get back my local changes, but now I'm looking at it and I'm not sure how to proceed.

Has anyone solved a configuration issue like this with Git and if so, how did you do it?

I think the functionality I'm after is essentially to "temporarily merge a set of of changes to a set of files and then revert them".

4

1 に答える 1

2

While I personally prefer to keep configuration information entirely separate from the code which that configuration is meant to apply to, there are existing solutions for maintaining a patch series on top of a moving target. guilt is the git-based work-alike for Quilt, a popular patch management system.

The canonical response, which I agree with, is: Don't commit config files, commit templates of config files.

Personally, I prefer a slightly modified version of this mantra:

  • don't commit config files, commit defaults which are specified in the same format as the config files themselves.
  • structure you application in such a way that defaults can be overridden by a file which specifies only those settings which disagree with the defaults. This allows additional defaults to be specified over time, without them being ignored due to the presence of a local configuration. This gives some (but not all) of the benefits of actually merging with defaults.
  • Always remember that "don't commit configuration alongside code" does not mean "don't version your config files"- you can version them separately. Always structure your application so that "secret" information can be stored separately from configuration, to allow only the smallest subsets to go unversioned.
于 2012-09-17T21:08:49.620 に答える