Question

在任何项目中至少有一个配置文件是很常见的。每次我与git分享项目时，我都会遇到同样的问题：

显然，必须以某种方式忽略配置，以防止开发人员特定数据泛滥到主存储库。现在有几种我常用的方法，每种方法都有一些缺陷：

.gitignore配置文件
- 最基本的方式
- 当开发人员克隆repo时，配置文件丢失，并且必须找出配置重新创建的位置
配置文件不会被忽略。它包含一些虚拟信息，每个开发人员都要解开并将其放入.git/info/exclude或将git update-index --assume-unchanged ...设置为文件
- 文件可供克隆回购的任何人使用
- 它包含的高级技术可能会让第一次使用git的人感到困惑
- 当有人意外提交配置文件时，它不允许人们提取/获取（因为排除不像.gitignore那样工作）
在_original中包含真实文件时，分发以.gitignore为后缀的配置文件。然后每个开发人员将文件重命名为真实姓名
- 文件可供克隆回购的任何人使用
- 必须在整个应用程序中搜索所有配置并重命名

还有其他可能更好的方法来解决这个问题吗？我怀疑我错过了一些东西，至少是一些插件。

Answer 1

enter image description here

smudge 脚本将在结帐时显示：

从那里开发人员可以对这些配置文件进行任何类型的修改这没关系，因为 clean 脚本在提交时会将该文件的内容恢复为其原始（模板）值。没有意外的推动。

Answer 2

我们在上一个项目中完成它的方式是有一个主配置文件，如果它存在则加载用户本地配置文件，如果指定，它可能会覆盖master中设置的默认值并声明它自己的配置信息如果没有在主人。本地文件已添加到gitignore。这样所有常见的东西都可以共享，一些配置总是存在，每个开发人员都可以修改他们的本地。

Answer 3

由于我花了一些时间来找出一个有@VonC提示的工作解决方案，这里有一个完整的例子，说明如何在Objective-C头文件中使用git clean过滤器忽略密码。

假设您有一个名为Config.h的默认配置脚本，其中包含此

// Change "12345" to your password
#define kPass @"12345"
#define kConstant 42

创建与关键行匹配的脚本hidepass.sh并打印默认行

#!/bin/sh
awk '{ if (/#define kPass/) print "#define kPass @\"12345\""; else print $0; }'
exit 0

使脚本可执行并将其添加到仓库
告诉git过滤您的配置文件，将此行添加到.gitattributes（同时将.gitattributes添加到您的仓库）
```
Config.h filter=hidepass
```
告诉git在清理期间使用 hidepass 过滤器的hidepass.sh脚本：
```
git config filter.hidepass.clean ./hidepass.sh
```

就是这样，您现在可以在Config.h中更改密码，但是git不会提交此更改，因为它总是用checkin上的默认行替换该行。

这是单行密码的快速解决方案，您可以发疯，例如使用特殊字符串结束要忽略的行，并检查具有该字符串的行。

Answer 4

在我曾经的项目中，我们有一个默认配置，开发人员在版本控制之外的特定位置（配置约定）有自己的配置 - 后者的值用于覆盖前者的值。

如果是git，您可以查看git attributes filter attribute以自动方式替换本地值和解密敏感值。

你也可以让子模块说production.yml并且对子模块仓库有限制访问权。

Answer 5

我能想到的一件事情与上面的方法2和方法1类似。您有一个目录，您可以在其中存储网站特有的复杂内容，例如配置文件的目录，用户上传的文件等。

您只保留配置文件本身不受版本控制，但是您的虚拟副本的名称与网站实际使用的略有不同，此文件包含有关配置参数的详细说明以及重命名的副本

例如，假设您有一个“site_profile”目录。在此目录中，您将创建一个名为“README.settings.php”的文件以及一个包含用户上载文件（来自管理员和前端用户）的“files”目录。所有这些都受版本控制。

但是，该站点将从“settings.php”运行其设置，此处不存在。但是，如果您要将“README.settings.php”重命名为“settings.php”，那么您将拥有所需的配置文件（当然，在您输入自定义设置之后）。

这将允许您告诉其他开发人员他们的配置文件需要什么，同时保持您自己的配置文件不混合。只需将您的配置文件设置为被忽略，或者永远不要为该目录进行全面提交并降低。

我们在Drupal网站上的工作方式非常好。

Answer 6

对于你提到的两个案例：

敏感信息（每个开发人员都有不同的数据库密码等）

编写脚本，以便将这些敏感文件存储在开发人员的主目录中，而不是存储在项目目录中。
任务特定信息（当开发人员处理需要更改某些设置的特定任务时）

我通常会将默认设置检入存储库，然后在准备提交时，您可以轻松检查是否已修改任何这些设置，并在提交之前将其还原。

Answer 7

我将本地配置更改保存到git存储区。我使用git stash apply而不是pop，所以我永远不会从存储队列中删除它。这样我就可以随时使用reset --hard。

Answer 8

没有使用Git的经验，但是在其他上下文（Spring JUnit套件中的Hibernate登录信誉，或ANT脚本）中处理相同的问题，对于任何特定于用户或依赖于用户的本地环境的事情： / p>

列出这些依赖项以及如何配置本地环境以运行脚本的自述文件。
使用对系统属性的调用替换conf中的这些依赖项，或者使用某种框架方式来获取外部值。例如，在ANT脚本中，您可以用<sysproperty key="jdbc.username" value="${jdbc.username}"/>替换字符串，其中jdbc.username是系统变量（可以在Eclipse中设置）。

开发人员可以检查他们想要的任何内容，因为conf与用户无关。

Answer 9

列出了很多好的选择。还有一些选择：

将所有配置添加到.gitignore。然后有一个单独的 git项目，只有配置文件。（将此GIT＃2保存在完全不同的文件夹中。）在此GIT＃2中，制作一些类似于apply-config /path/to/my_git1，save-config /path/to/my_git1的脚本，这些脚本可以复制或保存主GIT仓库的配置文件。
- 我更喜欢使用子模块。我发现在大型团队中使用子模块很麻烦。
- 然后，您可以跟踪配置，或使用多个GIT仓库进行生产设置，调试设置，更优化的设置等内容。
- 使用每个人都能理解的工具（GIT）。
我喜欢在主文件夹中查找数据库连接信息等敏感信息。（由@avh提及）
对于devOps，您可能需要考虑使用Ansible / Salt / Chef / Puppet等自动部署和设置。

Answer 10

由The Twelve-Factor App推广的另一个非常常见的选项是不将任何配置变量硬编码到文件中，而是从环境变量加载它们。这样，存储库中的文件不需要任何特殊处理。