CentOS 7安装Git全指南：yum与源码编译详解

做运维的兄弟应该都有这种经历：拿到一台CentOS 7服务器，第一件事除了改密码、配网、装常用工具，基本就是装Git。这个操作看起来简单，网上教程也一抓一大把，但真到自己动手的时候，什么版本太低、编译报错、command not found各种问题全冒出来了。我这几年在CentOS 7上装Git的次数少说也有几十次，从内网离线环境到源码编译折腾过一遍，今天就把从入门到进阶的装法、配置和踩坑经验全部捋一遍，包括yum一键安装、源码编译安装、安装之后的初始化配置，还有那些文档里不会写清楚的坑，一次说明白。

这篇文章适合刚接触Linux的小白，也适合打算在生产环境里搞一套干净、可维护的Git环境的同学，读完你不仅能装好Git，还能搞懂安装背后的原理和路径选择逻辑。文章里选了一个我实际用过多年的方案作为主线，每一步都标了可复现的命令和参数，直接抄作业就行。

1. 动手之前：先搞清楚你的CentOS 7到底是什么状态

1.1 检查系统版本和基础环境，别上来就敲命令

很多人拿到服务器就开始敲yum install -y git，然后就开始等。但我建议你先花30秒确认一下系统状态，避免装到一半才发现环境不对白折腾。第一步是确认系统是不是CentOS 7，虽然听起来弱智，但真的有人把CentOS 8或者Stream当7用，然后发现命令和软件源行为完全不一样。

cat /etc/redhat-release

正常会输出类似CentOS Linux release 7.9.2009 (Core)的内容。这能确认你的系统是7.x版本。接着看下系统架构：

uname -m

服务器基本都是x86_64，但如果是个ARM的板子或者云上的ARM实例，输出的就是aarch64。这个信息决定了后面下载源码包或者添加软件源时该选哪个架构，别小看这一步，我见过有人拿x86的RPM包装到ARM机器上，结果直接报错。

再看下系统的软件源是不是好的：

yum repolist

如果这个命令执行后返回一堆repo列表，说明源能用。如果报错或者列表为空，那你后面用yum装东西百分百会失败，就得先处理源的问题。CentOS 7的源是这么多年运维绕不开的话题，官方源停止维护后，建议提前换成可用的镜像源，具体操作后面会单独说。

1.2 搞清你的安装目标：要的是稳定老版本还是新功能版本

装Git之前先想明白一个问题：你是装来自己敲代码、提交代码，还是要给团队搭一个统一的代码托管环境，或者是给CI/CD流程打基础？不同目标对应的安装方式完全不一样。

如果只是本机用一用，git版本不太旧就无所谓，那直接用系统自带的yum装最省事，几秒钟搞定，后面升级、卸载都有系统包管理器统一管理。但CentOS 7官方源里的git版本停留在了2.x的早期版本，功能上缺少一些新特性，比如部分新命令、加密协议的支持、对某些新平台密钥格式的处理。如果你要跟新的Gitea、GitLab或者某些云平台做对接，版本低有时候会出现协议不兼容的怪问题。

如果是要装最新版，或者生产环境需要固定一个已知版本做统一的交付标准，那源码编译安装是更稳的路子。Git官网的release页面可以下载任意版本的源码包，编译参数可以自己定制，装完存放在/usr/local/git下，跟系统自带的文件完全不冲突。代价是编译过程需要一点时间，还要解决一堆依赖，后面我会把整个编译过程写清楚。

另外还有一种方式是通过维护第三方软件源的社区仓库安装，这类源里通常提供了比系统源新的版本，但这类源需要额外添加repo，并且你要信任这个源的维护者。对于生产环境，我个人的建议是：要么yum老版本，要么源码编译固定版本，尽量不要引入额外的第三方源，因为后续维护依赖关系会变得很麻烦。

2. 最省事的方案：用yum一条命令装好Git

2.1 安装前更新缓存，避免装到一半报依赖错

yum安装Git本身不复杂，但在装之前我还是建议先刷新一下软件源缓存，把已有的软件包元数据更新到最新，这样能减少装到一半出现依赖解析错误的概率。尤其是你刚装完系统，第一次用yum时，缓存往往是空的。

yum clean all yum makecache

这两条命令一个清理本地缓存，一个重新生成缓存。速度取决于你的网络和源质量，如果用的是内网源或镜像源，一般几十秒就完成了。

然后就是正式安装Git：

yum install -y git

安装过程会去解析依赖，比如git依赖一些 Perl 模块和 curl 相关的库，这些都会被自动拉进来。装完以后，命令行会显示Complete!，到这一步其实Git就已经装好了。

2.2 验证安装结果和版本号

装完以后，一定要验证一下，别急着跑路：

git --version

系统源装出来的版本一般是git version 1.8.3.1或者类似的老版本。看到这个版本号，说明命令行工具已经可用了。接着再看下安装路径：

which git

通常输出是/usr/bin/git，这是yum安装的标准路径。同时可以看下git的配置文件默认路径：

git config --list --system

这条命令会列出系统级的Git配置，主要是/etc/gitconfig这个文件里的内容。如果没有内容，说明还没有做过系统级配置，也正常。

2.3 yum方式装的Git，目录和升级方式要心里有数

用yum装的Git，所有的文件都散落在系统目录下：主程序在/usr/bin/git，文档和帮助文件在/usr/share/doc/下面，还有一部分依赖库会放在/usr/share/git-core里。这种安装方式的好处是卸载非常干净，一条yum remove -y git就能全部清掉。

后续升级也简单，想升级就再次执行：

yum update -y git

但因为CentOS 7官方源里的版本基本不会更新了，这条命令大概率显示“没有可升级的软件包”。所以这种方式的优点和缺点都很明显：省事但版本旧。日常个人使用完全够，但如果遇到新特性的需求，就得考虑下面的源码编译方案了。

3. 进阶方案：源码编译安装你想要的Git版本

3.1 为什么生产环境我更喜欢编译安装

在生产环境里，我最忌讳的事情是同一个软件在不同机器上版本五花八门。今天这台系统源装的是1.8，明天那台机器换了个源装出2.27，等出了问题排查的时候，别人问一句“你哪台机器什么版本”，你就头大了。所以一旦要统一版本、统一部署标准，编译安装固定一个版本反而比yum更可控。

编译安装还有另外几个实打实的好处：一是可以指定安装前缀，把Git完全隔离在一个目录里，比如/usr/local/git，将来不要了直接删目录；二是可以决定编译哪些功能模块，比如选择是否支持subversion协同、是否编译GUI工具；三是可以对新版内核、新协议有更好的兼容性。

当然编译安装的代价是过程稍微长一点，依赖多一些。以Git 2.39.2为例，整个编译过程如果机器配置还行，大概5到10分钟能完成，可接受。

3.2 安装依赖包，一个都不能少

编译Git必须的依赖有：C编译器（gcc）、make工具、Tcl/Tk（如果你想编译gitk和git gui）、curl和curl-devel（支持HTTPS协议）、zlib-devel（压缩支持）、perl-ExtUtils-MakeMaker（Perl模块构建）、openssl-devel（SSL支持）、expat-devel（HTTP协议支持）。注意，这些依赖缺了任何一个，编译过程中都可能报错，所以千万不要跳步。

yum install -y gcc make curl curl-devel zlib-devel perl-ExtUtils-MakeMaker openssl-devel expat-devel tk-devel gettext-devel asciidoc xmlto

asciidoc和xmlto这两个包是编译文档时用的，如果你不想编译HTML和man文档，可以不用。但装上了也没坏处，编译起来会更完整。如果你在编译过程中遇到报错提示缺少某个头文件，那就回来再用yum安装对应的-devel包，这是最省心的处理方式。

3.3 下载源码、解压、指定路径编译

下载Git源码，我一般选择从Git官网下载。找到你想要的版本，比如2.39.2，下载tar.gz包：

wget https://github.com/git/git/archive/refs/tags/v2.39.2.tar.gz

如果你从github下载速度很慢，也可以直接从Git官网的release镜像下载，链接格式类似https://mirrors.edge.kernel.org/pub/software/scm/git/git-2.39.2.tar.gz，这种方式比较稳定。

下载完成后解压并进入目录：

tar -zxvf v2.39.2.tar.gz cd git-2.39.2

接下来是配置编译参数。我用的前缀路径是/usr/local/git，把Git独立安装到这个目录下，再通过软链接或PATH变量让系统找到它：

./configure --prefix=/usr/local/git --with-curl --with-expat

--with-curl是启用HTTP/HTTPS协议支持，--with-expat是启用HTTP智能协议支持。如果你不需要，可以不加，但建议都加上。配置完成后开始编译，这里可以用多核加速编译，比如4核机器就用-j4：

make -j4

如果全程没有报错，进入安装步骤：

make install

安装完成后，Git就静静地躺在/usr/local/git目录下了。

3.4 把新版本接入PATH环境变量，并验证最终效果

这一步是最容易出问题的。因为系统原来可能已经存在/usr/bin/git，而/usr/local/git/bin不一定会被搜索到，这时候你敲git --version看到的还是老版本。

我的做法是做一个软链接，把新版本的git命令链接到系统标准路径下，这样执行git时会直接命中新版本：

ln -s /usr/local/git/bin/git /usr/bin/git

如果你想更灵活一点，也可以把/usr/local/git/bin加进/etc/profile的PATH里，然后在其他机器上手动控制优先级。

软链接做完以后，重新打开终端或者执行hash -r刷新一下命令哈希表，再验证：

git --version

这时候应该能看到你编译的版本号，比如git version 2.39.2。看到这个版本，就说明你的源码编译安装彻底成功了。

3.5 其他可选组件：gitk、git gui和completion

如果编译过程中你安装了tk-devel，那么gitk和git gui应该也能用了。这两个图形工具在服务器上用得少，但本地搞个图形界面还是有用的。验证一下：

/usr/local/git/bin/gitk --version

另外，Git的补全脚本一般在contrib/completion/目录下，你可以在~/.bashrc里source一下，就能在敲git che的时候按Tab自动补全成git checkout，这个体验在命令行里非常有价值：

source /usr/local/git/contrib/completion/git-completion.bash

我一般会把这句话写进/etc/profile.d/git.sh里，这样所有用户登录都会自动加载。

4. 装完Git之后，这几步初始化配置千万别跳过

4.1 配置 user.name 和 user.email，不然提交直接报错

Git安装完以后，第一次提交代码之前，必须配置用户名和邮箱。不配的话，当你执行git commit时，会直接报错提示please tell me who you are，就是说Git不知道你是谁，没法给提交打上作者标记。

配置本地用户（当前用户）：

git config --global user.name "你的名字" git config --global user.email "your_email@example.com"

如果你想在某一个仓库里用不同的身份提交，可以去掉--global，在仓库目录里单独配置：

git config user.name "针对这个仓库的名字" git config user.email "针对这个仓库的邮箱"

这里要特别注意：邮箱信息是会被公开显示在提交历史里的，如果是开源项目，建议用一个不常接收垃圾邮件的邮箱，避免隐私泄露。我见过有人直接用公司邮箱提交到个人开源项目，后期不胜其扰。

配置完以后可以查看配置：

git config --list

4.2 换行符、别名和默认编辑器这些细节

几个比较实用的初始化设置，能让你在日常使用中少踩很多坑。

第一是换行符处理。Windows下代码默认是CRLF换行，Linux和macOS是LF。如果一个项目在Windows和Linux之间来回切换，Git默认会自动转换，但有时候转换会造成奇怪的变化。我一般建议在Linux服务器上设置：

git config --global core.autocrlf input

意思是提交时把CRLF转换成LF，检出时不转换，这样在Linux环境下存仓库里的文件保持LF，避免一些无谓的diff。

第二是别名。用久了你会发现有些命令特别长，比如git checkout、git status，完全可以简化：

git config --global alias.st status git config --global alias.co checkout git config --global alias.br branch git config --global alias.lg "log --oneline --graph --all --decorate"

配置完之后git st就是git status，git lg就是带图形展示的提交记录，效率提升不是一点点。

第三是设置默认编辑器。不设置的话，Git会调用系统默认的vi，如果你对vi不熟悉，在git commit时可能会卡在编辑器里不知道怎么退出：

git config --global core.editor vim

如果你更习惯用nano，也可以设置成nano。

4.3 SSH密钥生成和公私钥配对，让本地免密连接代码平台

用HTTPS方式连接Git仓库每次都要输密码，非常痛苦。更常用的做法是配SSH密钥，然后通过SSH协议拉代码。

生成密钥：

ssh-keygen -t rsa -b 4096 -C "your_email@example.com"

如果是一路回车，密钥会默认生成在~/.ssh/id_rsa下，私钥文件是id_rsa，公钥文件是id_rsa.pub。把公钥内容复制出来：

cat ~/.ssh/id_rsa.pub

然后把这段内容配置到你的代码托管平台后台（比如Gitee或者GitHub）的SSH keys设置里。配置完成以后，可以用下面命令测试连接：

ssh -T git@gitee.com

第一次连接的时候会询问是否确认主机指纹，输入yes回车即可。如果输出一段欢迎语，说明密钥已经配对成功，之后clone和push都不需要输密码了。

这里有一个常见的坑：SSH密钥文件的权限太开放，SSH客户端会拒绝使用。比如密钥文件权限是别人也能读写，这时候会报Permissions 0777 for 'id_rsa' are too open。解决办法：

chmod 600 ~/.ssh/id_rsa chmod 700 ~/.ssh

这个权限问题尤其容易在解压备份文件、复制其他机器的密钥时出现，一定记得检查。

5. 安装和配置中出现的问题，以及我的排查方法

5.1 安装阶段高频报错和解决方案速查

安装Git的过程中，我见过、也处理过不少报错，把最典型的几个整理出来，你可以对照排查：

这张表我建议你截图或者存一下，尤其是首次编译Git的时候，大概率用到其中一两条。

5.2 编译到最后阶段发现缺文档模块，这种情况如何补救

编译Git的时候有个比较尴尬的情况：前面各种依赖都装好了，编译过程也很顺利，但到make install阶段突然报错，提示缺少xmlto或者asciidoc相关工具。这是因为Git的文档模块需要这些工具来生成HTML和man帮助文档。如果你不关心文档，可以绕过去：

make install NO_DOCBOOK=1 NO_GETTEXT=1

加了这两个参数之后，编译系统会跳过文档生成阶段，只安装核心程序。我后来重新测试下来，发现先安装xmlto asciidoc再编译是最省心的，因为报错信息不那么直观，新手容易卡在“为什么我编译一半突然失败”上面。既然使用yum install -y asciidoc xmlto就能解决，就别在这上面省。

如果编译时没用--prefix=/usr/local/git指定前缀，默认会安装到/usr/local下面，这时候git会出现在/usr/local/bin/git。不要惊讶，路径不同而已，软链接或PATH指向对就行。

5.3 配置文件混乱导致的行为难以捉摸

Git的配置分三个层级：系统级/etc/gitconfig、用户级~/.gitconfig、仓库级.git/config。如果同一个配置项在三个层级里都出现了，仓库级的优先级最高，用户级次之，系统级最低。

我排查过不少莫名其妙的git行为，最后发现都是配置冲突导致的。比如有人全局配置了一个很长的user.name，结果在某个仓库里提交时发现作者名莫名其妙不对，一看是这个仓库的.git/config里写了一个旧的user.email。排查这种问题，用这条命令看所有配置的生效值最直观：

git config --list --show-origin

它会显示每个配置项来自哪个文件，你再结合优先级去判断到底是谁生效了。这个命令在网络上是很多Git教程不会提的，但实际排查时真的能救命。

5.4 常见运行期问题：换行符、中文文件名和SSL证书

还有一个经常被问到的坑是git status显示中文文件名变成了一串八进制的转义字符，类似"\346\265\213\350\257\225"，其实文件本身没有损坏，只是Git默认对非ASCII字符做了转义。想让中文文件名正常显示，执行：

git config --global core.quotepath false

这个设置就是热搜词里那个-c core.quotepath=false参数对应的持久化版本，很多CI/CD脚本里临时加这个参数，就是为了避免中文路径被转义。

另外一个运行期问题跟SSL证书有关。在内网环境，如果用了自签名HTTPS证书的Git服务，clone时可能报SSL certificate problem。在不推荐全局关闭证书校验的前提下，你可以针对这个仓库单独配置：

git config http.sslVerify false

但请一定注意，这个方法只用于内网可信环境。在公网环境下把sslVerify关了，等于裸奔，非常不建议。

6. 我在实际项目中的做法和一些经验收尾

我把这套东西用到实际项目里以后，新机器的Git部署基本已经变成一条标准流水线了。先说我的最终推荐方案，供你参考。

如果是临时开发机或者个人实验环境，直接yum install -y git就完事，省时间、省心，版本旧一点不影响日常工作。如果是团队统一开发环境、CI/CD构建节点或者要对接新的代码托管平台，我建议走源码编译安装固定版本，像2.39.x或者更新的稳定版，把版本号写进团队的初始化脚本里。好处以后再有人问你环境版本的时候，你可以直接说固定是哪个版本，所有机器行为一致，出了问题也好复现。

初始化这一步不要省，user.name、user.email、别名、quotepath这几个我每次必配。SSH密钥这块，如果是给服务器部署用的，建议单独生成一个专用密钥对，把私钥放在专用的部署账号下，不要用root去日常拉代码。因为一旦用root拉代码，权限问题会很麻烦，而且也不安全。

关于Git版本升级，如果你是编译安装的，后面要升版本很简单：重新下载新版本的源码包，执行同样的./configure --prefix=/usr/local/git、make && make install，覆盖安装即可。老版本的文件会被新版本覆盖，配置都保留着，不会丢。如果你是yum安装的，想升到新版本，反而更麻烦一些，需要先卸载再编译或者换源，这也是我在生产环境更倾向于编译安装的原因之一。

最后再分享一个小技巧：在CentOS 7上做完所有配置后，把配置历史保存一份，比如整理成一个install_git.sh脚本放到团队的初始化配置仓库里，下次新机器跑一遍就齐活。我在实际工作中把这个脚本跑了几十次，每次都能顺畅装好Git，基本不会为这个事再耗费精力。希望这篇文章能帮你少走弯路，有问题也可以在评论区交流你遇到的具体报错，我尽量帮你排查。