在我的研究中，我发现在部署在线 PHP 应用程序时将其“.hg”文件夹或“.svn”文件夹保留在生产服务器上存在一些问题。不幸的是，我无法找到一个明确的解释来解释为什么这是一个问题。我想更好地了解这种安全风险。
在我看来，您不希望这些文件夹可见，就像您不希望显示 PHP 文件的内容一样。解决方案不是将 Web 服务器配置为不提供“.hg”目录吗？安全问题是否比这更严重？我真的不知道。非常感谢您对此的帮助!
如果有帮助的话，我想在服务器的生产存储库上保留版本控制的原因如下:
- 从暂存中进行更快的部署(相对于每次部署都创建一个新副本)
- 轻松快速的回滚功能
- 能够验证产量是否保持不变(通过
hg st)
欢迎替代方案。
谢谢!
最佳答案
确实，如果有人可以信赖不服务 .svn/.hg默认目录下就没有问题了。事实上，有人(新手/新开发者/在糟糕的一天经历过)做了一点改变，破坏了这些设置，并且“没有出问题”并没有注意到保护已经消失。瞧，您的源代码向全世界开放，甚至可能还存储了密码和 secret 。这并不是说正确的设置会出问题，而是只要进行微小的、容易被掩盖的改变，它们就可能会出问题，所以为什么不谨慎行事呢？
在严格控制的发布过程中，我发现更容易export某些分支/标签到某些文件夹，并且切换到已通过测试的较新的分支/标签只是将文档根从 /path/project/release-123 更改。至/path/project/release-124 (如果需要的话，切换回 release-123 也同样容易，甚至更快)。如果您的发布过程包含更多的小更改和错误修复，那么使用导出确实会很痛苦，但在我看来，增加的安全性是值得的。
在开发服务器上，所有内容都已在(VPN-)IP 或证书上进行过滤，因此我使用“最新和最好的”主干版本与版本控制目录进行结帐，没有任何问题。
编辑:
如今，Mercurial 和 Subversion 都将数据保存在顶层的单个 .hg/.svn 目录中。由于人们通常会在大多数文件位于文档根目录外部(并且文档根目录可能是更下面的子目录)的情况下进行 checkout ，因此这是很好的。只需确保您的版本控制目录不在文档根目录内的网络服务器可访问的文件夹中，并且您可以保持 checkout 而不是导出到那里，而不会出现太多问题。
关于php - 将 Mercurial 存储库部署到生产环境 - 安全问题和提示，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/3867646/