git 你如何处理源代码控制中的配置文件？

How do you deal with configuration files in source control?

提问by deadprogrammer

Let's say you have a typical web app and with a file configuration.whatever. Every developer working on the project will have one version for their dev boxes, there will be a dev, prod and stage versions. How do you deal with this in source control? Not check in this file at all, check it with different names or do something fancy altogether?

假设您有一个典型的 Web 应用程序和一个文件 configuration.whatever。每个参与该项目的开发人员都将有一个用于他们的开发箱的版本，将有一个开发、生产和阶段版本。你如何在源代码管理中处理这个问题？根本不签入这个文件，用不同的名字来检查它还是干一些花哨的事情？

采纳答案by yukondude

What I've done in the past is to have a default config file which is checked in to source control. Then, each developer has their own override config file which is excluded from source control. The app first loads the default, and then if the override file is present, loads that and uses any settings from the override in preference to the default file.

我过去所做的是有一个默认配置文件，该文件已签入源代码管理。然后，每个开发人员都有自己的覆盖配置文件，该文件被排除在源代码管理之外。应用程序首先加载默认值，然后如果存在覆盖文件，则加载该文件并优先使用覆盖中的任何设置而不是默认文件。

In general, the smaller the override file the better, but it can always contain more settings for a developer with a very non-standard environment.

一般而言，覆盖文件越小越好，但对于具有非常非标准环境的开发人员而言，它始终可以包含更多设置。

回答by davetron5000

Configuration iscode, and you should version it. We base our configuration files on usernames; in both UNIX/Mac and Windows you can access the user's login name, and as long as these are unique to the project, you are fine. You can even override this in the environment, but you shouldversion control everything.

配置就是代码，您应该对其进行版本控制。我们的配置文件基于用户名；在 UNIX/Mac 和 Windows 中，您都可以访问用户的登录名，只要这些是项目唯一的，就可以了。您甚至可以在环境中覆盖它，但您应该对所有内容进行版本控制。

This also allows you to examine others' configurations, which can help diagnose build and platform issues.

这还允许您检查其他人的配置，这有助于诊断构建和平台问题。

回答by Grant

Don't version that file. Version a template or something.

不要版本那个文件。版本模板什么的。

回答by Brandon Wood

My team keeps separate versions of the config files for each environment (web.config.dev, web.config.test, web.config.prod). Our deployment scripts copy out the correct version, renaming it to web.config. This way, we have full version control on the config files for each environment, can easily perform a diff, etc.

我的团队为每个环境（web.config.dev、web.config.test、web.config.prod）保留了不同版本的配置文件。我们的部署脚本复制正确的版本，将其重命名为 web.config。这样，我们对每个环境的配置文件都有完整的版本控制，可以轻松地执行差异等。

回答by Damien Diederen

+1 on the template approach.

+1 在模板方法上。

But since this question has tag Git, the distributed alternative springs to mind, in which customizations are kept on a private testing branch:

但是由于这个问题有标记 Git，所以我想到了分布式替代方案，其中自定义保留在私有测试分支上：

A---B---C---D---           <- mainline (public)
     \       \
      B'------D'---        <- testing (private)

In this scheme, the mainline contains a generic, "template" config file requiring the minimal amount of adjustments to become functional.

在这个方案中，主线包含一个通用的“模板”配置文件，需要最少的调整才能发挥作用。

Now, developers/testers can tweak the config file to their heart's content, and only commit these changes locally on one a private testing branch (e.g. B' = B + customizations). Each time mainline advances, they effortlessly merge it into testing, which results in merge commits such as D' (= D + merged version of B's customizations).

现在，开发人员/测试人员可以将配置文件调整到他们想要的内容，并且只在一个私有测试分支上本地提交这些更改（例如 B' = B + 自定义）。每次主线推进时，他们都会毫不费力地将其合并到测试中，从而导致合并提交，例如 D'（= D + B 自定义的合并版本）。

This scheme really shines when the "template" config file is updated: the changes from both sides get merged, and are extremely likely to result into conflicts (or test failures) if they are incompatible!

当“模板”配置文件更新时，这个方案真的很出色：来自双方的更改合并，如果它们不兼容，极有可能导致冲突（或测试失败）！

回答by GateKiller

Currently I have the "template" config file with an added extension for example:

目前我有一个添加了扩展名的“模板”配置文件，例如：

web.config.rename

However, I can see an issue with this method if critical changes have changed.

但是，如果关键更改发生了变化，我会发现此方法存在问题。

回答by Jason Stevenson

The solution we use is to have only the single configuration file (web.config/app.config), but we add a special section to the file that contains settings for all environments.

我们使用的解决方案是只有一个配置文件 (web.config/app.config)，但我们在包含所有环境设置的文件中添加了一个特殊部分。

There is a LOCAL, DEV, QA, PRODUCTIONsections each containing the configuration keys relevant to that environment in our config file(s).

在我们的配置文件中有一个LOCAL、DEV、QA、PRODUCTION部分，每个部分都包含与该环境相关的配置键。

What make this all work is an assembly named xxx.Environmentwhich is referenced in all of our applications (winforms and webforms) which tells the application which environment it is operating on.

使这一切正常工作的是一个名为xxx.Environment的程序集，它在我们所有的应用程序（winforms 和 webforms）中都被引用，它告诉应用程序它正在运行的环境。

The xxx.Environment assembly reads a single line of information from the machine.configof the given machine which tells it that it is on DEV, QA, etc. This entry is present on all of our workstations and servers.

xxx.Environment 程序集从给定机器的machine.config中读取一行信息，告诉它它在 DEV、QA 等上。这个条目存在于我们所有的工作站和服务器上。

Hope this helps.

希望这可以帮助。

回答by HymanAce

I have always kept all versions of the config files in source control, in the same folder as the web.config file.

我一直将所有版本的配置文件保存在源代码管理中，与 web.config 文件位于同一文件夹中。

For example

例如

web.config
web.qa.config
web.staging.config
web.production.config

I prefer this naming convention (as opposed to web.config.production or production.web.config) because

我更喜欢这种命名约定（而不是 web.config.production 或 production.web.config），因为

• It keeps the files together when you sort by file name
• It keeps the files together when you sort by file extension
• If the file accidentally gets pushed to production, you won't be able to see the contents over http because IIS will prevent *.config files from being served

• 当您按文件名排序时，它会将文件保存在一起
• 当您按文件扩展名排序时，它会将文件保存在一起
• 如果文件不小心被推送到生产环境，您将无法通过 http 查看内容，因为 IIS 将阻止提供 *.config 文件

The default config file should be configured such that you can run the application locally on your own machine.

应配置默认配置文件，以便您可以在自己的机器上本地运行应用程序。

Most importantly, these files should be almost 100% identical in every aspect, even formatting. You shouldn't use tabs in one version and spaces in another for indenting. You should be able to run a diff tool against the files to see exactly what is different between them. I prefer to use WinMerge for diffing the files.

最重要的是，这些文件在各个方面都应该几乎 100% 相同，甚至是格式。您不应该在一个版本中使用制表符，而在另一个版本中使用空格来缩进。您应该能够对这些文件运行 diff 工具，以准确查看它们之间的不同之处。我更喜欢使用 WinMerge 来区分文件。

When your build process creates the binaries, there should be a task that overwrites the web.config with the config file appropriate for that environment. If the files are zipped up, then the non relevant files should be deleted from that build.

当您的构建过程创建二进制文件时，应该有一个任务用适合该环境的配置文件覆盖 web.config。如果文件被压缩，则应从该构建中删除不相关的文件。

回答by Andy Whitfield

I've used the template before, i.e. web.dev.config, web.prod.config, etc, but now prefer the 'override file' technique. The web.config file contains the majority of the settings, but an external file contains environment-specific values such as db connections. Good explanation on Paul Wilson's blog.

我以前使用过模板，即 web.dev.config、web.prod.config 等，但现在更喜欢“覆盖文件”技术。web.config 文件包含大部分设置，但外部文件包含特定于环境的值，例如数据库连接。Paul Wilson 的博客上有很好的解释。

I think this reduces the amount to duplication between the config files which can cause pain when adding new values / attributes.

我认为这减少了配置文件之间的重复数量，这在添加新值/属性时可能会导致痛苦。

回答by Tom

@Grant is right.

@Grant 是对的。

I'm on a team with close to 100 other developers, and our config files are not checked into source control. We have versions of the files in the repository that are pulled with each check out but they don't change.

我所在的团队有近 100 名其他开发人员，我们的配置文件未签入源代码管理。我们在每次签出时都会提取存储库中的文件版本，但它们不会更改。

It's worked out pretty well for us.

对我们来说效果很好。