我正在尝试在 Ubuntu 上部署一个新的（首次）Nginx 服务器。我正在关注DigitalOcean 的教程，可在此处找到。
按照教程的建议，我将每个站点放在主机内/var/www/domain.tld。当我尝试使用 git 时，我遇到的问题出现了：一些站点存储在 git 存储库中，但尝试将 sudo 与 git 一起使用会导致权限错误（在 git 端）。我正在寻找一种安全的方法，允许我的用户帐户访问站点目录，而无需通过 sudo。我不想使用用户主文件夹中的目录（因为~/var/www这会使站点依赖于我的用户）。哪里是一个合理标准化的存储用户可访问的站点的地方？
答案1
使用 sudo 分配站点文件所在目录的所有权。例如 /var/www/example.com/public_html（使用您参考的教程中的命名方案）。您可能希望分配 /var/www/example.com 内其他目录的所有权，但如果您有一个 /var/www/example.com/logs 目录，那么该目录及其父目录应由 root 拥有，并且其他任何人都无法写入。
您引用的教程有一个相当简单的权限模型，如果一个没有权限以 www-data 用户或 root 身份执行操作的用户需要在 web-root 中安装文件，那么这个模型对您来说就没什么用。此外，您还希望尽可能阻止 www-data 用户写入代码文件。
有一种简单的策略，在共享托管系统中相当常见，即每个站点都有一个用户，拥有文件，并且 Web 服务器帐户根据“其他”用户对文件的权限访问文件。这意味着所有用户都可以看到其他用户的所有 Web 文件，但通常还会对通过正在使用的文件访问服务器（例如 ftpd 或 ssh 的 internal-sftp）可以看到的内容施加限制。这阻止用户查看彼此的文件，而没有强大的安全性。可以采取更强有力的措施，但实际上不能仅通过文件权限。
www-data 用户需要能够写入某些目录（文件上传到这些目录），但理想情况下，您希望用户能够禁止 Web 服务器写入其他目录。用户可以通过“其他”用户的“可写”位来控制这一点。即chmod o+x ...或chmod o-x ...。
以拥有该站点的用户身份运行 git，仅针对该用户可写入的目录。
对于允许多个用户共享站点目录的稍微复杂的模型（并且节省了他们必须特意切换到站点用户的时间），您可能需要查看http://andrew.mcnaughty.com/node/1
您可能还想研究一个系统，其中推送到相应 git 分支的更改会自动签出到站点，这意味着用户只需担心 git 访问，而不必担心站点用户的访问。搜索“推送以部署 git”以了解更多信息。
答案2
如果您只希望该服务器上有一个站点，那么 /var/www 就可以了。
如果您计划在多个站点上（即 nginx 中多个“服务器”节），那么我建议使用 /var/www/ 或其他类似的结构。
如果可能的话，请远离 /home，以获取站点内容。
不过我不确定这与 git 有什么关系；你必须更明确地描述问题是什么。如果我可以猜测的话，它可能与权限有关？如果是这样，请记住，如果你拥有服务器，那么现在 /var/www 就是原因了必须由 root 拥有，这只是初始默认设置（通常？也许……可能会有所不同）。它可能由您用来通过 git 部署内容的非 root 用户拥有，可能是您自己的用户代码（但不建议这样做，因为它将交互式用户与服务类型用户的概念混为一谈），也可能是拥有已部署代码/内容的“部署”用户。
答案3
虽然这当然不是唯一的解决方案，但对我来说似乎有效：
我最初尝试将我的用户添加到www-data组（/var/www由 拥有www-data:www-data），但是我不想授予 www-data 组写入/执行权限，以防止涉及 中的其他系统用户的安全问题www-data。
最后，我最终将我的个人管理员帐户设置为/var/www（及其子目录）的所有者。我觉得这远非最佳解决方案，因此我仍然愿意接受更好的想法，但就目前而言，将自己设置为整个目录的所有者使我能够在那里运行 git，而不会出现任何重大安全漏洞。这种解决方案仍然感觉有点依赖于用户，但它确实比将 Web 文件放在像 .gitignore 这样经过大量编辑且依赖于用户的地方感觉要好/home。