我们有这样的工作流程：开发在dev.example.com上完成更改将提交到SVN，然后导出到活动站点。实时站点位于www.example.com
我想对dev.example.com进行密码保护，但如果我使用.htaccess，我们将在实时网站上使用相同的.htacccess，它也将受到密码保护。
我们使用的是Dreamhost共享主机，我有SSH访问权限，但我无法编辑Apache的configuration.conf文件。
我们不想有单独的.htaccess文件用于dev&live并忽略SVN中的.htaccess，因为对.htacccess也进行了更新。
那么我该怎么办呢？
如果服务器上启用了mod_setenvif，则可以将其添加到.htaccess文件中：
SetEnvIfNoCase ^HOST$ .+ unauthenticated
SetEnvIfNoCase ^HOST$ ^dev'.example'.com$ !unauthenticated
AuthType Basic
AuthName "Secured"
AuthUserFile /path/to/.htpasswd
Require valid-user
Order allow,deny
Allow from env=unauthenticated
Satisfy any
它的基本功能是设置一个名为"unauthenticated"的环境变量，但如果HOST（浏览器请求的主机）正是"dev.example.com"，则取消设置该变量。在Directory指令中，"满足任何"会告诉Apache，如果满足任何一个条件，则允许该请求。这意味着在"dev.example.com"上，环境变量不会被设置，因此，您需要一个密码。对于任何其他主机，都会设置变量，这样Apache就不会要求提供凭据。
您可以忽略.htaccess，将其完全排除在存储库之外。然后在每台服务器上有两个不同的.htaccess文件。因为它们被忽略了，所以它们不会在SVN更新中被覆盖。
在Apache虚拟主机配置中执行，而不是在.htaccess文件（通常在/etc/apache或/etc/apache2中）中执行
我把所有能进入.htaccess的东西都放在了这里。这些设置通常需要根据部署而有所不同，因此将它们保留在回购之外是有意义的。如果Apache能够在启动时加载指令，而不是在每次请求时从.htaccess文件加载指令，那么它也会让你的应用程序更快。
我通常也会在里面放一个这样的指令：SetEnv APP_ENV production
它将传递到您的应用程序，允许您检测您是否处于开发环境与生产环境中，并相应地调整您的设置。
我还将这个conf文件的副本检查到我的repo的assets文件夹中，以便于访问。
在存储库中放入两个文件：
- htaccess.dev
- htaccess.live
制作一个负责部署的脚本，首先将所有文件导出到目标服务器，然后根据导出到的服务器重命名正确的htaccess文件。该脚本应该很容易调用，一步完成整个部署，包括处理服务器的主机名等：
deploy dev或deploy live是两条很好的瞄准命令线
对于ssh登录，您必须从脚本中提示用户输入密码，或者更好的做法是使用基于密钥的身份验证，以便自动登录。
与其在远程服务器上开发，为什么不在本地机器上开发呢？您可以在repo中为每个dev创建分支，并在它们准备好推送到活动站点时将它们的更改与trunk合并。
您应该真正将开发环境和生产环境尽可能分离。我建议您重新评估使用共享.htaccess文件的最初愿望。根据我的经验，像.htaccess这样的服务器文件通常不会经常更新，因此不会对生产效率造成风险。
如果您使用的是虚拟主机，您可以将授权代码放在该文件（httpd或vhosts配置文件）中，这将允许您仍然使用共享的.htaccess文件。
@formicin，
我假设主要目标是让窥探者远离你的开发内容。
如果要在代码中实现逻辑（而不是通过Apache配置），则可以使用HTTP请求本身中指定的主机名。
$dev_server = "dev.mysite.com";
$hostname_used_to_access_site = $_SERVER['SERVER_NAME'];
if (strcasecmp($hostname_used_to_access_site, $dev_server) == 0) {
// The server name sent by the browser matches the name
// of the dev server, so check for a valid session. If
// the user hasn't already logged in, redirect to a
// login page.
}
这可以放在一个通用的包含文件中，也可以放在每个页面的顶部。请注意，dev和production之间的代码是相同的，但$_SERVER['SERVER_NAME']的值将导致登录代码仅在dev服务器上执行。
如果我错过了标记，或者你想澄清如何处理登录，请发表评论。
谢谢！
在文件头中导入文件include("permission.php")
在dev.example.com上：permission.php
<?PHP
// Do a password check
?>
在www.example.com上：permission.php
<?PHP
// Just an empty file
?>
在dev站点上，它将执行需要执行的密码操作，但在live站点上它将完全不执行任何操作。
两个简单的建议-都不需要.htaccess或服务器配置。
1） 如果你在Wordpress等CMS框架上构建，你可以简单地在开发网站上将网站的隐私设置（仪表板>设置）设置为密码保护，并且由于所有这些设置都是数据库管理的，你可以将实时网站设置为公共的。
或者。。。
2） 本地开发并推送至单独的密码保护安装。