先说最基本的.git目录防护。很多开发压根不知道这个隐藏文件夹里装着整个项目的变更历史，要是被直接拖库就全完了。特别是那些把项目扔在Web根目录下还忘记配置禁止访问的，黑客直接输入域名/.git就能把整个版本库拖走。最稳妥的办法是在服务器上用git clone --mirror同步到非Web目录，再配合钩子脚本自动部署到运行环境。
权限管控这块水更深。见过有团队把仓库权限简单分成"可写"和"只读"两种，这简直是在安全雷区蹦迪。最起码要细分到：项目负责人有master分支强制推送权限，核心开发者能合并功能分支，普通成员只能推送到自己的开发分支。现在GitLab和Gitea都支持分支保护规则，记得把关键分支都加上合并请求和代码审查的强制要求。
敏感信息泄露这事儿我说过八百遍了，但还是有团队中招。光靠团队成员自觉不在代码里写密码根本防不住，最好在预提交钩子里加个正则扫描，检测到密钥模式就直接阻断提交。更专业的做法是用Vault这类密钥管理工具，或者至少用git-secrets这样的插件做实时检测。万一真手滑提交了敏感信息，别以为简单删除就完事儿了，必须立即轮换所有可能暴露的凭证。
签名验证现在真该重视起来了。光是启用SSH密钥认证还不够，得强制要求所有提交都要GPG签名。特别是在开源项目里，没签名的提交根本不该被合并。配置起来也不复杂：生成密钥对，上传到密钥服务器，在Git配置里设置签名规则。Windows平台用gpg4win，Mac下装GPG Suite，Linux系统直接apt install gnupg就行。
说到远程仓库的安全，千万别用HTTP协议传输代码。SSH协议不仅加密数据流，还能通过密钥对实现身份验证。建议把SSH默认端口改成非常用端口，禁用密码登录，最好再配置个双因素认证。如果是自建Git服务器，记得定期更新SSH服务版本，检查 authorized_keys 文件的权限设置。
分支策略看似是工作流程问题，其实直接关系到代码安全。那种所有人都在master分支上疯狂提交的团队，不出事才怪。推荐用GitFlow这类标准化分支模型，功能开发、紧急修复、版本发布都走固定流程。重要分支必须设置成受保护状态，合并时必须通过至少两人的代码审查，CI构建全通过才能合入。
钩子脚本用好了是安全利器，用不好就是后门。服务端钩子应该强制检查提交信息规范、拒绝包含大文件的提交、验证提交者身份。客户端钩子可以做一些轻量级检查，比如确认代码格式、运行基础测试。但切记不要在钩子里放业务逻辑，更别偷偷收集开发者的本地信息。
最后说说那些容易被忽视的细节：定期清理.git/refs/original里的备份引用；用git reflog expire清理过期日志；配置git gc自动打包松散对象；对于废弃分支一定要物理删除而不是简单切换。还有.gitignore文件必须规范配置，把编译产物、IDE配置、本地环境文件都排除在版本控制之外。
其实Git安全说到底就是养成好习惯：每次push前想想这行代码会不会暴露服务器配置；合并分支时多问句这个改动是否经过验证；定期用git log -p检查历史记录有没有可疑内容。安全这事儿永远没有一劳永逸，得持续盯着才行。