1. 安装前必须想清楚的事版本、源与基础环境先聊点实际的。CentOS 7 虽然已经停止维护了但不可否认的是大量生产环境、老服务器、各类云主机上还在跑着这套系统。在这种背景下“装个 Git”听起来像是三分钟搞定的小事实际上里面藏了不少坑尤其是版本问题和软件源问题。我见过太多人直接在服务器上执行yum install -y git装完一查版本是 1.8.3.1然后后面拉代码、跑 CI 的时候遇到各种诡异问题回头才发现是 Git 版本太老导致的。所以这篇文章我想把自己的实操经验完整过一遍覆盖 yum 安装、IUS 源安装、源码编译安装三种方式以及安装之后必须做的配置和常见问题排查让不管是刚入门的新手还是想补细节的老手都能有收获。先说一个核心认知。CentOS 7 官方默认源里的 Git 版本是 1.8.3.1这个版本发布于 2013 年到现在已经非常老了。它存在几个实际痛点第一对 HTTPS 协议的支持不完整部分新搭建的 Git 服务端默认开启的 TLS 配置会导致 clone 或 push 直接失败第二不支持一些较新的协议特性和性能优化比如部分 partial clone、稀疏检出等特性在老版本上表现很差第三git status等基本命令在超大仓库上的性能明显劣于新版本因为老版本的索引格式和算法没有后续优化。如果你只是在一台机器上管理几个小项目的代码1.8.3.1 勉强能用但只要涉及跨团队协作、大型 monorepo、CI/CD 流水线我都建议至少把 Git 升级到 2.x 版本。另外装 Git 之前必须检查基础环境。CentOS 7 的装机方式有很多种有些是最小化安装有些带了图形界面还有的是云厂商提供的镜像它们的软件包集合差异不小。比如源码编译 Git 需要 gcc、make、autoconf 等工具链还需要 zlib-devel、curl-devel、openssl-devel、expat-devel 等依赖库如果是最小化安装这些默认一个都没有。所以安装之前别急着执行安装命令先花两分钟把系统环境梳理清楚这会省掉后面很多折腾的时间。还有一个容易被忽略的点是网络。装 Git 本身不需要外网但如果要通过 yum 安装或者下载源码包就必须确保服务器能正常访问外部软件源或代码托管平台。国内服务器的话建议先把 yum 源替换成阿里云或清华的镜像源速度会快非常多也稳定得多。这一步很多人不当回事结果 yum 卡半天最后超时或者下载源码包几十 KB 每秒极其影响效率。后面我会把具体操作也写出来。提示CentOS 7 已于 2024 年 6 月 30 日 EOL官方镜像源已经停止同步。继续使用 CentOS 7 的服务器务必把 yum 源切换到 vault.centos.org 或阿里云、清华等镜像站否则yum install会直接报错。2. 三种安装方式怎么选快速装、追新版、源码控2.1 方式一yum 直接安装最快但版本老旧先说一下最省事的方案。CentOS 7 官方源里直接有 Git 的 RPM 包所以理论上一个命令就能装完yum install -y git装完之后验证版本git --version正常情况下你会看到git version 1.8.3.1。如果只是开发机上临时用用或者内网环境对版本没有硬性要求这个方式确实够快。但我必须强调我刚才说的那几点1.8.3.1 的问题不仅仅是功能少更关键的是它在大仓库和 HTTPS 场景下的表现确实拉胯。我在一台配置不错的服务器上用 1.8.3.1 拉取一个包含几十万文件的仓库耗时比 2.31 版本多了将近一倍而且git status每次执行都要卡好几秒。如果你的工作流里包含这些场景建议直接用下面两种方式装新版。另外要注意如果你之前已经通过 yum 装过 Git再想升级到新版只看yum install git是无效的因为 yum 默认不会跨大版本升级。你得先把老版本卸载掉再装新版本或者用yum update配合指定版本号。这个细节下面会展开。2.2 方式二用 IUS 仓库安装推荐省心且版本较新IUS 是一个第三方软件源全称是 Inline with Upstream Stable专门为 CentOS 和 RHEL 提供较新版本的软件包。它跟 EPEL 的区别在于IUS 更专注于把上游最新稳定版打包进 RPM而且做了严格的兼容性测试。对于想用新版 Git 又不想折腾源码编译的朋友IUS 是性价比最高的方案。先安装 EPEL 源因为 IUS 依赖 EPEL 的某些基础包yum install -y epel-release然后安装 IUS 源。这里需要先获取 IUS 的 release 包。以 CentOS 7 为例执行yum install -y https://repo.ius.io/ius-release-el7.rpm装完源之后用下面的命令搜索并安装新版 Gityum -y install git2u注意包名不是git而是git2u这是 IUS 仓库的命名规则数字代表主版本u代表 upstream。装完同样验证一下git --version如果一切正常你会看到类似git version 2.40.x的输出。这个版本相比 1.8.3.1 提升非常明显。平时我推荐朋友在生产环境用 Git基本都建议走这条路因为不需要自己维护编译参数升级也方便直接yum update git2u就能更新到 IUS 里最新的补丁版本。有个小细节假如系统里已经装过老版本 Git装了 IUS 源之后直接安装git2u可能会提示版本冲突原因是两个 RPM 都提供了/usr/bin/git这个文件。遇到这种情况先把老版本卸掉再装yum remove -y git yum install -y git2u2.3 方式三源码编译安装适合对版本有强迫症的场景源码编译适合两类人一类是需要 Git 最新版但 IUS 源还没跟进更新的朋友另一类是服务器在内网、无法访问外网 yum 源只能自己上传源码包编译的场景。源码编译的流程完整走一遍并不算复杂但有几个坑必须提前讲。首先是依赖库缺一不可。执行下面命令把编译需要的工具链和依赖库装上yum install -y gcc make autoconf curl-devel expat-devel gettext-devel openssl-devel perl-devel zlib-devel这里我解释一下每个包的作用。gcc和make是编译工具链autoconf用于生成配置文件curl-devel让 Git 支持通过 HTTP/HTTPS 协议传输数据expat-devel是 XML 解析库的依赖gettext-devel提供国际化支持openssl-devel提供 TLS/SSL 加密支持perl-devel用于构建部分辅助脚本zlib-devel是压缩算法的依赖。缺少任何一个编译过程中都可能在特定模块报错到时候再回头补装浪费的时间更多。依赖装好后去 Git 官方仓库下载源码包。可以到 https://github.com/git/git/releases 挑选版本也可以直接用 wget 下载。以 2.43.0 为例wget https://github.com/git/git/archive/refs/tags/v2.43.0.tar.gz tar -zxvf v2.43.0.tar.gz cd git-2.43.0接下来是 Configure、编译、安装三步make configure ./configure --prefix/usr/local/git make all make install这里--prefix参数很关键它决定了 Git 的安装路径。我习惯装到/usr/local/git这样和系统自带的软件分离方便管理。编译过程根据机器性能可能要花几分钟到十几分钟不等耐心等它跑完就行。装完之后要注意 PATH 问题。/usr/local/git/bin并不在 CentOS 7 的默认 PATH 里直接执行git --version可能还是显示旧版本或者提示找不到命令。需要手动配置环境变量在/etc/profile末尾追加export PATH/usr/local/git/bin:$PATH然后让配置生效source /etc/profile再验证which git git --version如果which git显示的是/usr/local/git/bin/git说明配置成功了。要是还显示/usr/bin/git说明系统自带的 Git 还在前面可以检查一下 PATH 顺序或者直接用hash -r清除命令缓存再试。注意源码编译安装的 Git 不会覆盖系统自带的/usr/bin/git。如果后面发现某些脚本仍然用的老版本建议把/usr/bin/git做个软链或者直接用绝对路径调用新版本。2.4 三种方式横向对比为了让大家做选择时心里更有数我把三种方式的优劣列成了一张表安装方式操作难度版本新旧适用场景升级方式yum 直接安装最简单老1.8.3.1临时环境、对版本无要求需换源或重装IUS 源安装简单较新2.x 系列生产环境推荐yum update git2u源码编译中等最新可选内网环境、追新版本手动下载重新编译如果你拿不准选哪个我的建议是无脑走 IUS。既兼顾了稳定性又避免了源码编译过程中可能出现的各种意外。只有当你需要特定版本比如某个企业内网规定必须用某个版本或者服务器完全上不了外网时才考虑源码编译。3. 安装后的关键配置环境变量、git config 与 SSH 密钥3.1 确保命令行能找到正确的 Git装完 Git 之后第一件事就是确认当前 shell 使用的到底是哪个 Git。这在源码编译安装的场景下尤其重要。我遇到过不止一次明明编译装好了新版本但执行git命令时用的还是系统自带的旧版原因就是 PATH 配置没生效或者顺序不对。检查方法很简单which git输出如果是/usr/bin/git说明用的是系统自带版本如果源码编译装到了/usr/local/git需要按照上面说的方式配置 PATH然后重新登录 shell 或者source /etc/profile。配置完成后再次执行which git应该显示/usr/local/git/bin/git。还有一种情况如果你是通过 IUS 源安装的git2u它默认会把二进制安装到/usr/bin/git所以不需要额外配置 PATH装完直接就能用。这一点也是我不太推荐源码编译的一个原因——对于大多数人来说环境变量这个坑不值得踩。3.2 git config 全局配置必须做Git 装好不代表配置好了。第一次使用 Git 时如果没配置用户信息执行 commit 会直接报错提示需要设置 user.name 和 user.email。这三条命令是最基本的git config --global user.name 你的名字 git config --global user.email 你的邮箱 git config --global core.editor vimuser.name和user.email会写进每次提交的元数据里别人通过 Git 历史看到的就是这些信息。core.editor是这个用户默认的文本编辑器不设置的话 Git 可能会调用 vi 或系统默认编辑器对一些习惯 nano 的人会很难受。另外我建议顺手设置一下默认分支名和 push 策略避免每次操作都要带额外参数git config --global init.defaultBranch main git config --global push.autoSetupRemote trueinit.defaultBranch main的含义是新建仓库时默认分支叫 main 而不是 master符合现在的行业习惯。push.autoSetupRemote true则是让你执行git push时自动关联到远端同名分支少打一条git push -u origin main的命令。查看所有全局配置可以执行git config --list --global配置文件路径在~/.gitconfig你也可以直接用 vim 编辑。我有时候在服务器上懒得敲命令就直接改这个文件效果一样。3.3 SSH 密钥配置免密拉取与推送的关键Git 的远程操作有两种认证方式HTTPS 和 SSH。HTTPS 每次 push 都要输密码就算配了 credential helper 也会偶尔抽风SSH 密钥配置好之后就是无感的。在 Linux 服务器上操作 Git 仓库我强烈建议直接用 SSH。生成密钥对ssh-keygen -t ed25519 -C your_emailexample.com注意这里推荐的是 ed25519 算法而不是传统的 RSA。ed25519 的密钥更短安全性更高而且 GitHub、GitLab、Gitea 等主流平台都支持。如果你的 Git 服务器版本比较老只支持 RSA那就退回用ssh-keygen -t rsa -b 4096 -C your_emailexample.com生成过程中会提示你设置文件保存路径和 passphrase。保存路径默认是~/.ssh/id_ed25519直接回车即可。passphrase 我一般留空因为服务器上的密钥如果还要输密码就失去了免密的意义。如果你担心私钥泄露的风险可以设置 passphrase再配合 ssh-agent 使用这个属于进阶玩法这里不展开。公钥位置在~/.ssh/id_ed25519.pub查看并复制内容cat ~/.ssh/id_ed25519.pub把这段内容粘贴到你的 Git 服务商后台比如 GitHub 的 Settings - SSH and GPG keys或者 Gitee 的设置页面。之后测试连接ssh -T gitgithub.com如果是 GitHub会提示Hi username! Youve successfully authenticated说明整条链路已经打通了。接下来 clone 仓库时用 SSH 协议的地址形如gitgithub.com:user/repo.git就能免密操作。3.4 安全提示私钥权限别偷懒SSH 私钥的权限必须严格控制。如果id_ed25519这个文件的权限过于宽松比如其他用户可读ssh 客户端会直接拒绝使用这个密钥报错信息是Permissions 0644 for id_ed25519 are too open。这个问题我见得太多了尤其是从 Windows 机器上复制密钥到 Linux 服务器时特别容易触发。解决办法是chmod 600 ~/.ssh/id_ed25519 chmod 700 ~/.ssh顺便说一下~/.ssh目录的权限也不能忽略最佳实践是700只允许当前用户进入。4. 常见问题与排查技巧实录4.1 yum 安装时报 Could not resolve host 或下载超时这个问题的根源多数是 DNS 配置或源的速度问题不一定是 Git 安装本身的锅。先检查网络连通性ping -c 4 mirrors.aliyun.com如果 ping 不通检查/etc/resolv.conf里的 DNS 配置。如果 ping 通但 yum 速度很慢直接把源换成阿里云镜像mv /etc/yum.repos.d/CentOS-Base.repo /etc/yum.repos.d/CentOS-Base.repo.bak curl -o /etc/yum.repos.d/CentOS-Base.repo https://mirrors.aliyun.com/repo/Centos-7.repo yum clean all yum makecache切换源之后你会发现下载速度快了一个量级。这里提醒一下CentOS 7 EOL 之后阿里云对老版本源的支持还是有的路径是mirrors.aliyun.com/centos-vault/但上面那个命令走的是官方的CentOS-Base.repo配置它会自动指向可用的镜像路径实测是没问题的。4.2 源码编译时 make: *** No rule to make target 或者报错缺少头文件这种问题几乎都是依赖没装全导致的。比如编译到一半提示cannot find -lcurl说明系统里缺少curl-devel提示zlib.h: No such file or directory说明缺少zlib-devel。解决方法就是把第一节列出的依赖包全部装一遍yum install -y gcc make autoconf curl-devel expat-devel gettext-devel openssl-devel perl-devel zlib-devel装好之后重新执行make clean再编译。很多时候问题就出在最初偷懒少装了一两个包。4.3 报错 git: command not found这个报错分两种情况。一种是真的没安装执行一下yum install -y git或者按本文其他方式安装即可。另一种是安装了但 PATH 没配好多见于源码编译安装。排查方式ls /usr/local/git/bin/git如果文件存在就说明只有 PATH 问题按照前面说的方式把/usr/local/git/bin加到 PATH 里。如果文件不存在说明编译安装过程没成功需要回到源码目录查看日志。4.4 SSL certificate problem: unable to get local issuer certificate这个报错在 CentOS 7 上特别经典因为老版本 Git 对证书链的处理不够完善或者服务器的 CA 证书库过旧。临时解决办法是关闭 SSL 校验git config --global http.sslVerify false但我非常不建议在生产环境这么干这会让你所有 Git 操作都暴露在中间人攻击的风险下。更优雅的解法是更新系统 CA 证书yum update -y ca-certificates更新后重启 Git 相关操作报错一般就消失了。如果还不行检查你访问的 Git 服务器的 SSL 证书链是否完整有些自签名证书需要手动加到系统的信任列表里。4.5 报错 Unable to negotiate with xxx.xxx.xxx.xxx port 22: no matching key exchange method这是因为老版本 Git/OpenSSH 不支持服务端要求的密钥交换算法导致的。常见于连接一些比较老或者安全策略比较激进的服务端。解决办法是在~/.ssh/config里添加Host your-git-server HostKeyAlgorithms ssh-rsa PubkeyAcceptedKeyTypes ssh-rsa KexAlgorithms diffie-hellman-group14-sha1这段配置的意思是允许使用旧版的 SSH 算法。要注意加了之后 SSRF 安全性理论上会变差一些所以只对特定的 Git 服务器生效就好不要全局添加。4.6 git clone 大仓库时卡死或内存不足这个不是安装问题但很多人装完 Git 后第一次 clone 大仓库就遇到。Git 默认会把整个仓库历史都拉下来大仓库动辄几个 GB。解决办法是使用浅克隆git clone --depth 1 gitgithub.com:user/large-repo.git--depth 1代表只拉取最新一次提交历史记录不下载。如果你之后需要完整历史可以再git fetch --unshallow补全。另外还可以考虑使用部分克隆git clone --filterblob:none gitgithub.com:user/large-repo.git这个命令会让 Git 只下载提交记录和目录树文件内容在 checkout 的时候才按需下载对于 monorepo 来说效果非常明显。4.7 常见问题速查表把上面遇到的问题整理成一张表方便大家对照排查问题现象根本原因快速解法yum 安装报错 network 相关DNS 或源不可用替换为阿里云源检查 resolv.conf编译报错缺头文件依赖包缺失安装对应的 -devel 包git 命令找不到未安装或 PATH 缺失重新安装或配置 PATHSSL 证书报错CA 证书过期yum update ca-certificatesSSH 协商失败算法不兼容在 ~/.ssh/config 中开启旧算法clone 卡死大仓库历史记录过多使用浅克隆或部分克隆4.8 我踩过的坑一次升级 Git 引发的连锁反应这里分享一个真实的经历。有一次我图省事直接在已经通过 yum 装了 git 1.8.3.1 的服务器上执行了yum install -y git2u结果报了一堆依赖冲突。我当时没细看报错直接加了--skip-broken参数结果 git2u 装上了但原有的 git 包也没卸干净导致/usr/bin/git指向了新版本但很多依赖旧版 git 的 RPM 包还在系统里。后面跑一个自动化脚本时脚本调用了git rev-parse返回结果却跟我预期不一致排查了半天才发现是版本切换导致的输出格式差异。所以后来我总结了一条铁律跨源替换软件包时一定要先彻底卸载旧包再安装新包。不要用--skip-broken这种掩盖问题的方式该卸载就卸载。尤其是 CentOS 7 这种包管理相对老旧的系统依赖关系一旦混乱起来排查成本远超重装一遍。5. 一些关于 Git 版本与生产环境的额外思考Git 安装这件事本身很简单但版本选择背后的逻辑值得多想一步。很多 CentOS 7 服务器上跑着老版本 Git并不是管理员不知道有新版而是担心升级带来的兼容性问题。这种担心有一定道理因为某些自动化脚本、编辑器集成、CI 系统可能硬编码了对 Git 输出格式的解析版本升级后行为变化会导致这些链路出问题。我建议的稳妥做法是先在测试机上把新版本 Git 跑一遍主要工作流——clone、fetch、checkout、commit、push、pull——确认没问题后再上生产机。特别是那些通过调用git命令来自动化处理的脚本一定要测试一下输出格式是否有变化。另外Git 版本这件事在容器化时代有一个新思路如果你觉得在 CentOS 7 上折腾 Git 版本很麻烦完全可以把 Git 环境封装在容器里通过挂载卷的方式操作宿主机上的仓库。之前我在一篇分享里看到过有人在 CentOS 7 里用容器跑新版 Git 客户端的方式规避底层版本限制我没试过。如果你对容器化操作比较熟也不妨往这个方向考虑。回到安装本身。如果你最终选择了源码编译安装再送你一个小技巧编译的时候加一个--with-gitconfig/etc/gitconfig参数可以把 Git 的全局配置文件位置固定到系统级目录这样多用户共用一台服务器时系统管理员可以统一配置默认行为不用每个用户单独设一遍。这个细节在实际管理多台服务器时非常有用我在团队内部就是这么部署的。