如果您遵循应用程序在退出版本控制时应“开箱即用”运行的原则,.htaccess
则应包括在内。不过,这感觉有些不对劲,因为它并没有真正成为应用程序的一部分。我很矛盾,谁能让我放心?
2 回答
我通常会在源代码控制中保留应用程序的 .htaccess,其中包括应用程序运行所需的 Apache 配置,即重写不特定于运行它的服务器的规则、对环境变量的访问等。
以这种方式考虑 - 如果 .htaccess 文件包含应用程序使用的重写规则,则这些规则有效地作为应用程序路由的一部分,因此是应用程序的一部分。
如果您正在打包一个应用程序以供其他人下载和使用,您可能应该包含一个骨架 .htaccess 文件,其中包含使应用程序运行所需的规则。如果您的应用程序只打算在您自己的服务器上运行,并且您将所有相关的 Apache 配置保存在 .htaccess 中,而不是 VirtualHost 配置,我会说它确实属于源代码控制。
这对我们来说也是一个常见问题,我知道你所说的“感觉不对”是什么意思。
但是,对我来说,问题不在于感觉 .htaccess 不是应用程序的一部分,因为它的某些部分显然是。问题更多在于该文件将特定于应用程序的代码(路由等)与特定于安装的内容(本地 URL 重写、身份验证/访问规则等)混合在一起。理想情况下,您将版本控制特定于应用程序的规则,而不是特定于安装的规则,但这当然是不可能的,因为两者都需要在同一个文件中。
我可以想到四种管理方法。最佳方案将取决于您的特定情况(并且可能因项目而异):
- 如果您控制部署,Michael 的第二个建议是最佳选择。即,将特定于应用程序的代码保留在 .htaccess 文件中,受版本控制,并将任何特定于安装的代码保留在主 Apache VirtualHost 指令中。这提供了完全分离,但如果您无法直接访问主要 Apache 配置或分发给第三方,则不是一个可行的解决方案。
- 版本控制 .htaccess 文件中特定于应用程序的元素,使用清晰的注释标记,例如
### FOO APPLICATION SETTINGS - DO NOT CHANGE ###
,### ADD ANY ADDITIONAL LOCAL CONFIG BELOW THIS LINE ####
并且不要对安装特定的任何内容进行版本控制。如果规则足够简单而不会真正引起冲突,这很好,但如果您的骨架文件需要用户修改现有行,则这不是很好,因为您可能最终会遇到合并冲突。如果部署是受版本控制的(至少对于开发版本来说可能是这种情况),它还会冒不必要的编辑进入您的存储库的风险,并且如果不是这样,它会冒本地更改被升级吹走的风险(例如公共zipfile 分发)。 - 我们决定作为一个很好的替代方案是对一个名为的文件进行版本控制,该文件
.htaccess.sample
可以包含特定于应用程序的规则和(在相关时)用户可能会发现有用的安装特定规则的建议。无论是否使用版本控制,这都易于维护和部署,但会使升级稍微困难一些,因为用户需要手动将任何更改合并到他们的本地.htaccess
文件中。在我们的案例中,升级总是由开发人员完成,因此这不是一个大问题,假设有适当的差异工具可用。 - 与 #3 相同,除了您还提供了一个脚本来自动应用任何修改。设置更多的工作,不一定需要更多的维护工作,这取决于你如何实现它(例如,如果它只是替换一些标记之间的代码块),如果你要分发给广泛的用户群,可能值得。例如,这就是 Wordpress 所做的。