为什么开发人员提交 .dist 文件而不是实际文件？答案

【问题标题】：Why do developers commit .dist files instead of the actual file?为什么开发人员提交 .dist 文件而不是实际文件？
【发布时间】：2017-09-09 21:21:05
【问题描述】：

为什么开发人员会提交 .dist 文件而不是实际文件？

例如： https://github.com/FriendsOfPHP/PHP-CS-Fixer

.php_cs.dist
phpunit.xml.dist

https://github.com/symfony/symfony

.php_cs.dist
phpunit.xml.dist

为什么.php_cs 和phpunit.xml 被提交为.dist 文件？

代码格式规则在.php_cs.dist，如果每个贡献者都应该遵循相同的规则，为什么.dist 文件？

更新

parameter.yml.dist 背后的推理是显而易见的，但为什么特别是 .php_cs 没有被承诺？为什么有人会更改包含代码格式规则的.php_cs？ .php_cs 的重点不是每个贡献者都使用相同的规则来格式化他们的代码吗？

请仅回复这两个文件。

【问题讨论】：

见my answer to a somewhat different question。
".dist" 通常表示“此文件适合分发，但不适合实际使用”。这意味着这是一个模板文件，实际文件也可能在该存储库中被忽略。在本地，克隆后，您应该复制 .dist 文件，删除 .dist 部分，并对它进行适当的更改以使软件在您的系统上运行。
parameter.yml.dist 背后的原因很明显，但为什么特别是 .php_cs 没有提交？为什么有人会更改包含代码格式规则的 .php_cs ？ .php_cs 的重点不是每个贡献者都使用相同的规则来格式化他们的代码吗？

标签： git symfony version-control

【解决方案1】：

您可以将.dist 文件视为模板文件。在您的特定发行版上，配置可能略有不同。使用 dist 文件，您可以简单地将它们复制到例如phpunit.xml 并对其进行调整以满足您的需求。（例如设置一些特定的 ENV 变量等）。

小旁注：Symfony 项目中另一个常见的 dist 文件是 app/config/parameters.yml.dist

【讨论】：

parameter.yml.dist 背后的原因很明显，但为什么特别是 .php_cs 没有提交？为什么有人会更改包含代码格式规则的 .php_cs ？ .php_cs 的重点不是每个贡献者都使用相同的规则来格式化他们的代码吗？

【解决方案2】：

我在这里找到了答案：https://github.com/symfony/recipes/issues/41

不同之处在于 PHPUnit 会加载 phpunit.xml.dist 文件，如果 phpunit.xml 不存在。所以你不需要复制它，除非你想做特别的事情。所以在 repo 中提交一个 phpunit.xml.dist （并在 gitignore 中添加 phpunit.xml）只是遵循 PHPUnit 最佳实践

这些特定文件的 .dist 文件背后的原因是 phpunit 和 php-cs-fixer 在没有本地文件的情况下使用 .dist 文件。

【讨论】：

【解决方案3】：

因为这样做会在本地（通常是“开发”）和远程配置之间产生差异。这也让您可以保护您的私人数据，而不会忘记设置所需的参数。

例如，symfony 有一个“parameters.yml”文件和一个“parameters.yml.dist”文件。您的参数包含真实数据，用于您的实际环境，如果您尊重良好实践，则永远不会提交，因为您将推送一个包含您的数据库名称、用户名、邮件主机和所有类型的绝对敏感数据的文件（使用的秘密令牌形式）。

所以，你有一个 dist 文件，包含相同的键，但没有值：

示例：参数.yml：

# This file is auto-generated during the composer install
parameters:
    database_host: mysql
    database_port: null
    database_name: portfolio
    database_user: artandor
    database_password: supersecretpassword
    mailer_transport: smtp
    mailer_host: smtp.gmail.com
    mailer_user: artandor
    mailer_password: supersecretaswell
    secret: 070950937b085d66fb1c59978ab9c47d4a420e32

你的 dist 文件看起来像：

# This file is a "template" of what your parameters.yml file should look like
# Set parameters here that may be different on each deployment target of the app, e.g. development, staging, production.
# https://symfony.com/doc/current/best_practices/configuration.html#infrastructure-related-configuration
parameters:
    database_host: 127.0.0.1
    database_port: ~
    database_name: symfony
    database_user: root
    database_password: ~
    # You should uncomment this if you want to use pdo_sqlite
    #database_path: '%kernel.project_dir%/var/data/data.sqlite'

    mailer_transport: smtp
    mailer_host: 127.0.0.1
    mailer_user: ~
    mailer_password: ~

    # A secret key that's used to generate certain security-related tokens
    secret: ThisTokenIsNotSoSecretChangeIt

抱歉发了这么长的帖子，想给你说清楚:)

通常的过程是推送 dist 文件，然后将其拉到服务器上后，制作 cp parameters.yml.dist parameters.yml

除了保护数据之外，其他原因是本地应用程序和已部署应用程序之间的配置不同。

再见:)

【讨论】：

parameter.yml.dist 背后的原因很明显，但为什么特别是 .php_cs 没有提交？为什么有人会更改包含代码格式规则的 .php_cs ？ .php_cs 的重点不是每个贡献者都使用相同的规则来格式化他们的代码吗？
我不确定这个具体的例子，但考虑到代码编写中有很多规则和标准，我认为这允许人们格式化代码以适应他们的习惯；同时仍提供“推荐”格式（包含在 dist 文件中）。你也可以扭转这个：提交的人不喜欢用默认规则编写他的代码，他使用他自己的配置，但不推送它，所以你得到一个干净的配置文件。

【解决方案4】：

php_cs.dist也是一样的道理，你可以在本地php_cs自定义规则，需要分析的文件和目录，而不是使用命令行选项自定义规则等等：例如--dry-run选项显示需要修复但没有实际修改的文件：

$ php php-cs-fixer.phar fix /path/to/code --dry-run

可用的选项等here 可以在 .php_cs 本地文件中设置。

【讨论】：