我会考虑使用 git 进行部署非常好的做法。

您列出的两个问题与使用 git 进行部署本身几乎没有关系。替换.git/包含数据库密码的配置文件，您会遇到同样的问题。如果我对您的 Web 根目录具有读取权限，则我对其中包含的任何内容都具有读取权限。这是一个服务器强化问题，您必须与系统管理员讨论。

git 在安全性方面提供了一些非常有吸引力的优势。

1. 您可以强制实施系统以部署到生产环境。我什至会配置一个post-receive钩子，以便在提交时自动部署到生产环境master。我当然假设一个类似于git flow的工作流程。

2. 如果出现安全问题，git 可以非常容易地将部署在生产环境中的代码回滚到以前的版本。这有助于阻止对您需要时间正确修复的关键任务安全漏洞的访问。

3. 您可以强制执行一个系统，您的开发人员必须签署他们所做的提交。如果发现故意的安全漏洞，这可以帮助追踪谁将什么部署到生产环境。

从 git repo 部署没有什么问题，实际上这是一种非常普遍的做法，正如您所说，与通过 ftp 或 rsync 复制文件相比，它更不容易出错。

鉴于您提供的信息，我会注意以下几点：

• 不要只拉入最新的大师。生产应从发布标签部署。使用git flow或类似工具来获得更多关于代码部署和标签创建的过程。因为标签是在给定时间对您的代码的不可变引用，所以它比指向可能由错误提交更新的主分支更稳定。

• 至于为 .git 目录提供服务，这应该不是什么大问题。只需将任何以 .git 为前缀的内容重定向到 .htaccess 中的 404。

• 您的 git 身份验证应该基于 ssh 密钥，因此不需要在服务器上存储 repo 密码。

为 git 部署工作流欢呼！

我将不同意这里的流行观点。Git 用于版本控制，而不是用于部署/CI。

人们在这里提倡的方法适用于小型项目，但一般来说，不能很好地扩展。

...这并不是说你不应该继续做你正在做的事情。请记住，随着您的职业发展，您正在从事的项目可能会超出纯粹基于 git 的部署工作流程。

范式的主要转变是停止考虑部署分支，并开始考虑部署构建结果，并注入环境依赖项以将基础架构与分支策略分离。

例如，使用上面关于“部署文件”和回滚的范例。如果您正在部署文件，您可以在生产服务器上保留应用程序的多个版本，如果您需要回滚，您可以通过重新符号链接 Web 根目录将您的 Web 服务器指向旧版本。两个 shell 命令，微秒级的停机时间，比使用 git 的出错空间更小。

另一个例子 - 你有标准的 dev 分支 > staging 分支 > master 工作流，每个都有一个服务器。您已经准备好进入开发阶段，但还有其他一些关于暂存失败的 QA 的东西。所以你需要做一些丑陋的操作——从阶段中删除错误的提交，重新部署阶段，并在开发中删除或修复错误的提交，并希望开发和暂存不会最终不同步。

相反，如果你从 master 中切断一个发布分支，合并准备进入该发布分支的东西并构建结果，在 AWS 上启动一个测试服务器并将结果部署到它，运行你的 QA 和功能测试那个临时登台服务器，然后将相同的结果推送到生产集群并部署它？然后停用您启动的临时暂存盒，将版本合并到主版本中，并使用版本号标记主版本。

显然，这些都是极端的例子。通常，即使我们希望它是干净的，它也不是那么干净 - 您可能需要在目标环境中运行一些构建过程，因为您需要进行数据库更改。如果你在版本之间有非幂等数据库模块，那么无论你使用什么方法，回滚都不会那么容易，因为你需要回滚数据库（一般来说，尝试部署幂等数据库更改，然后在您确定它们已超出应用程序流程之后，在以后的版本中删除过时的数据库位）。

无论如何，我想我在说什么，这是我对“使用 git 进行部署不好的做法”的回答吗？一般来说，“是”，就像使用辅助轮不利于骑自行车一样。与反复在混凝土上打屁股相比，这是一个改进，但你希望最终能超越它。

您可以--separate-git-dir=<git dir>在调用git clone时使用该参数。这将在.git目录中放置一个符号链接（Git 的符号，我不认为它是您的操作系统的符号链接），并且您可以指定<git dir>到文档根目录之外的某个位置。