开源项目git自建；3个坑在权限和备份

开源项目git自建这件事，装的那一步几乎没啥难度，一条包管理命令或者一个 docker run 就起来了。真正让人半夜爬起来翻日志的，是后面——权限和备份，这两块一开始没想清楚，出事的时候基本都不是小毛病。

开源项目git自建，权限这块最容易翻车

装完能 clone、能 push，多数人觉得这就成了。等团队进来几个人，问题开始冒头：谁都能删分支、谁都能强推、新来的一 push 就报 remote: error: cannot lock ref，还得你登上服务器去 chown。这类事不稀奇，我见过好几回。

两套账号体系，装的时候就该想清楚

自建的这套东西一般有两套身份：命令行走的 SSH key，浏览器后台走的账号密码。装的时候图省事两边都开着，后来就变成同一个人有两个身份，这边改了权限那边没跟上。比较稳的做法是命令行只走 SSH key，后台账号只留给需要看 issue、发合并请求的人，两边的分组名字起成一样的，改权限的时候对着改，不容易漏。

authorized_keys 这个文件本身也值得盯一眼。有人为了省事，让用户在后台自己贴公钥，贴完服务器上那文件就是可写的；再加上 hooks 目录也开放写权限，等于递了一条在服务器上执行命令的路出去。把这两处收紧，能省掉很多解释不清的麻烦。

顺便说一句，大仓库 push 失败不一定是权限。前面要是挂了 Nginx 反代，先看 client_max_body_size 和超时那两项，改完再谈权限。方向定错了，白折腾一晚上。

所有人塞进一个组，省事也埋雷

刚开始人少，大家都丢进 developers 组，能直接推主干，痛快。人一多，主干就成试验田，谁都能把没跑通的代码推上去。稳妥点的划法是主干保护打开、只允许通过合并请求进；能直接推的人留一两个；跑流水线的机器人账号单独给一个，别跟人共用。听着麻烦，真出事的时候至少知道该找谁。

服务端还有几个现成开关，裸仓库的 config 里 receive.denyNonFastForwards、receive.denyDeletes 之类，开一下就能挡掉强推和删分支，别光靠人盯。

还有一个特别容易混进权限问题里的细节——文件属主。仓库目录、上传目录、hooks 目录的属主必须跟服务进程跑的那个用户一致，不一致的话 push 上去就是一堆 lock 报错，日志里还看不出啥。这个坑跟权限设置混在一起，最费人。

开源项目git的备份坑，只备份仓库等于没备

这条我劝你记一下。不少人的备份就是 tar 一遍 repositories 目录，觉得仓库全在里头了。整套自建系统里，除了裸仓库，还有用户公钥、后台数据库（账号、issue、合并请求、评论全在里面）、配置文件、自己写的 hooks 脚本、LFS 的大文件对象、头像和附件这些上传文件。少一样，恢复出来就是个空壳。

数据库最容易被忘。代码能 clone 回来，但那堆讨论记录、合并请求的历史、issue 里的来龙去脉，全在库里。备份的时候，数据库和仓库最好对着同一个时间点拍，别一边今天的、一边上周的，恢复完整不过来。

LFS 也一样。项目里放了设计稿、模型文件这类大东西，它们不在裸仓库里，单独躺在 lfs 目录。只 tar 仓库不 tar lfs，恢复完 clone 下来一堆指针文件，那场面挺尴尬。

备份文件放哪，跟备份本身一样要紧

脚本跑得欢，文件全落在同一台机器的同一块盘上，机器一挂就一起没了。至少挪一份出去，另一台机器、对象存储、甚至一块移动硬盘都行。备份文件的读权限也顺手收紧，那里面等于整个团队的账号加代码。

保留策略不用搞太复杂，日备留几天、周备留几周，按你们能接受的恢复点来定。定完写成几行字，别只装在某个人的脑子里。

能恢复回来才算备份

脚本每天退出码是 0、日志一片绿，不代表能恢复。隔段时间找台干净机器，从最新的备份完整走一遍：起服务、clone、push、翻 issue 还在不在。做过这一步的人基本都翻出过问题——路径不对、属主没设、某个配置压根没进备份。早点翻出来，比在真事上翻出来强太多。

走完把步骤写成几行，放在备份目录旁边。真出事的时候人是慌的，照着做比临场想要靠谱。

照着做就行的几条

列个清单，能直接对着勾：主干保护打开，改动走合并请求；hooks 目录和 authorized_keys 只有运维可写；仓库和上传目录的属主跟服务用户对齐；备份范围覆盖仓库、LFS、数据库、配置、hooks、上传文件；备份挪一份到别的机器或对象存储；短周期内至少演练一次恢复。

自建 Git 的好处是全都自己说了算，代价也是全都自己扛。权限和备份这两块前面多花半天，后面能少熬几个夜。剩下的慢慢调。