前两天帮一台老服务器重装 Git本来想着几条命令就能搞定的事结果前前后后折腾了小半个下午。yum 源慢到像拨号上网、编译依赖缺了好几个、装完以后中文文件名还乱码整个过程基本把 CentOS 7 上装 Git 能踩的坑都踩了一遍。正好趁着这个经历还在我把从选型到落地再到排错的过程完整梳理出来希望能帮最近也在头疼这件事的朋友省点时间。到底该用哪种方式装 Git装完以后怎么配置才能顺手怎么跟 Gitee、GitHub 打通这篇文章会围绕这几个问题展开。无论你是刚接触 Linux 的新手还是需要在存量机器上快速部署的老手按着下面的步骤走一遍基本不会出大问题。我先把结论放前面CentOS 7 上装 Git绝大多数场景直接用 yum 安装就够了只有少数需要最新特性的情况才值得走源码编译如果你对版本有明确要求又不想折腾编译环境官方预编译的二进制包也是一条可选路子。后面我会把每种方式的细节、命令和坑都讲透。1. 装之前先想清楚版本、权限和软件源1.1 先确认你的系统到底是不是 CentOS 7很多机器虽然登录进去看到一堆 CentOS 相关字样但具体小版本可能差得很远。装 Git 之前花十秒钟确认一下系统版本能避免后面很多不必要的误会。直接执行cat /etc/centos-release正常会输出类似CentOS Linux release 7.9.2009 (Core)的结果。如果你是拿 CentOS 7 的镜像装的虚拟机或者容器基本都在 7.x 这个范围内。这里多提一句CentOS 7 的小版本之间yum 源的配置和软件包版本差异并不大所以不用太纠结具体是 7.6 还是 7.9只要确定是 7 系后面操作都能照抄。如果输出的是其他发行版信息比如Rocky Linux或者AlmaLinux那说明你这台机器虽然界面长得像 CentOS但底层已经不是原版的 CentOS 7安装命令大概率也能用但一些源配置和依赖处理方式会有细微差别。这时候我更建议你按对应系统的官方文档走别硬套 CentOS 7 的操作。1.2 确认当前用户权限并检查是否已经装过 Git安装软件这个动作本身需要 root 权限所以先确认你当前是什么身份whoami如果输出是root那没问题如果是普通用户名那后面所有安装命令都需要加sudo比如sudo yum install -y git。这里有个经验不要全程用 root 操作配置级别的文件比如编辑/etc/profile或者/root/.ssh/下的密钥文件root 和普通用户的家目录不一样你给 root 配了 SSH 密钥切到普通用户下一样用不了。另外CentOS 7 的 minimal 安装版默认不带 Git但有些定制镜像或者你之前的同事可能已经装过。检查一下git --version如果显示git version 1.8.3.1之类的信息说明系统里已经有一套 Git 了。这个由 yum 源提供的版本确实比较老但日常提交代码、拉取分支完全没问题。如果你只是想要一个能用的 Git到这一步其实就可以收工了如果你需要更高版本或者自定义编译参数后面看第 3 节的操作。1.3 安装方式怎么选先回答三个问题网络上关于 CentOS 7 装 Git 的教程一搜一大把但很多教程只说一种方式容易让人以为那就是唯一答案。实际上安装方式的选择是和你的使用场景强相关的。在动手之前先问自己三个问题这台机器能访问外网吗还是说只能在内网环境里装你对 Git 版本有硬性要求吗比如测试环境必须和线上保持版本一致。这台机器以后要长期维护还是说只是临时用一下根据这三个问题基本可以把方案锁定下来。能访问外网、对版本没特殊要求的直接用 yum 装省时省力对版本有要求、能访问外网的优先考虑源码编译或者官方二进制包完全离线内网的就得提前准备好 rpm 包或者源码包依赖也得一起离线准备好这条路的成本最高也是大家最容易踩坑的地方。我个人的建议是能用 yum 就不要折腾源码。Git 的版本迭代虽然快但对大多数开发场景来说2.x 和 2.4x 的日常体验差距没有想象中那么大稳定可靠比版本新更重要。下面第 2 节我会把这几种方式的优劣势摊开来讲。1.4 软件源是安装的地基检查并准备 yum 源yum 之所以好用核心在于它能自动把软件依赖一起装好。这个功能依赖软件源配置也就是/etc/yum.repos.d/下的.repo文件。安装之前务必确认 yum 源是可用状态yum repolist如果列出了base、extras、updates等仓库并且数量不为 0说明源正常工作。如果命令卡住不动或者报各种无法连接的错误多半是源有问题。国内服务器尤其常见默认的 CentOS 官方源在部分网络环境下速度很慢甚至根本连不上我处理过的案例里至少有三分之一是源的问题导致的安装失败。解决办法很直接把 yum 源换成国内镜像源。CentOS 7 的镜像源配置网上很多我这里以阿里云镜像为例其他国内镜像站大同小异选一个你网络延迟低的就行。操作前先备份原始源mv /etc/yum.repos.d/CentOS-Base.repo /etc/yum.repos.d/CentOS-Base.repo.bak然后下载新的源配置CentOS 7 对应的文件名是CentOS-7.repocurl -o /etc/yum.repos.d/CentOS-Base.repo https://mirrors.aliyun.com/repo/Centos-7.repo下载完成后清理并重建缓存yum clean all yum makecache换源之后原本几十 KB 每秒的下载速度往往能直接拉满。这个操作不仅是装 Git装任何软件前都建议先确认一遍。另外注意一下镜像站提供的 repo 文件里有时候会启用epel或者extras仓库如果你的机器是内网环境换源前先确认这台机器能访问镜像站的地址不能访问就别换否则比不换还麻烦。2. 三条主流安装路线yum、源码编译、官方二进制包2.1 yum 安装快速省心但版本由源决定yum 安装 Git 是一条最常规的路线。它的优势到了一种接近“无脑”的程度一条命令装完依赖自动处理后续卸载更新也方便。命令长这样yum install -y git装完执行git --version大概率会看到git version 1.8.3.1。没有看错CentOS 7 自带源里的 Git 就是这个版本这是 2013 年左右发布的版本到今天确实已经很老了。它在功能上缺少一些新特性比如部分新协议的优化、部分新命令的调整但最核心的clone、commit、push、pull、branch、merge这些操作一点问题没有。如果你的需求只是“有个 Git 能用”那 yum 这条路线足够。特别是生产环境我反而推荐用这种方式因为它的版本是经过 CentOS 官方测试的和系统其他组件的兼容性更稳。升级也简单哪天源里更新了一条yum update -y git就能跟上。yum 安装唯一的变数是你可能会顺手装上一些用不到的依赖比如 perl 相关的包。Git 这个软件本身是 C 写的但它的部分辅助脚本用到了 Perl所以 yum 会自动把这些依赖拉进来。只要磁盘空间不是特别紧张这些依赖可以忽略不用特意去清理。2.2 源码编译版本够新够灵活但准备工作量大如果你需要安装指定版本的高版本 Git或者想自定义安装路径和编译参数那只能走源码编译。Git 的源码包很小编译时间也不算长但问题出在依赖上编译 Git 需要 gcc、make、curl、openssl、zlib 等一堆开发库任何一个缺失配置阶段就会报错而且报错信息对新手来说并不友好。源码编译的另一个问题是后续升级要靠自己。你用 yum 装的话以后yum update就能带上去源码编译的你得重新下载新版本源码再走一遍configure make make install的流程。所以除非明确需要新版本的特性否则我一般不建议普通用户走这条路。如果你确实需要走源码编译后面第 3 节会有完整步骤和依赖清单照着敲就行。2.3 官方二进制包不用编译但有路径配置成本Git 官方其实提供了预编译的二进制包主要面向一些不方便通过包管理器安装的场景。这个方案有两类选择一类是下载官方编译好的Linux x86_64二进制 tar 包解压后配置 PATH 就能用另一类是使用第三方维护的静态编译版本。这个方案的好处是版本新、不需要本地编译环境缺点也很明显所有依赖都要自己处理安装路径要自己规划环境变量要自己配。对新手来说这反而比 yum 安装多出不少步骤而且出了问题能查到的资料相对少。如果你对版本没有执念我个人不推荐这个路线。但如果你已经决定了要哪个版本后面我给了清单式的步骤照着复制粘贴也能跑通。2.4 三种方案对比怎么选最合适为了让你一眼看清差异我把三种方式的核心区别整理成一张表对比维度yum 安装源码编译官方二进制包安装速度快依赖自动处理慢编译要等快解压即用版本新旧旧一般 1.8.x可指定最新版可指定最新版依赖处理自动处理手动安装开发库手动配置运行依赖后续升级yum update 即可需重新编译需重新下载替换适合场景绝大多数日常使用有版本/自定义需求无法编译且不想用源看完这张表你应该能理解为什么我反复强调“默认选 yum”它把最复杂的两件事依赖和升级都帮你处理好了。如果你拿不准选哪个就选 yum。等哪天真遇到 yum 版本满足不了需求的场景再考虑花时间编译也不迟。3. 实操从零到能用的 Git 环境3.1 路线Ayum 安装一条命令起步先把路线 A 走完。确保 yum 源正常后执行yum install -y git安装过程会输出一堆软件包的安装信息其中你会看到 git、perl-Git、perl-TermReadKey 等包名。这里注意一下perl-Git是 Git 提供的 Perl 模块被 yum 自动作为依赖装上了这说明依赖解析已经生效。装完验证一下git --version正常情况下输出git version 1.8.3.1。到这里 Git 本体已经可用了但先别急着走还需要配置用户信息和一些默认行为见 3.3 节。另外再提一句如果你的源里配置了 EPEL也可以尝试yum install -y epel-release yum install -y gitEPEL 源里的 Git 版本会稍新一些但也非常有限不要抱有太大期待。当前网上还有一种做法是用 IUS 社区源来安装较新的 Git通过这个源可以装到 Git 2.x 的中期版本。比如先安装 IUS 源再yum install -y git2u。这个方案介于 yum 和源码编译之间有需要的可以自己研究这里不展开因为 IUS 源的维护状态目前并不算活跃生产环境我不会主动推荐。3.2 路线B源码编译安装以 Git 2.x 新版本为例如果坚持要编译安装新版 Git完整流程如下。我在一台干净的 CentOS 7 minimal 上实测过照着这条流程走能顺利跑通。第一步安装编译依赖编译 Git 最核心的四个依赖是gcc、make、curl-devel、openssl-devel再加上zlib-devel和perl-ExtUtils-MakeMakeryum install -y gcc make curl-devel openssl-devel zlib-devel perl-ExtUtils-MakeMaker这几个包的作用分别说一下gcc和make是编译工具链没有它们连./configure都跑不起来curl-devel提供 libcurl 开发头文件Git 通过它支持 HTTP/HTTPS 协议拉取远程仓库openssl-devel提供 TLS 和加密相关支持没有它 Git 无法通过 HTTPS 访问远程仓库zlib-devel提供压缩支持Git 的对象存储压缩离不开它。之所以强调curl-devel是因为网上大量教程到这一步容易漏掉缺了它编译出来的 Git 会在 HTTPS 传输时出各种诡异问题。在 CentOS 7 上用源码编译 Git这几个开发包缺一不可。第二步下载源码并解压源码包可以去 Git 官方发布的镜像地址下载也可以选择国内镜像下载速度差别很大。我自己习惯把源码放在/usr/local/src下cd /usr/local/src wget https://mirrors.edge.kernel.org/pub/software/scm/git/git-2.43.0.tar.gz tar -zxvf git-2.43.0.tar.gz cd git-2.43.0这个版本的号可以替换成你实际需要的版本比如 2.39.x、2.40.x。如果下载时提示证书错误或者连接超时可以换一个网络状况更稳定的镜像源多试几次。第三步编译安装先配置指定安装目录为/usr/local/git这样以后想删除整个 Git 环境时直接把目录删掉就行不会污染系统路径./configure --prefix/usr/local/git配置过程会检查一堆环境项目最后总结你要支持的协议。确保输出里没有明显的 error。然后编译这里用-j参数指定并行编译的进程数nproc会返回 CPU 核心数能明显加快编译速度make -j$(nproc)编译时间取决于机器配置一般几分钟到十几分钟不等。比较老的机器上不加-j参数可能要等更久。编译完成后安装make install装好的二进制在/usr/local/git/bin/git下此时直接输入git是找不到的因为系统默认的/usr/bin路径下没有这个命令。第四步让系统找到新版本的 Git这一步有二选一的做法。第一种加软链接把新版 git 链接到/usr/bin下ln -s /usr/local/git/bin/git /usr/bin/git这种方式适合单用户或者只有 root 导航的机器。第二种修改 PATH 环境变量追加/usr/local/git/binecho export PATH/usr/local/git/bin:$PATH /etc/profile.d/git.sh source /etc/profile.d/git.sh这种方式更规范对所有用户生效而且不会覆盖系统默认的/usr/bin路径。我个人推荐第二种因为软链接方式在你以后升级 Git 时容易忘记更新链接而 PATH 方式直接指向了新版本的实际位置。验证结果which git git --version看到git version 2.43.0说明源码编译安装已经成功。这里有个细节要注意如果你想同时保留系统原有的/usr/bin/git那就必须用 PATH 方式并把/usr/local/git/bin放在前面这样/usr/local/git/bin/git会优先被找到。3.3 安装后的三板斧身份信息、中文路径和默认行为Git 装好后的第一件事不是急着 clone 代码而是把用户身份信息配好。这一步非常关键因为每次提交记录里记录的 “author” 信息就来自这里。尤其在一台多人共用的服务器上如果不配置这个提交记录里会出现一长串随机生成的名字后面追责和回溯都会很痛苦。git config --global user.name 你的名字 git config --global user.email 你的邮箱这两条命令会写入当前用户家目录下的~/.gitconfig文件。查看配置文件内容cat ~/.gitconfig输出会看到[user] name 你的名字 email 你的邮箱在 CentOS 7 上特别是用 yum 装的 Git 1.8.3.1 版本还有一个非常影响体验的问题中文文件名和中文路径在git status和git log里会显示成转义后的八进制序列看起来就像乱码。原因是 Git 默认会对非 ASCII 字符做转义。解决办法是关闭这个转义git config --global core.quotepath false设置完以后再用git status查看就能正常看到中文文件名了。这一点网上教程提得不多但实际用起来几乎人人都可能碰上。另外两个提升日常体验的小配置也建议顺手写上。一个是把默认分支名设为main当前社区主流习惯另一个是开启带颜色的输出git config --global init.defaultBranch main git config --global color.ui auto最终用下面命令检查所有配置是否生效git config --list如果显示了你设置的 user、core、init、color 等各项说明配置已经生效。3.4 顺手配好编码和换行符避免团队协作隐坑在 Linux 上开发还有一种常见的坑换行符。Windows 上文件的换行符是 CRLFLinux 上是 LF。如果团队里同时有 Windows 和 Linux 的开发人员Git 的换行符处理策略会影响仓库内容的一致性。Git 有个core.autocrlf配置项Windows 上一般设置为true会在提交时把 CRLF 转成 LF检出时把 LF 转成 CRLF。但在 CentOS 7 上我建议保持默认的input行为提交时会自动把 CRLF 转换成 LF但检出时保持 LF这样能保证仓库里保存的都是 LF 格式避免因为换行符不同导致的 diff 显示混乱。git config --global core.autocrlf input这个配置在纯 Linux 环境不是必需但团队协作时建议尽早统一。配合git config --global core.quotepath false这两项一起配置能省掉后续不少沟通成本。4. 打通远程仓库SSH 密钥与 Gitee/GitHub 对接4.1 为什么推荐用 SSH 而不是 HTTPS配置好本地 Git 后下一步就是和远程仓库对接。远程仓库的访问方式主要有 HTTPS 和 SSH 两种。HTTPS 方式需要每次推送时输入用户名和密码或者个人访问令牌麻烦不说密码还可能被保存在 git 的 credential 缓存里存在安全风险。SSH 方式通过密钥对进行身份认证配置一次之后推送拉取都不需要再输密码也更安全。这里做一个简单类比HTTPS 方式像是每次进小区都要保安核对身份证SSH 方式更像是你配了一把钥匙第一次登记以后就能直接开门。所以在 Linux 服务器上我更推荐使用 SSH 方式。如果你使用国内的 Gitee码云平台SSH 方式还有一个额外优势国内网络环境下 SSH 的 22 端口往往比 HTTPS 443 端口更稳定传输速度也相对可控。4.2 生成 SSH 密钥对生成密钥的命令很简单ssh-keygen -t ed25519 -C 你的邮箱或备注这里用了ed25519算法它比传统的rsa更安全密钥更短生成更快。如果你的系统环境比较老或者某些托管平台不支持ed25519可以退回用 rsassh-keygen -t rsa -b 4096 -C 你的邮箱或备注命令执行过程中会询问保存路径默认在~/.ssh/id_ed25519和 passphrase私钥密码。如果你只是想快速打通一路上按回车使用默认值即可如果你对安全要求高可以设置一个 passphrase这样即使私钥泄露别人也无法直接使用。生成完成后用ls ~/.ssh/查看会看到两个文件id_ed25519是私钥id_ed25519.pub是公钥。私钥绝对不能泄露公钥则可以随便分发。查看公钥内容cat ~/.ssh/id_ed25519.pub复制输出的整行内容下一步要把它配置到代码托管平台。4.3 把公钥配置到 Gitee 或 GitHub登录 Gitee进入“设置” - “安全设置” - “SSH 公钥”把刚才复制的内容粘贴进去标题可以随意填方便你自己识别是哪台机器的密钥。如果常用 GitHub流程类似GitHub 的 Settings - SSH and GPG keys - New SSH key同样粘贴公钥内容。这里有一个容易被忽略的点公钥是绑定“用户”的不是绑定“项目”的。同一个账号下的所有仓库只要用同一个密钥都能免密访问。所以一台服务器只需要配置一次 SSH 密钥后续克隆、推送都不用再改配置。配置完成后验证一下连接ssh -T gitgitee.com首次连接会出现确认提示The authenticity of host gitee.com (xxx.xxx.xxx.xxx) cant be established. Are you sure you want to continue connecting (yes/no)?输入yes回车看到类似Hi 你的用户名! Youve successfully authenticated, but GITEE.COM does not provide shell access.说明密钥配置成功。如果你看到Permission denied (publickey)后面第 5 节有排查方法。4.4 克隆、推送与拉取的基本操作连通之后日常操作就很常规了。克隆一个仓库git clone gitgitee.com:你的用户名/你的仓库.git进入仓库目录后新建一个文件并提交cd 你的仓库 echo hello test.txt git add test.txt git commit -m add test.txt git push origin main这里说明一下整个流程git add是把文件从工作区加入暂存区git commit是把暂存区的内容提交到本地仓库git push是把本地提交推送到远程仓库。如果你在其他机器上改了代码需要拉取最新内容就执行git pull origin main到此一台 CentOS 7 机器的 Git 环境就算真正打通了可以直接参与团队的远程协作。4.5 换密钥或换机器时的处理建议如果你在公司和个人环境之间切换推荐给不同机器生成不同密钥分别添加到托管平台的 SSH 公钥列表里。Git 默认会使用~/.ssh/id_ed25519里的密钥如果一台机器上同时存在多个密钥可以通过~/.ssh/config文件指定不同的主机使用不同密钥Host gitee.com HostName gitee.com User git IdentityFile ~/.ssh/id_ed25519 Host github.com HostName github.com User git IdentityFile ~/.ssh/id_rsa_github这个配置属于进阶内容日常单密钥使用完全不用管但多密钥场景下它能省掉很多“认证失败”的烦恼。5. 翻车现场常见问题与排查实录5.1 yum 安装速度慢或者直接超时这个问题我遇到得最多症状是执行yum install -y git后一直卡在下载阶段或者直接报Could not resolve host、Timeout之类的错误。绝大多数原因是默认的 CentOS 官方源在当前网络环境下不可用或速度过慢。解决办法就是前面 1.4 节讲的换国内镜像源。补充一个注意点换源后如果还是慢要检查一下是不是机器上配置了代理但代理已失效或者 DNS 解析有问题。先执行curl -I https://mirrors.aliyun.com如果能快速返回 HTTP 状态码说明网络到镜像站是通的这时再yum install基本就能解决。如果这一步都不通那问题在网络层换源也解决不了。5.2 源码编译时报错缺少开发依赖源码编译的报错五花八门最常见的几种我在下面列一下configure: error: no acceptable C compiler found in $PATH没有安装 gcc执行yum install -y gcc。fatal error: openssl/crypto.h: No such file or directory缺 openssl 开发头文件执行yum install -y openssl-devel。fatal error: curl/curl.h: No such file or directory缺 curl 开发头文件执行yum install -y curl-devel。fatal error: zlib.h: No such file or directory缺 zlib 开发头文件执行yum install -y zlib-devel。fatal error: curses.h: No such file or directory缺 ncurses 开发头文件执行yum install -y ncurses-devel。这些报错信息虽然看着吓人但本质上都是依赖缺失看报错里提示的头文件名就能反推是哪个开发包没装。我建议在编译之前一次性装齐所有依赖省得跑一半停下来补装yum install -y gcc make curl-devel openssl-devel zlib-devel perl-ExtUtils-MakeMaker ncurses-devel5.3 编译装好后输入 git 提示 command not found这个问题的原因很简单新装的 git 二进制不在系统的 PATH 搜索路径里。如果你走的是软链接方案检查链接是否创建成功ls -l /usr/bin/git如果你走的是 PATH 方案检查/etc/profile.d/git.sh文件是否存在、内容是否正确然后重新登录或者执行source /etc/profile.d/git.sh让配置生效。这里再补一个排查命令确认系统到底能不能找到 gitwhich git如果显示的是/usr/local/git/bin/git说明 PATH 生效如果显示空白或者no git in ...说明路径还有问题。5.4 SSH 连接时报 Permission denied (publickey)这个报错是配置 SSH 密钥时最常看到的。排查顺序建议如下第一确认公钥是否已经复制完整并粘贴到托管平台。公钥以ssh-ed25519或ssh-rsa开头末尾是邮箱或备注复制时不要多空格、少字符。第二确认你连接用的密钥和配置到平台的是同一对。很多人生成完密钥后在 root 下配置了结果用普通用户去连接必然失败。用ssh -vT gitgitee.com查看详细调试信息能看到具体使用了哪个密钥文件。第三确认密钥文件权限是否正确。家目录下的.ssh目录权限应该是 700密钥文件权限应该是 600。如果权限过宽ssh 会主动拒绝使用chmod 700 ~/.ssh chmod 600 ~/.ssh/id_ed25519 chmod 644 ~/.ssh/id_ed25519.pub5.5 中文文件名显示成八进制乱码这个问题的原因前面已经说过是core.quotepath默认开启了转义。执行git config --global core.quotepath false之后再执行git status和git log中文文件名就能正常显示。另外如果终端本身中文乱码还要检查系统的 locale 环境是否支持 UTF-8echo $LANG正常输出应该是en_US.UTF-8或zh_CN.UTF-8。如果是POSIX或空值说明 locale 没设置好可能导致终端无法正常显示中文。5.6 连接远程仓库超时或者无法连接如果你用的托管平台是 GitHub而你的服务器在特定网络环境下访问 GitHub 不稳定频繁出现连接超时我的建议非常简单直接国内场景优先使用 Gitee。把仓库托管到 Gitee 后再把这个仓库作为中间镜像需要同步 GitHub 时在本地操作即可不需要在服务器上直接访问。从纯技术排查视角看连接远程仓库超时需要检查的点包括本机 DNS 是否正常、是否设置了系统代理检查~/.ssh/config中的ProxyCommand配置和http_proxy环境变量、远程仓库的 SSH 端口是否可达。如果这些都没问题但依然超时可以考虑用 HTTPS 方式 clone 一次作为替代看是不是只有 SSH 端口不通。5.7 多用户共用机器时的权限与归属问题服务器上多个人共用一台机器时Git 仓库的目录权限和提交身份很容易出问题。一个常见场景是root 用户创建了仓库目录普通用户进去推送代码时提示没有写权限。解决办法是用git init --sharedgroup设定仓库为组共享模式然后把目录的所属组改为多人共用的组。另外多人共用机器时严禁每个人都在自己的家目录里生成重复的 SSH 密钥而是严格遵循“一人一密钥”原则统一登记到托管平台方便后续回溯是哪台机器、哪个用户在操作。我见过一些小团队为了省事所有成员共用 root 账号操作 Git后面线上出问题根本查不到是谁提交的排查成本非常高。6. 最后分享一点个人体会我在这台 CentOS 7 上装 Git 时踩过的坑基本都写在上面的问题清单里了。装完以后我回头看了一下这次经历最大的感触是CentOS 7 上装 Git 本身没有难度真正花时间的是把软件源和依赖环境搞好。软件源不通装啥都白搭依赖缺心眼编译一次报一次错。很多人觉得 Git 是“小软件”就随便装结果恰恰是这种“随便”让后面的排查耗掉一个下午。我自己现在再遇到 CentOS 7 的机器会先按固定的流程走确认版本和权限检查 yum 源换国内镜像然后yum install -y git装完立刻配置user.name、user.email、core.quotepath false这三项再生成 SSH 密钥配置到托管平台。整套流程走下来十分钟左右基本不会再出幺蛾子。最后再给一个建议如果你只是日常写代码做版本管理yum 装的 Git 2.x 版本够用到这台机器退役如果你实在需要新版本源码编译并没有想象中可怕把依赖一次装齐照着第 3 节的步骤走也能顺利跑通。希望这篇文章能帮你少走一些弯路。