1. 先从一台 CentOS 7 服务器要装 Git这个真实场景说起如果你还在维护 CentOS 7 服务器又需要在上面安装 Git那你大概率已经遇到过或者即将遇到这么几个情况yum 一把装完发现版本老得离谱好不容易决定源码编译结果各种依赖缺失报错看懵了装完想用 HTTPS 拉代码SSL 证书又跳出来拦路。我接手过不少还在生产线上跑着的 CentOS 7 机器系统替换不是今天说改就能改的但代码发布、配置同步、CI/CD 这些事又绕不开 Git所以一台 CentOS 7 服务器能不能装好一个靠谱的 Git直接决定了后续运维工作顺不顺利。这篇文章不是把官方文档翻译一遍而是把一套完整的CentOS 7 上从零安装并配置好 Git的实操过程记录下来包括版本选型的理由、源码编译每一步的用途、安装后的全局配置与 SSH 免密设置以及我实际踩过的几个报错和排查链路。无论你是刚接触服务器的 Linux 新手还是已经写过一堆 Linux 常用命令但第一次在 CentOS 7 上折腾 Git 的运维同学这篇文章都能让你少走几天弯路。要特别说明的一点是CentOS 7 这个系统在 2024 年 6 月 30 日已经停止官方维护默认软件源不再提供更新所有老包被转移到 vault.centos.org 存档仓库。这个事实直接影响了后面 yum 安装和依赖补齐的操作方式所以我会把EOL 之后怎么处理源也一并讲清楚。这是现在装 CentOS 7 软件绕不开的前提。2. 版本选型yum 默认源与源码编译为什么我建议后者2.1 默认源里的 Git 到底有多老如果你直接在 CentOS 7 上执行yum install git装出来的版本是1.8.3.1。这个版本发布于 2016 年左右放在今天属于爷爷辈。它的问题不只是数字难看而是实打实缺了一堆现代工作流里大家都在用的能力。简单列几个 1.8.3.1 没有、现代 Git2.3x 以上才有的东西git switch和git restore现在切换分支推荐用 switch 而不是 checkout老版本只有 checkout。git init.defaultBranch配置项新仓库默认分支想设成 main老版本做不到。更完善的差异算法和合并策略git merge --no-ff能看懂但像 ort 合并策略这类性能优化在老版本上根本没有。部分克隆、稀疏检出等仓库瘦身功能老版本不支持拉大仓库的时候体验很差。更完整的协议支持与安全修复老版本对服务端协议的兼容性和现代托管平台存在差异。我在一台机器上验证过同一个私有 GitLab 仓库老版本 Git 在git fetch时偶尔会出现奇怪的协议错误跑git submodule update也容易卡住。换成新版之后同样的网络环境、同样的仓库路径问题消失。这不是玄学就是老版本客户端和现代服务端协议处理不兼容。2.2 源码编译的成本与收益那为什么不直接用别人打包好的新版 Git 呢CentOS 7 默认源里没有新版第三方源比如 IUS、REMI 可以装但引入第三方源本身就带来了信任和依赖冲突的问题。对服务器来说源码编译是可控性最高、最没有额外依赖负担的方案这也是我最终推荐的方式。源码编译的成本其实很小在 CentOS 7 上装好依赖后编译 Git 本体大概 3 到 6 分钟取决于机器核数后续升级就是下载新版源码包再编译一遍管理路径清晰。相比 yum 装完就锁定在 1.8.3.1源码编译给我们留下了版本主动权。后面第 4 节会详细展开整个编译安装过程这里先把结论放在前面如果是新装、要长期使用的服务器直接上源码编译如果只是应急用一下yum 也不是不能用但请记住版本是 1.8.3.1心理预期要摆正。3. 编译前的系统准备EOL 源修复与依赖包一次性补齐3.1 确认系统环境别在 32 位机器上白忙活动手之前先确认两件事系统确实是你以为的 CentOS 7架构是 x86_64。命令很简单cat /etc/redhat-release uname -m正常情况下输出类似CentOS Linux release 7.9.2009 (Core)和x86_64。如果你看到的是i386或者i686请先去确认机器资源32 位系统装新版 Git 的坑会更多不建议继续。3.2 CentOS 7 EOL 之后先把 yum 源切到 vault 存档我遇到过最尴尬的场景新装的一台 CentOS 7 虚拟机执行yum install直接报错原因是官方源已经停服默认的 mirrorlist 地址已经不可用。解决办法是把 yum 源切到 vault.centos.org 存档仓库或者使用国内镜像站保留的 CentOS 7 存档源。切官方 vault 源的操作如下sed -i s/mirrorlist/#mirrorlist/g /etc/yum.repos.d/CentOS-*.repo sed -i s|#baseurlhttp://mirror.centos.org|baseurlhttp://vault.centos.org|g /etc/yum.repos.d/CentOS-*.repo执行完yum clean all yum makecache验证源是否可用。这一步听着像是歪门邪道但其实是 EOL 系统的标准自救操作我是建议在动手编译之前先把源搞定否则后面缺依赖的时候会非常被动。3.3 依赖包逐个说清楚为什么要装它们源码编译 Git 之前需要把编译工具和几个关键开发库装好。我习惯一次性装齐免得编译到一半报错又回头补yum install -y gcc make expat-devel curl-devel zlib-devel openssl-devel perl-ExtUtils-MakeMaker这里每个包都不是凑数的我按作用拆开讲一下gcc、makeC 语言编译器与构建工具源码编译的标配不用多说。expat-develexpat 是一个 XML 解析库Git 的 HTTP 智能协议在解析服务端响应时会用到它。缺了这个编译配置阶段直接报 expat 相关错误。curl-develGit 通过 HTTPS 拉代码依赖 libcurl这个开发包提供头文件。没有它git clone https://...基本不可用。zlib-devel压缩库Git 对象存储的压缩全靠它。编译时找不到 zlib.h 会中断。openssl-develTLS/SSL 支持HTTPS 加密通信的底层依赖。CentOS 7 的 Git 编译建议走 OpenSSL 后端这样证书行为更可控。perl-ExtUtils-MakeMakerGit 自带一些 perl 脚本文本插件构建它们需要这个模块。装不装不影响主程序但装上能避免构建到一半爆 perl 警告。这组依赖包整理成一张表方便你对照检查依赖包作用缺失时的典型报错gccC 编译器gcc: command not foundmake构建工具make: command not foundexpat-develXML 解析expat.h: No such file or directorycurl-develHTTPS 传输curl/curl.h: No such file or directoryzlib-devel数据压缩zlib.h: No such file or directoryopenssl-develTLS/SSLopenssl/ssl.h: No such file or directoryperl-ExtUtils-MakeMakerPerl 模块构建perl: unrecognized switch或 MakeMaker 相关提示嫌一个个手敲太慢的话也可以直接yum groupinstall Development Tools把整套开发工具装上然后再补expat-devel、curl-devel等几个库。我个人更推荐精确安装上面这组避免装机器的开发工具包带来一大堆用不到的组件。4. 源码编译安装 Git从下载到环境变量完整操作4.1 源码包从哪下、怎么校验源码下载我推荐两个地方一个是 Git 官方的 GitHub Releases 页面github.com/git/git/releases另一个是 kernel.org 的源码镜像。我习惯用 kernel.org 的地址下载稳定且速度通常不错cd /usr/local/src wget https://mirrors.edge.kernel.org/pub/software/scm/git/git-2.45.2.tar.gz版本号可以按需替换选稳定版即可。下载完建议做一下 SHA-256 校验GitHub Release 页面会给出对应的 checksum 值对照确认没问题再解压sha256sum git-2.45.2.tar.gz这一步很多人跳过了但我吃过亏曾经下载到一个损坏的压缩包解压时报错排查了半天才发现是文件不完整。花十秒钟校验能省半小时。4.2 configure、make、make install 三步走解压并进入源码目录然后执行配置tar -xzf git-2.45.2.tar.gz cd git-2.45.2 ./configure --prefix/usr/local/git这里--prefix/usr/local/git是核心参数意思是把 Git 安装到独立的/usr/local/git目录。为什么不直接默认装到/usr/local或/usr因为单独一个前缀目录后续升级、卸载、检查版本都干净不会和系统自带工具混在一起。等新版 Git 发布直接下载新源码用同一个 prefix 再编译安装就能覆盖升级可维护性最好。configure 这一步会检查前面装好的 expat、curl、zlib、openssl 是否齐全并自动生成 Makefile。如果之前依赖没装齐这一步就会报错中止正好提前暴露问题比编译一半再挂掉容易定位。配置完成后开始编译make -j4-j4表示用 4 个线程并行编译。如果你的服务器核数更多比如 8 核或 16 核可以改成-j8、-j16编译速度会明显更快。我在这台 4 核机器上编译 2.45.2 大约花了 5 分钟期间 CPU 满载属正常现象别以为机器卡死了。编译完成后安装make install安装完成后去/usr/local/git/bin看一眼git、git-upload-pack、git-receive-pack等可执行文件应该都在。4.3 PATH 环境变量装完最容易漏的一步很多人装完发现敲git还是提示 command not found或者显示的版本还是旧版原因就是 PATH 没有指向新装的目录。在/etc/profile.d/下新建一个git.sh把新目录放到 PATH 最前面vi /etc/profile.d/git.sh写入export PATH/usr/local/git/bin:$PATH然后让配置生效source /etc/profile which git git --version如果which git指向的还是/usr/bin/git说明当前终端还带着旧 PATH执行hash -r清理一下 shell 的命令哈希缓存再重新确认。这一步特别容易踩新旧 Git 同时出现在 PATH 里是后面各种诡异报错的根源我把排查思路放在第 6 节统一讲。5. 安装后的四件事全局配置、SSH 密钥与首次验证5.1 全局基础配置Git 装好不等于能直接用第一件事是配置身份信息。服务器上配置一个专用的机器人身份比用个人身份更合理下面是我在一台部署服务器上的习惯做法git config --global user.name deploy-bot git config --global user.email deployexample.com这里有个容易忽略的点如果服务器上 Git 提交的代码会推送到远程仓库这个 user.name 和 user.email 会出现在 commit 记录里。很多团队因为服务器提交用了某位同事的邮箱导致代码量统计错乱。建议用一个团队统一认可的部署机器人身份或者干脆在服务器上避免直接提交只做拉取与同步。接下来是几个对服务器环境特别重要的配置项git config --global core.autocrlf false git config --global init.defaultBranch main git config --global push.default simplecore.autocrlf false服务器是 Linux代码文件应该保持 LF 换行这项一定要关掉。如果设成 truecheckout 时会自动把 LF 转成 CRLF在 Linux 服务器上纯属自找麻烦。init.defaultBranch main新仓库默认分支设为 main这是现在的主流习惯。老版本 Git 没有这个配置项我们编译的是新版可以放心设置。push.default simple默认值其实已经是 simple但显式写出来是为了防止老配置文件的干扰语义也清楚只推送当前同名分支。配置完可以执行git config --list --show-origin查看所有配置项及其来源文件。这个--show-origin参数老版本没有它也算侧面验证我们装的新版生效了。5.2 生成 SSH 密钥并配置免密拉取服务器拉取私有仓库SSH 方式比 HTTPS 方式省心得多不用反复输密码也不会被令牌到期折腾。CentOS 7 自带的 OpenSSH 版本是 7.4支持 ed25519 算法所以直接生成 ed25519 密钥ssh-keygen -t ed25519 -C deployexample.com -f ~/.ssh/id_ed25519生成过程中可以直接回车跳过 passphrase。如果公司要求密钥加密那后续每次拉代码都要输密码自动化脚本就得用 ssh-agent 托管复杂度上升我建议部署密钥保持无口令。然后把公钥内容添加到你的代码托管平台GitHub、Gitee、GitLab 私有实例均可cat ~/.ssh/id_ed25519.pub复制输出内容到平台后台的 SSH Keys 设置里粘贴保存。验证是否配置成功ssh -T gitgitee.com第一次连接会提示确认 host key输入 yes 后如果看到类似Hi xxx! Youve successfully authenticated的欢迎语说明免密配置完成。这一步之后服务器拉取私有仓库就不再需要密码了。如果因为某些原因 ed25519 不被远端支持备选方案是生成 RSA 4096 位密钥ssh-keygen -t rsa -b 4096 -C deployexample.com -f ~/.ssh/id_rsa老一点的平台可能只认 RSA备份一种方案总没错。5.3 首次拉取验证配置完环境后建议立刻找一个真实仓库做一次完整拉取验证cd /srv git clone gitgitee.com:some-team/some-project.git拉取成功后进入项目目录执行git log --oneline -5确认历史记录正常再执行git status确认工作区干净。这一步能同时验证 PATH、SSH 免密和 Git 核心功能是安装收尾最实在的一次检查。6. 踩坑实录CentOS 7 上装 Git 最常见的五个报错与排查链路6.1 编译阶段的依赖缺失报错症状是 configure 或 make 过程直接中断报错信息五花八门expat.h: No such file or directory、curl/curl.h: No such file or directory、openssl/ssl.h: No such file or directory。这些报错本质都一样对应的开发头文件没装。我自己的真实经历是第一次编译时漏装了 expat-develconfigure 阶段直接提示找不到 expat 库。当时第一反应是去网上搜git 编译 expat 错误搜出来的答案绕来绕去最后一看发现就是缺包装完重跑 configure 就过了。排查链路其实很简单看报错信息里提到的是哪个头文件比如ssl.h对应 openssl-develcurl.h对应 curl-devel。用rpm -qa | grep 包名确认是否已安装。装对应 devel 包重新跑 configure。按第 3 节那一条命令把所有依赖装齐就能从源头规避这一类问题。6.2 HTTPS 克隆时的 SSL 证书报错如果你选择用 HTTPS 方式拉代码CentOS 7 一个高频坑是fatal: unable to access https://xxx/: SSL certificate problem: unable to get local issuer certificate这个问题的根源是 CentOS 7 系统里的 CA 证书库太老或者 nss 版本有兼容问题导致 Git 在验证服务端证书时失败。解决办法分两步yum update -y ca-certificates nss更新完再重试。如果还是不行检查一下 curl 是否正常curl -I https://你的仓库地址如果 curl 也报错说明系统层面的证书链路有问题需要继续更新或手动安装对应 CA 证书。临时方案是给 Git 配置跳过证书校验但我强烈不建议git -c http.sslVerifyfalse clone https://...跳过校验等于明文裸奔服务器上千万别这么干临时调试可以生产环境一律禁止。6.3 git-upload-pack: command not found这个报错容易出现在从你的工作电脑 SSH 登录到服务器然后直接 clone 服务器上的仓库的场景里bash: git-upload-pack: command not found明明是git clone root服务器IP:/srv/repo.git服务器上也明明装了 Git为什么报 not found原因是SSH 执行命令时走的是非交互 shell不会加载~/.bashrc或/etc/profile里的 PATH 设置于是找不到/usr/local/git/bin下的命令。排查链路先确认服务器上git实际路径是不是/usr/local/git/bin/git如果是那问题就是 SSH 会话的 PATH 没包含这个目录。最干净的解决办法是把 Git 核心命令软链到/usr/local/bin因为/usr/local/bin在绝大多数系统的默认 PATH 里ln -s /usr/local/git/bin/git /usr/local/bin/git ln -s /usr/local/git/bin/git-upload-pack /usr/local/bin/git-upload-pack ln -s /usr/local/git/bin/git-receive-pack /usr/local/bin/git-receive-pack做完之后在另一台机器上重新 clone 测试一般立刻恢复。这个坑特别隐蔽因为它不是装的时候报错而是过了好几天、换了个使用场景才冒出来。6.4 fatal: not a git repository (or any of the parent directories): .git这个报错大概是 Git 新手最常碰到的提示之一在相关热词里出现的频率极高。它的含义非常直白当前目录不是 Git 仓库向上逐级目录里也没有 .git 目录。场景一你进了/srv目录直接执行git status而/srv本身不是仓库就会报这个错。处理方式是先cd进真正的仓库目录。场景二新建项目时忘了初始化cd /srv/myproject git init如果是想在服务器上建一个裸仓库给别的机器 clone命令是git init --bare /srv/repos/project.git裸仓库没有工作区只有.git那套对象存储目录命名一般带.git后缀。裸仓库里执行git status同样会提示 not a git repository这其实是对的别误以为坏了。这个报错本身不算复杂但它属于高频出现的新人迷惑点我专门提一句是为了让大家看到提示不要慌先看 pwd 在哪再确认目录里有没有.git问题基本就解开了。6.5 大仓库克隆中断RPC failed; curl 18在服务器上克隆体积较大的仓库时经常会看到error: RPC failed; curl 18 transfer closed with outstanding read data remaining这个问题通常发生在 HTTP(S) 协议下原因是网络链路不稳定或者代理服务器、防火墙对传输时长有限制导致连接在传输过程中被掐断。用 SSH 协议拉代码一般不会触发这个因为不走 HTTP 层。如果你必须走 HTTPS可以尝试调高缓冲区git config --global http.postBuffer 524288000524288000大约是 500MB把本地 HTTP 发送缓冲调大。还可以配合设置低速超时git config --global http.lowSpeedLimit 1000 git config --global http.lowSpeedTime 30意思是传输速度低于 1000 字节/秒持续 30 秒才判定超时给慢速网络更多耐心。如果仓库实在太大推荐浅克隆只拉最新一层历史git clone --depth 1 gitgitee.com:some-team/some-project.git浅克隆适合发布部署这种只需要最新代码的场景能省掉大量历史对象传输时间。如果你的 CI/CD 流程只是把代码拉到服务器上构建部署这个方案相当值得考虑。7. 收尾建议版本固化、升级路径与日常使用习惯装完 Git 不是终点服务器上的软件版本管理才是日常运维的重头。我的习惯是装完立刻把版本信息记进资产清单git --version同时把安装目录、prefix 参数、依赖包列表一并记录在团队的运维文档里。这样半年后如果有人问这台机器的 Git 是哪来的、怎么升的级不用翻历史记录也能直接回答。关于升级源码编译的一大好处就是升级路径清晰。新版本发布后下载新源码包用相同的 prefix 重新走一遍 configure、make、make install新文件会自动覆盖旧版本cd /usr/local/src wget https://mirrors.edge.kernel.org/pub/software/scm/git/git-2.4x.x.tar.gz tar -xzf git-2.4x.x.tar.gz cd git-2.4x.x ./configure --prefix/usr/local/git make -j4 make install升级前建议先git --version记录老版本升级后再确认新版本。因为 prefix 相同PATH 不用改旧仓库、旧配置全部保留基本无痛。唯一要注意的是升级前别正在跑重要构建任务编译安装和构建抢占资源容易引发意想不到的连锁问题。最后说两个使用习惯。第一个如果服务器上有多个系统用户都用 Git尽量让每个用户维护自己的~/.gitconfig别用/etc/gitconfig写全局配置否则不同用户的 user.name、user.email 会互相干扰提交记录里出现别人的身份信息。第二个写脚本调用 Git 时尽量显式指定命令路径或确保在脚本头部 source 了 profile不要赌 SSH 环境的 PATH这也是我踩过 6.3 之后养成的习惯。在我个人实际操作中的体会是CentOS 7 上装 Git 这件事百分之八十的问题其实都集中在版本太旧和PATH 环境不对这两类原因上。只要你愿意多花几分钟走源码编译再把 PATH 和 SSH 两件事理顺后面基本一路顺畅。如果你手头的 CentOS 7 机器还要继续服役一两年不妨今天就把这套流程走一遍至少将来拉代码、跑部署的时候不会在Git 版本太老不支持某个命令这种低级问题上卡住。