CentOS 7安装Git全攻略：yum、源码编译与SSH配置详解

前两天帮一台老服务器重装 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.repo：

curl -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”：它把最复杂的两件事（依赖和升级）都帮你处理好了。如果你拿不准选哪个，就选 yum。等哪天真遇到 yum 版本满足不了需求的场景，再考虑花时间编译也不迟。

3. 实操：从零到能用的 Git 环境

3.1 路线A：yum 安装，一条命令起步

先把路线 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 git

EPEL 源里的 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-MakeMaker：

yum 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/bin：

echo '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 上文件的换行符是 CRLF，Linux 上是 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，可以退回用 rsa：

ssh-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 git@gitee.com

首次连接会出现确认提示：

The authenticity of host 'gitee.com (xxx.xxx.xxx.xxx)' can't be established. Are you sure you want to continue connecting (yes/no)?

输入yes回车，看到类似：

Hi 你的用户名! You've successfully authenticated, but GITEE.COM does not provide shell access.

说明密钥配置成功。如果你看到Permission denied (publickey)，后面第 5 节有排查方法。

4.4 克隆、推送与拉取的基本操作

连通之后，日常操作就很常规了。克隆一个仓库：

git clone git@gitee.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-devel

5.3 编译装好后输入 git 提示 command not found

这个问题的原因很简单：新装的 git 二进制不在系统的 PATH 搜索路径里。如果你走的是软链接方案，检查链接是否创建成功：

ls -l /usr/bin/git

如果你走的是 PATH 方案，检查/etc/profile.d/git.sh文件是否存在、内容是否正确，然后重新登录或者执行source /etc/profile.d/git.sh让配置生效。

这里再补一个排查命令，确认系统到底能不能找到 git：

which git

如果显示的是/usr/local/git/bin/git，说明 PATH 生效；如果显示空白或者no git in ...，说明路径还有问题。

5.4 SSH 连接时报 Permission denied (publickey)

这个报错是配置 SSH 密钥时最常看到的。排查顺序建议如下：

第一，确认公钥是否已经复制完整并粘贴到托管平台。公钥以ssh-ed25519或ssh-rsa开头，末尾是邮箱或备注，复制时不要多空格、少字符。

第二，确认你连接用的密钥和配置到平台的是同一对。很多人生成完密钥后在 root 下配置了，结果用普通用户去连接，必然失败。用ssh -vT git@gitee.com查看详细调试信息，能看到具体使用了哪个密钥文件。

第三，确认密钥文件权限是否正确。家目录下的.ssh目录权限应该是 700，密钥文件权限应该是 600。如果权限过宽，ssh 会主动拒绝使用：

chmod 700 ~/.ssh chmod 600 ~/.ssh/id_ed25519 chmod 644 ~/.ssh/id_ed25519.pub

5.5 中文文件名显示成八进制乱码

这个问题的原因前面已经说过，是core.quotepath默认开启了转义。执行：

git config --global core.quotepath false

之后再执行git status和git log，中文文件名就能正常显示。另外，如果终端本身中文乱码，还要检查系统的 locale 环境是否支持 UTF-8：

echo $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 --shared=group设定仓库为组共享模式，然后把目录的所属组改为多人共用的组。

另外，多人共用机器时严禁每个人都在自己的家目录里生成重复的 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 节的步骤走也能顺利跑通。希望这篇文章能帮你少走一些弯路。