.htaccess应该在源代码管理中进行版本化吗？

Question

如果您遵循以下原则：应用程序应在退出版本控制时“开箱即用”运行，则应包含.htaccess。但是有些事情并不合适，因为它并不真正感觉应用程序的 part 。我有冲突，有人会让我放心吗？

Answer 1

我通常会在源代码管理中保留一个应用程序的.htaccess，其中包括运行应用程序所需的Apache配置，即重写规则，这些规则并非特定于运行它的服务器，访问环境变量等。

以这种方式考虑 - 如果.htaccess文件包含应用程序使用的重写规则，那些文件有效地作为应用程序路由的一部分运行，因此 是应用程序的一部分。

如果要打包供其他人下载和使用的应用程序，则应该包含一个骨架.htaccess文件，其中包含使应用程序运行所需的规则。如果您的应用程序仅用于在您自己的服务器上运行，并且您将所有相关的Apache配置保存在除VirtualHost配置之外的.htaccess中，我会说它确实属于源代码管理。

Answer 2

这对我们来说也是一个常见问题，我知道您对“不正确”的意思。

但是，对我而言，问题并不在于感觉.htaccess并非应用程序的一部分，而是其中的一部分。问题更多在于该文件将特定于应用程序的代码（路由等）与特定于安装的内容（本地URL重写，身份验证/访问规则等）混合在一起。理想情况下，您将版本控制特定于应用程序的规则，而不是版本特定于安装的规则，但是当然这是不可能的，因为两者都需要位于同一文件中。

我可以想到四种管理方法。最佳的选择取决于您的具体情况（并且可能因项目而异）：

1. 如果您控制部署，迈克尔的第二个建议是最好的选择。即，在版本控制下，将应用程序特定的代码保留在.htaccess文件中，而主Apache VirtualHost指令中保留所有安装特定的代码。如果您无法直接访问主要的Apache配置或正在分发给第三方，则可以完全隔离，但不是可行的解决方案。
2. 版本控制.htaccess文件的应用程序特定元素，并带有清晰的注释标记，例如### FOO APPLICATION SETTINGS - DO NOT CHANGE ###和### ADD ANY ADDITIONAL LOCAL CONFIG BELOW THIS LINE ####不会版本特定于安装的任何版本。如果规则足够简单以至于不会真正引起冲突，那么很好，但是如果您的骨骼文件要求用户修改现有行，那么就不好了，因为您很可能最终会沿行合并冲突。如果部署是受版本控制的（至少可能是开发版本的情况），它还存在不必要的编辑进入您的存储库的风险，并且如果不进行升级，则存在本地更改被升级吹散的风险（例如，公共的） zip文件分发。）
3. 我们选择的一个不错的选择是对名为.htaccess.sample的文件进行版本控制，该文件可以包含特定于应用程序的规则以及（可能相关的）针对特定安装规则的建议，这些建议可能对用户有用。无论是否使用版本控制，这都易于维护和部署，但是由于用户需要将所有更改手动合并到其本地.htaccess文件中，因此升级会稍微困难一些。在我们的案例中，升级总是由开发人员完成，因此，假设有合适的差异工具可用，这不是大问题。
4. 与＃3相同，不同之处在于您还提供了一个脚本来自动应用所有修改。根据您的实现方式（例如，如果它只是替换某些标记之间的代码块），需要进行更多的设置工作，而不必维护更多的工作，并且如果您要分发给广泛的用户群，则可能值得这样做。例如，Wordpress就是这样做的。