为企业内部配置Git服务器搭建与权限分配的完整教程

先说几个核心结论：搭建Git服务器时，裸仓库必须用git init --bare初始化，否则客户端push一定会报错；它不含工作目录，只存储Git元数据，是SSH/HTTP协议唯一认可的远程仓库形态。路径建议以.git结尾，目录归属、SSH公钥权限以及git用户的shell限制也都得严格配置——任何一个环节卡住，整个流程就走不通。

裸仓库必须用 --bare 初始化，否则客户端 push 会失败

Git服务器不能直接拿普通仓库（带工作目录那种）对外提供服务。裸仓库没有worktree，只存Git元数据，是唯一被SSH/HTTP协议认可的远程仓库形态。很多人踩过的坑：在服务器上执行git init后直接把仓库放上去，结果客户端git push时弹出remote: error: refusing to update checked out branch。这个错误的意思很直白——远程仓库当前有检出分支，Git拒绝直接覆盖。正确的做法始终是：git init --bare myproject.git。路径名建议以.git结尾，方便识别。目录归属必须设为git用户：chown -R git:git /opt/git/myproject.git。

SSH 公钥必须写入 /home/git/.ssh/authorized_keys，且权限必须严格

只要权限不对，SSH就拒绝读取公钥——这是最常卡住的环节，而且报错信息特别模糊。必须确保以下三点同时成立：

• /home/git/.ssh 目录权限为 700（仅owner可读写执行）
• /home/git/.ssh/authorized_keys 文件权限为 600（仅owner可读写）
• 文件所有者是 git 用户：chown git:git /home/git/.ssh /home/git/.ssh/authorized_keys

漏掉任意一项，git clone git@server:/path.git 都会提示 Permission denied (publickey)，而且系统不会告诉你具体哪一步错了——排错全靠反复检查。

多用户场景下，禁止 git 用户交互式登录是硬性安全要求

让git用户能执行shell命令，等于给服务器开了一个后门——即使只配了公钥也危险。必须锁定它的shell：

• 修改 /etc/passwd 中 git 行，把 /bin/bash 替换为 /usr/bin/git-shell（Git自带受限shell，只允许Git协议操作）
• 或者更彻底：sudo usermod -s /bin/false git

验证方式很简单：手动执行ssh git@server，应该立即退出，不会进入交互；但git push等Git操作不受影响。忽略这一步，审计时基本过不了合规检查——很多安全漏洞就是从这里进来的。

权限隔离靠文件系统组+--shared，别指望 Git 自己管细粒度权限

Git本身没有用户/仓库级别的权限控制。所谓“权限分配”，本质上是Linux文件权限加上组管理。典型做法：

• 创建业务组：sudo groupadd devteam
• 把开发者加进组：sudo usermod -aG devteam alice
• 初始化仓库时启用共享模式：sudo -u git git init --bare --shared=group /opt/git/proj.git
• 再设组所有权：sudo chgrp -R devteam /opt/git/proj.git && sudo chmod -R g+swX /opt/git/proj.git

这样一来，所有devteam成员对仓库有读写权，但无法修改其他组的仓库。如果真要做到按人/按分支精细控制，那就得上gitolite或Gitolite3了——纯SSH方案搞不定这种粒度。