如何实用地对配置文件进行版本控制?

发布于 2024-08-16 10:32:52 字数 683 浏览 6 评论 0原文

假设我们有一个包含敏感密码的配置文件。我想对整个项目进行版本控制,包括配置文件,但我不想共享我的密码。
那就太好了

database_password=secret
foo=bar

如果这个配置文件:变成

database_password=*
foo=bar

并且 vcs 的其他用户也可以自己设置密码, 。忽略该文件不是一个好方法,开发人员应该意识到配置文件是否发生更改。

示例:

本地版本:

database_password=own_secret
foo=bar

vcs 中的配置文件:

database_password=*
foo=bar

然后突然,配置文件发生变化:

database_password=*
foo=bar
baz=foo

对于每个开发人员来说,本地版本将变为:

database_password=own_secret
foo=bar
baz=foo

这是我的解决方案。我怎样才能实现这种行为?你如何存储你的配置文件?有没有办法做到这一点,或者我应该破解一些东西?

Suppose we have a config file with sensitive passwords. I'd like to version control the whole project, including the config file as well, but I don't want to share my passwords.
That could be good, if this config file:

database_password=secret
foo=bar

becomes

database_password=*
foo=bar

and the other users of the vcs could also set up the password on they own. To ignoring the file isn't a good approach, the developers should be aware, if the config file changes.

Example:

Local version:

database_password=own_secret
foo=bar

config file in vcs:

database_password=*
foo=bar

Then suddenly, the config file changes:

database_password=*
foo=bar
baz=foo

And the local version would become for each developer:

database_password=own_secret
foo=bar
baz=foo

This is my solution. How could I achieve this behaviour? How do you store your config files? Is there a way to do that, or should I hack something?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(9

晨曦慕雪 2024-08-23 10:32:52

您可以在版本控制中放置一个模板或默认文件,以及一个要求数据库信息和凭据以生成真实配置文件的脚本,而不是对实际配置文件进行版本控制,该文件将被排除在外(即被忽略)版本控制。结账时,开发人员可以运行此脚本来获得工作环境。该脚本也可以作为应用程序使用的任何安装过程的一部分来调用。

另请参阅我对类似问题的回答。

Instead of version-controlling the actual configuration file, you could put a template or defaults file in version control, and a script that would ask for DB information and credential to generate the real config file, which would be excluded from (i.e. ignored by) version control. On checkout, developers could run this script to get a working environment. This script could also be invoked as part of any installation process that your application uses.

Also see my answer to a similar question.

余生再见 2024-08-23 10:32:52

不确定你的配置是如何实现的,但我将如何处理这个问题,使用分层覆盖。

您有一个主配置,其中包含通用配置以及虚拟用户名/密码(或完全忽略这些)。然后,每个开发人员使用其特定的用户名/密码创建本地 override.config(或其他内容)。主要配置受源代码控制,开发人员(或机器)本地覆盖则不受源代码控制。

我已经在 .NET 中完成了此操作,但没有在 PHP 中完成,所以我担心这有多容易。

Not sure how your config is implemented, but having hierarchical overides is how I would handle this.

You have a main config that contains common config plus dummy username/password (or leave these out altogether). Each developer then creates a local override.config (or whatever) with their specific username/password. The main config goes under source control, the developer (or machine) local overrides do not.

I've done this in .NET but not PHP so I don't know how easy this would be I'm afraid.

烟若柳尘 2024-08-23 10:32:52

创建一个本地覆盖文件,其中包含用户特定信息作为 PHP 变量。

例如,创建一个名为 local_overrides.php 的文件,其中包含以下内容:

$local_password = 'qUzaEAFK13uK2KHy';

然后在包含数据库密码的文件中执行类似以下

$overrides = 'local_overrides.php';

if (file_exists($overrides)) {
   #include_once($overrides);
   $db_password = $local_password;
} else {
   // perform appropriate action: set default? echo error message? log error?    
   $db_password = 'l1m1t3d!'
}

操作 源代码管理永远不会看到本地覆盖文件。

Create a local overrides file that contains the user specific info as PHP variables.

For instance create a file called local_overrides.php which contains the following:

$local_password = 'qUzaEAFK13uK2KHy';

Then in the file that includes your DB password do something like this

$overrides = 'local_overrides.php';

if (file_exists($overrides)) {
   #include_once($overrides);
   $db_password = $local_password;
} else {
   // perform appropriate action: set default? echo error message? log error?    
   $db_password = 'l1m1t3d!'
}

The local overrides file would never has to be seen by source control.

终难遇 2024-08-23 10:32:52

有一个单独的文件,其中仅包含机密,不受版本控制?

或者理想情况下,完全使用 openssh 或类似的方式取消密码,并为每个用户进行公钥/私钥身份验证。

Have a separate file with ONLY the secrets in, that isn't under version control?

Or ideally, do away with passwords entirely use openssh, or similar, and do public/private key authentication for each user.

请持续率性 2024-08-23 10:32:52

是否可以使用预提交挂钩来清除敏感字段?当然,这假设您首先愿意通过网络发送文件。

问题另一端的更新:
要处理更新,您要么想要强制手动合并敏感文件,要么修改本地构建过程以使用本地/私有/忽略文件中的内容覆盖敏感行。

What about a pre-commit hook to blank out sensitive fields? This assumes you're comfortable sending the file over the network in the first place, of course.

Update for the other end of the problem:
To handle updates, you'd either want to force a manual merge of the sensitive files, or modify the local build process to overwrite the sensitive lines with contents from a local/private/ignored file.

来世叙缘 2024-08-23 10:32:52

我习惯用配置文件的结构制作一个txt文件。
之后,我将制作一个副本并更改扩展名,让我的版本控制系统忽略该文件。

因此,当您在配置文件中进行更改时,只需更新它的 txt 版本即可。
这是我能想到的唯一选择,也是逻辑的(在我看来)

I'm used to make a txt file of it with the structure of the configfile.
And after that I'll make a copy and change the extension and let my version control system ignore this file(s).

So when you make changes in the config file, just update the txt version of it.
That's the only option I can think of which is logic as well (in my eyes)

强者自强 2024-08-23 10:32:52

我对此的首选答案已经在这里提到:签入虚拟文件,通过在运行时复制虚拟文件来生成“真实”文件,并忽略 VCS 中的“真实”文件。

我已经回答了类似的问题,并提供了如何在 Visual Studio 中执行此操作的完整示例:
如何使用 tortoise hg 忽略 kiln/mercurial 中的文件“属于存储库的一部分”

My preferred answer to this was already mentioned here: check in a dummy file, generate the "real" file by copying the dummy file at runtime, and ignore the "real" file in your VCS.

I already answered a similar question, with a complete example how to do this in Visual Studio:
how to ignore files in kiln/mercurial using tortoise hg "that are part of the repository"

落日海湾 2024-08-23 10:32:52

在我的项目中,我使用一个目录来保存这些类型的文件,但它没有上传到服务器,因此我的数据库配置文件位于该目录中,并且是为项目所在的服务器配置的。
如果有人更改配置文件,他将更改服务器配置文件,任何更新修订版的人都会看到该文件中的更改,并且需要手动更改其本地配置。

我没有看到除此之外的其他方法。如果您发现不同的方法,请分享。

In my projects I use a directory that holds these kinds of files but it's not uploaded to server, so my db config file is in that directory and it is configured for server where the project is placed.
If someone changes config file he will change server config file and anyone updating revision will see changes in that file and will need to manually change his local config.

I don't see a way of doing it rather than that. If you find a different approach please share.

指尖微凉心微凉 2024-08-23 10:32:52

我有类似的东西,虽然我不知道它是否适合你。我有一个目录,其中包含包含密码的文件。该目录不受版本控制。这些文件以使用它们的应用程序命名,并且在配置文件中,我在需要时“获取”了适当的密码文件。这将要求您的配置解析器能够处理采购。

I had something similar to this although I don't know if it would work for you. I had a directory that contained files that contained passwords. This directory was not version controlled. The files were named after the applications which used them and in the config files, I 'sourced' the appropriate password file at the point it was needed. This would demand that your config parser can handle sourcing.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文