gitosis已停止维护，因依赖python 2和旧ssh配置，与现代linux发行版兼容性差，存在导入错误、ssh公钥加载失败、push权限异常等问题，且仅支持仓库级权限，无分支/路径控制与审计日志。
Gitosis 已停止维护，不建议新项目使用；多人协作权限应优先考虑 Gitolite 或直接用 Git + Unix 组权限 + shared=group。
为什么 Gitosis 不再适合当前 Linux 环境
Gitosis 自 2010 年起就不再更新，其依赖的 Python 2 和旧版 SSH 配置在现代发行版（如 CentOS 8+/RHEL 8+、Ubuntu 20.04+）上存在兼容性问题。常见表现包括：
-
gitosis-init报错ImportError: No module named pkg_resources（缺少 setuptools） - 克隆
gitosis-admin.git时提示fatal: Could not read from remote repository，实为 SSH 公钥未被正确加载或post-updatehook 权限失效 - 配置生效后，用户仍无法 push —— 因为 Gitosis 仅修改
authorized_keys，但新版 OpenSSH 默认禁用no-port-forwarding以外的限制指令，而 Gitosis 生成的 key 行不含必要环境变量
它本质是“用 Git 管理一个静态 authorized_keys 文件”，功能边界窄，无分支级/路径级权限，也无审计日志。
替代方案：用 git init --shared=group 实现基础协作
若团队规模小（
- 创建专用组：
sudo groupadd gitdev - 将所有开发者加入该组：
sudo usermod -aG gitdev dev1 dev2 - 初始化仓库时启用组共享：
git init --bare --shared=group /srv/git/myproject.git - 确保目录属组和权限正确：
sudo chgrp -R gitdev /srv/git/myproject.git && sudo chmod -R g+rwX /srv/git/myproject.git - 关键：所有用户需设置 umask 为
0002（在~/.bashrc中加umask 0002），否则新提交对象权限仍为644/755，同组人无法覆盖
此方式下，只要用户属于 gitdev 组，就能 clone、push、pull；无需 SSH 密钥管理，也不依赖 Python 或特殊 shell。
需要精细权限？改用 Gitolite（非 Gitosis）
Gitolite 是 Gitosis 的继任者，仍在活跃维护，支持分支规则、命令白名单、个人命名空间等。安装要点：
- 不要用系统包管理器装（如
yum install gitolite版本太旧），直接从源码部署：git clone https://github.com/sitaramc/gitolite - 管理员密钥必须用
ssh-keygen -t ed25519生成（OpenSSH 7.0+ 默认），避免 RSA 兼容问题 - 安装时指定专用用户（如
git），且该用户 shell 必须为/bin/bash或/usr/bin/git-shell（不能是/bin/false） - 权限配置在
gitolite-admin/conf/gitolite.conf中，语法更清晰，例如：
repo myproject
RW+ = dev1 dev2
R = dev3
RW master$ = dev1
- refs/tags/.* = dev2
推送到服务器后自动生效，无需手动 chmod hook 或重启服务。
最容易被忽略的权限细节
无论选哪种方案，以下三点常被跳过，导致“配置写了却没效果”：
-
/home/git目录权限不能是755—— 必须为750或711，否则 SSH 拒绝读取authorized_keys - 用户本地的
git config user.name和user.email只影响 commit 元数据，与服务器权限无关；权限判断只看 SSH 连接时使用的公钥对应用户名（即keydir/dev1.pub中的dev1） - 如果用
git@server:/path/to/repo.git方式访问，确保/path/to上级目录对git用户可执行（x位），否则报 “repository not found” 而非权限错误
