先说个真实经历。前阵子有同事来找我说新申请的CentOS 7机器上要跑CI脚本第一行就是git clone结果怎么弄都不行。我上去一看系统默认装着git 1.8.3.1连CI脚本里用的--filter参数都不认识。那一刻我就发现“在CentOS 7上安装Git”这件事看起来一条yum命令就完事实际坑多得很——版本老旧、依赖缺失、SSL证书、换行符、SSH密钥哪个都能卡你半天。这篇文章的目标很直接把CentOS 7上安装和配置Git的完整链路讲透。包括版本选型的理由、两种最靠谱的安装路径、装完后的初始化配置、日常使用里的高频报错以及一条完整的排查思路。无论你是刚接触Linux的运维新手还是被内网私有GitLab折磨过的老开发照着做基本都能一次跑通。1. 先想清楚CentOS 7上装Git为什么不是yum install git就完事很多教程上来就甩命令好像yum装完就万事大吉。但CentOS 7有个特殊性它虽然是2014年发布的系统生命周期一直延续到2024年默认软件源里的Git却始终停留在1.8.3.1版本这个版本老到什么程度呢2013年发布的距今已经十多年。版本老不是问题问题是老版本带来的兼容性缺口会在日常操作里反复膈应你。比如git clone --filterblob:none这种做部分克隆加速大仓库的用法1.8.3.1根本不支持再比如新版Git对ssh协议默认使用更安全的算法老版本在连接某些新搭建的Git服务器时可能直接握手失败。最恶心的是CI/CD平台很多脚本已经开始用Git 2.x的新语法而你本机装的是1.8.x脚本跑一半报错你连问题出在哪都看不出来。1.1 默认yum源的Git 1.8.3.1到底缺了什么我自己实际踩过几个比较痛的点不支持filter参数导致无法做blob:none部分克隆。你想拉一个带几百MB历史的大仓库只能全量拽下来内网环境还勉强能忍公网环境基本就等吧。不支持commit-graph老版本在大型仓库上执行git log、git status会明显变慢。那种几万次提交的仓库每次操作都感觉像卡住。对HTTP/HTTPS协议的处理比较老尤其是配合Nginx反代的Git服务器偶发报错“RPC failed; HTTP 500 curl 22”。所以如果你只是在自己机器上提交几个文件yum装个1.8.x无所谓。但如果你要做自动化、做CI/CD、管理稍大一点的团队仓库我建议直接上2.x版本。1.2 三种主流安装方式的横向对比装新版Git通常有下面几条路每个都有自己适合的场景我直接列个表对比安装方式版本难度适用场景主要缺点yum默认源1.8.3.1极低临时用、不追求新特性版本太旧坑多IUS第三方源2.x持续更新低日常开发、生产环境最推荐要信任第三方仓库、IUS已进入维护末期源码编译最新版如2.40中需要特定新版本、有编译环境编译耗时、依赖要自己凑官方二进制包2.x低能接受手动解压安装路径管理稍麻烦升级靠手动源码编译这条路我多说一句很多人一听“编译安装”就发怵其实Git的编译在Linux各软件里算非常省心的依赖不多make过程大概三到五分钟而且编译出来的是纯正最新版路径全部在/usr/local下跟系统自带的不冲突。唯一的门槛是你要先装好gcc、curl-devel、openssl-devel这些依赖缺了哪一个都会在编译中途报错后面我会展开讲。1.3 我推荐的选型结论我的建议很简单一次性编译安装最新版或者用IUS源快速装一个2.x。二选一看你有没有耐心等编译。我自己给服务器装的时候倾向于源码编译原因跟洁癖有关——IUS仓库虽然好用但它毕竟是个第三方源万一哪天仓库停止维护或者源地址变更你下次yum update的时候还得处理一堆依赖报错。事实上IUS在2023年就宣布进入维护末期了社区已经把精力转移到其他仓库上了。所以新装环境我基本上都是直接编译安装一劳永逸。2. 动手装两条可行的完整安装路径这一节直接上实操。我会把源码编译和IUS源安装两条路都完整走一遍每一步的命令、作用、以及可能报什么错都给你说清楚。你只需要选一条走到底就行。2.1 准备工作环境检查与依赖安装无论走哪条路先确认系统环境和基础工具链。登录服务器后先看下系统版本和当前git情况cat /etc/redhat-release git --version # 可能提示 command not found也可能显示1.8.3.1如果你是全新的CentOS 7很可能git都没装。如果已经装了老版本后面编译安装新版后默认PATH里的旧版会被覆盖吗这里面有个优先级问题下面讲。接着安装编译所需的依赖sudo yum -y install gcc curl-devel expat-devel gettext-devel openssl-devel zlib-devel perl-ExtUtils-MakeMaker这串依赖是这个场景的核心缺一个编译就会莫名报错。比如少了curl-devel编译时你会看到“curl/curl.h: No such file or directory”直接退出少了openssl-devel后面通过HTTPS拉代码时会提示SSL相关错误。我自己早期装的时候偷懒少装了perl-ExtUtils-MakeMaker结果make阶段一直报perl模块问题浪费了半小时。2.2 路径AIUS源快速安装适合不想折腾编译的IUS这个第三方仓库的做法很直接把官方源的包名加个后缀比如git2u这样你就不会误覆盖系统自带的旧包安装和卸载都很干净。# 安装EPEL和IUS仓库 sudo yum -y install epel-release sudo yum -y install https://repo.ius.io/ius-release-el7.rpm # 安装Git 2.x sudo yum -y install git2u # 验证 git --version装完大概显示git version 2.40.0之类的。这个方案有几条注意事项一个是我前面说的仓库维护状态。IUS的维护者已经公开表示不会再积极更新了如果要长期用建议装好后把git2u这个包的关键依赖记录下来以后迁移时心里有数。另一个是安装过程中可能遇到GPG key导入的提示yum会问你要不要导入仓库的公钥输入y就好。如果你在脚本里自动化执行需要加--nogpgcheck跳过但我不建议这么干公钥校验是对仓库可信度最基本的确认。2.3 路径B源码编译最新版最稳、最可控如果你决定一劳永逸走编译路线步骤也不复杂。先从官方源码地址下载指定版本的tar包。以Git 2.43.0为例# 下载源码包建议先到/git官网页面确认具体版本号 cd /usr/local/src wget https://www.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然后就是标准的编译三连sudo make prefix/usr/local all sudo make prefix/usr/local install这里解释下为什么prefix指定/usr/local。CentOS 7默认PATH里/usr/local/bin在/usr/bin之后但如果你用yum装的旧版本git它位于/usr/bin/git而新编译的git装在/usr/local/bin/git。这样两个版本的git在系统里会共存——git --version实际显示的取决于当前用户PATH里先找到哪个。怎么确认当前使用的是哪个版本用which git查看路径如果指向/usr/local/bin/git说明新版生效了。但如果你想彻底让新版覆盖旧版可以让/usr/local/bin的优先级更高echo export PATH/usr/local/bin:$PATH ~/.bashrc source ~/.bashrc which git # /usr/local/bin/git git --version # git version 2.43.0装完这一套再用系统的yum包管理基本就跟git无关了以后升级只需要再下载新版源码重编一次。2.4 安装后的自动化和环境验证不管用哪条路径装完都建议做一遍全局验证确保基础命令可用git --version git config --global --list git --exec-path其中git --exec-path会输出git子命令的实际目录如果你编译安装执行路径应该是/usr/local/libexec/git-core。如果这里输出异常多半是编译时某些子模块没装全常见的是git-submodule、git-svn这些附加工具缺失后续需要回头查编译日志。3. 装完只是开始全局配置、SSH密钥与首次提交很多人装完git跑通git --version就觉得自己干完活了直到第一次commit提交时看到“Please tell me who you are”才懵。Git不像某些软件装完即用它要求每个提交记录必须关联一个用户名和邮箱这是所有版本管理的基础。所以装完的第一件事不是急着clone而是把身份信息配好。3.1 必须配置的三件套user.name、user.email、core.autocrlf身份信息配置语法很简单git config --global user.name 你的名字 git config --global user.email your-emailexample.com这里的--global表示对当前系统用户全局生效换台机器重新配。命名建议跟你的团队规范对齐比如用真实姓名拼音或者工号不要在邮箱里用花里胡哨的昵称——提交者信息是给所有协作者看的保持可辨识度比彰显个性重要。接下来是core.autocrlf这个参数在Linux和Windows混用的团队里极其重要它是控制换行符转换的开关。Windows上装Git时安装向导一般默认建议你选checkout Windows style, commit Unix style对应的配置就是core.autocrlftrue。Linux/macOS上我建议直接设置core.autocrlfinput意思是提交时把CRLF转成LF检出时不做转换。如果整个团队都是Linux环境那就直接false不做任何转换。为什么要专门提这个因为换行符问题不会立刻暴露而是会在某个人用Windows打开文件后git diff瞬间多出几万个差异行全是每一行末尾的^M。遇到这种情况别慌把core.autocrlf按上述规则统一后重新检出一遍就好。3.2 配置SSH密钥让Gitee/GitHub不再每次输密码这一步是搜索热词里的高频需求。生成SSH密钥的方式在各平台一致ssh-keygen -t ed25519 -C your-emailexample.com -f ~/.ssh/id_ed25519这里推荐用ed25519算法它是目前安全性和性能最均衡的选择。老一些的教程还在用rsa -b 4096也不是不行但新搭的Git服务器有些已经默认拒绝RSA密钥了直接用ed25519省得以后折腾。生成过程中会让你设置passphrase私钥口令这个看你对安全的敏感程度。设了口令每次用私钥都要输一次密码但胜在私钥泄露了也不至于立刻被使用。不设的话更顺滑适合公司内网机器——前提是你的机器物理安全和登录口令要靠谱。生成完之后把公钥加到Git服务器cat ~/.ssh/id_ed25519.pub复制输出内容登录Gitee或GitHub在设置里找到SSH公钥管理粘贴保存。接着验证连接ssh -T gitgitee.com首次连接会提示你确认主机指纹输入yes之后如果看到类似“Hi xxx! Youve successfully authenticated”的信息说明密钥配置成功。之后clone仓库时用SSH地址gitgitee.com:用户名/仓库.git就再也不用输账号密码了。3.3 配置push.default和凭证缓存策略身份和SSH搞定之后还建议设置两个参数它们不是必需的但能让日常操作少很多心智负担。第一个是push.defaultgit config --global push.default simpleGit 2.0之后默认就是simple这个策略的意思是当前分支在upstream分支存在时只推送当前分支到同名远程分支不会出现“一次push把所有本地分支都推上去”的吓人操作。如果你是老版本升级上来的用户建议手动确认一下这个值。第二个是HTTP/HTTPS协议的凭证缓存。如果你公司用的是HTTP协议的Git服务比如内网GitLab走的http://每次push都要输账号密码很烦可以设置一个缓存时间git config --global credential.helper cache --timeout7200这个设置的实质是把凭证在内存里保留7200秒2小时期间不用重复输。注意这是明文缓存在进程内存里一定程度上牺牲了安全性在公司个人开发机上可以接受。如果访问的是第三方公网服务更稳妥的方案是用store模式明文存磁盘或者直接用SSH方式。4. 日常使用中最容易翻车的几个坑环境安装好了配置也做了可真正到了日常使用阶段你会发现还是会遇到各种“莫名其妙的报错”。这一节把我自己踩过、以及帮同事排查过的几个高频问题全部列出来每个都有场景描述和解决办法你可以直接当字典查。4.1 SSL certificate problem: unable to get local issuer certificate这个报错最常见的场景是内网GitLab/自建Git服务器用的HTTPS证书是自己签的并没有经过正规CA机构签发。git默认会校验证书链发现证书不可信就直接拒了。解法有三种按推荐程度排序第一种把自签名证书加到系统信任库正规做法所有命令行工具都能识别sudo cp my-ca.crt /etc/pki/ca-trust/source/anchors/ sudo update-ca-trust前提是你得有那个自签CA的根证书文件。如果公司搞过内部PKI这文件一般能找IT要。第二种针对单个仓库临时关闭SSL验证git config --global http.sslVerify false这个我不建议全局关闭等于把HTTPS的安全防护全部关掉了。如果一定要用也在具体某个仓库目录里设置localhost级别的关闭别把全局搞坏。第三种给特定域名配置自定义CA证书路径git config --global http.https://git.internal.example.com/.sslCAInfo /path/to/cert.pem这个写法很灵活只对特定域名生效既不用改系统信任库也不用全局关闭验证。内网环境尤其推荐。4.2 中文文件名和路径显示成八进制转义在Git仓库里放中文名文件执行git status时看到的是一串“\346\265\213\350\257\225.txt”这就是core.quotepath默认开启的效果本质是Git为了兼容非UTF-8终端故意做的转义。对绝大多数中文用户来说这个特性已经不合时宜了。关掉它git config --global core.quotepath false改完再执行git status中文文件名就能正常显示。注意这只是显示问题不影响仓库内部存储——Git内部存储文件名用的是UTF-8字节序列这个行为不区分系统和语言环境。4.3 编译安装时老是报“make: *** [xxxx] Error 1”这个报错出现时绝大多数人的第一反应是去搜索引擎复制粘贴但真正高效的思路是先看报错前面的几行那里通常藏着真正的原因。我在编译Git时遇到过典型的一种configure阶段没问题make阶段报错往上翻看到类似“cannot find -lcurl”的字样。原因很直接前面第2.1节说的curl-devel没装或者装了但Makefile没找到对应的库文件路径。另外还有一个坑某些云厂商的CentOS 7镜像预装了libcurl但缺libcurl-develconfigure检查时又碰巧能过到make时连接阶段才炸。遇到这种先执行sudo yum -y install curl-devel libcurl-devel openssl-devel然后重新从configure开始跑一遍多数情况下能解决。4.4 push代码时一直提示输入用户名密码即使配置了SSH也没用这个问题的本质是你在clone仓库时用的是HTTPS地址而不是SSH地址。很多人以为生成并配置了SSH密钥就能全局生效其实Git是“按地址走协议”的——HTTPS地址走的是用户名密码或token认证SSH地址才走密钥认证。检查方式git remote -v如果输出开头是https://那SSH密钥再正确也没用。解决办法两种一是把remote地址改成SSH格式git remote set-url origin gitgitee.com:用户名/仓库.git二是继续用HTTPS但配置credential helper或者用token替代密码这个方式今天GitHub已经强制推了Gitee也在跟进。4.5 在服务器上用git pull拉公司仓库总是提示权限不足Permission denied服务器上拉代码碰到“Permission denied (publickey)”经典报错时我一般按下面顺序排查确认当前用户是不是生成密钥的那个用户。很多人用root生成密钥然后切换到普通用户去拉代码普通用户找不到~/.ssh/id_ed25519自然认证失败。确认私钥权限。Git对私钥文件权限要求很严如果~/.ssh/id_ed25519的权限大于600OpenSSH会直接拒绝使用。改一下chmod 600 ~/.ssh/id_ed25519确认连接测试输出。执行ssh -T gitgitee.com如果还是Permission denied多半是公钥没加到Gitee账号下或者加错了把私钥复制上去了。这俩字符串长得不一样复制时注意。5. 一次完整的git clone失败排查链路有一种报错是“fatal: unable to access ...”它是个“症状”不是根因。引发它的可能原因太多了网络不通、代理设置残留、DNS解析失败、SSL证书问题、防火墙拦截、甚至服务器时间不对。我拿一次真实排查过程当例子带你走一遍完整的链路你以后再遇到就照着这个思路一步步缩圈。5.1 从最外层的网络可达性开始验证有一次我给一台新服务器配Git执行git clone时直接报“fatal: unable to access https://github.com/xxx/yyy.git/: Failed to connect to github.com port 443 after timeout”。第一反应不是去改Git配置而是先确认机器到GitHub的网络通不通ping github.com curl -I https://github.comping是验证ICMPcurl是验证HTTP层的真实连通情况。如果curl能返回响应但git报错问题多半出在Git客户端自身的配置上如果curl也超时那就是机器到目标地址的网络链路问题需要检查route -n cat /etc/resolv.conf这一步的排查顺序是有讲究的——先确认网络层通不通再分析应用层配置有没有问题顺序反了往往会越排查越乱。5.2 使用-vv模式让Git把家底全亮出来网络层确认没问题之后还是在clone时报同样的错这时候就要让Git输出更详细的调试信息GIT_TRACE1 GIT_CURL_VERBOSE1 git clone https://github.com/xxx/yyy.git加上这两个环境变量后Git会把HTTP请求的每个细节都打出来包括连接了哪个IP、走了什么代理、TLS握手状态、HTTP请求头等。那次我排查时看到日志里卡在一行“TLS certificate verify failed”——问题立刻锁定在SSL证书验证上不是网络也不是代理。再结合内网环境的自签证书特点基本就是第4.1节的问题。最后用关闭SSL验证或者导入自签CA的方式处理掉。如果你看到日志里明确有“using proxy”之类的字样那要注意是不是系统环境变量里残留了HTTP_PROXY/HTTPS_PROXY。之前帮同事排查时遇到一台机器设置了全局代理后来代理服务器下线了git访问就一直“Failed connect”清掉环境变量立刻恢复。5.3 区分Git自身问题与服务器端问题有时候问题不在客户端而在仓库服务器本身。判断方法很直接用浏览器或者curl直接访问仓库首页能打开说明服务端基本正常打不开就要看服务端的状态。这个判断很关键能帮你省下在客户端云里雾里排查半天、结果发现是对方服务宕机的时间。有一个容易忽略的点服务器系统时间偏差。Git的HTTPS协议依赖TLS证书证书有有效期。如果你的机器系统时间漂移到了证书有效期之外TLS握手会直接失败报“certificate has expired”之类的错。检查一下date再对比一下实际时间。这个问题在长期不重启的虚拟机里挺常见NTP服务没跑或者网络不通导致时间一直没同步。调整时间后git就恢复正常了。5.4 把报错信息完整记录下来的习惯最后想提醒一点遇到git报错不要只看最后一行尽量把前因后果完整复制下来。很多人截图只截了最后“fatal”然后到处发帖问“怎么回事”别人想帮你都无从下手。我在排查时最常用的组合拳是git clone 21 | tee /tmp/git-clone-error.log把完整错误输出保存到文件里再逐行分析。这个方法在处理复杂问题时尤其有效你回头复盘或者求助同事时都能直接甩出完整的日志信息不用靠记忆复述。6. 从“能装能用”到“顺手好使”命令速查与小技巧装好、配好、排好坑之后最后聊点能提升日常效率的东西。我尽量挑实用不花哨的内容每个都是我在真实工作里用得多、见效快的。6.1 高频命令速查表这个表里的命令是日常开发用到的核心场景建议保存下来场景命令说明查看当前状态git status改了什么一目了然查看文件具体改动git diff用小键盘翻页暂存部分文件git add -p一个文件分几段暂存查看提交历史git log --oneline --graph图形化看分支轨迹修改最后一次提交git commit --amend只改提交信息或补漏文件撤销暂存git reset HEAD把误add的文件退回工作区撤销工作区改动git checkout --危险操作会用再碰暂存当前所有改动git stash临时切分支时救急撤到某个历史版本git reset --hard慎用会丢提交拉取远程新分支git fetch git checkout -b origin/比git pull更可控这里提醒一句git reset --hard、git checkout --这两个操作都会丢失未提交的改动使用前务必想清楚。我见过不止一次有人本来只想切换分支手一抖把一天的改动全撤销了非常糟心。6.2 几个让人“用得爽”的小配置一个经常被低估的配置是增加默认的push自动设置upstream。老版本Git第一次push新分支时会提示你指定远程分支名git push -u origin branch每次敲四个关键词很烦。在Git 2.37之后可以设置push.autoSetupRemote为true之后新分支push会自动设置upstreamgit config --global push.autoSetupRemote true这个配置我强烈推荐是这两年Git新增配置里最省心的一个。另外一个是分支提示符。在bash提示符里显示当前git分支能大幅减少git branch和git status的输入频率。CentOS 7自带bash-completion只需在.bashrc里加一行source /etc/bash_completion.d/git PS1[\u\h \W$(__git_ps1 (%s))]\$ 改完source ~/.bashrc提示符就会变成类似[rootlocalhost repo (main)]的样子当前分支一眼可见。6.3 一次大规模升级的验证清单如果是给现有的生产服务器升级Git版本我建议升级前后照着下面的清单过一遍升级前备份当前git配置文件cp ~/.gitconfig ~/.gitconfig.bak确认当前全局配置无异常git config --global --list升级后验证基础命令git --version、git status、git clone验证SSH连接ssh -T gitgitee.com找一个中小型仓库跑一遍完整工作流clone、branch、commit、push、pull如果机器上有CI脚本抽一条最常用的跑一遍确认没问题这个清单是我每次在生产环境动Git版本时都会走的流程虽然简单但能避免大部分“升完级才发现某些脚本跑不动”的风险。6.4 最后再分享一个我踩过坑后的习惯我现在每在一台新服务器上装完Git都会顺手把安装时间、方式、版本号、配置了什么参数记在一个项目笔记里。不是形式化的文档就几行字的事。可一旦这台服务器半年后出问题翻一下笔记立刻就知道当初装的是哪个版本、走的是哪条安装路径排查范围一下子就缩小了。还有一个小习惯升级Git时永远不要直接卸载旧版本再装新版。先装新版测试无误后再决定要不要清理旧版。这样即使新版环境有问题你还能随时切回旧版继续干活不用干等着修复。Git本身是能多版本共存的没必要学其他软件“先卸载再装新版”。
CentOS 7安装配置Git超全指南：源码编译、SSH密钥与排坑技巧
先说个真实经历。前阵子有同事来找我说新申请的CentOS 7机器上要跑CI脚本第一行就是git clone结果怎么弄都不行。我上去一看系统默认装着git 1.8.3.1连CI脚本里用的--filter参数都不认识。那一刻我就发现“在CentOS 7上安装Git”这件事看起来一条yum命令就完事实际坑多得很——版本老旧、依赖缺失、SSL证书、换行符、SSH密钥哪个都能卡你半天。这篇文章的目标很直接把CentOS 7上安装和配置Git的完整链路讲透。包括版本选型的理由、两种最靠谱的安装路径、装完后的初始化配置、日常使用里的高频报错以及一条完整的排查思路。无论你是刚接触Linux的运维新手还是被内网私有GitLab折磨过的老开发照着做基本都能一次跑通。1. 先想清楚CentOS 7上装Git为什么不是yum install git就完事很多教程上来就甩命令好像yum装完就万事大吉。但CentOS 7有个特殊性它虽然是2014年发布的系统生命周期一直延续到2024年默认软件源里的Git却始终停留在1.8.3.1版本这个版本老到什么程度呢2013年发布的距今已经十多年。版本老不是问题问题是老版本带来的兼容性缺口会在日常操作里反复膈应你。比如git clone --filterblob:none这种做部分克隆加速大仓库的用法1.8.3.1根本不支持再比如新版Git对ssh协议默认使用更安全的算法老版本在连接某些新搭建的Git服务器时可能直接握手失败。最恶心的是CI/CD平台很多脚本已经开始用Git 2.x的新语法而你本机装的是1.8.x脚本跑一半报错你连问题出在哪都看不出来。1.1 默认yum源的Git 1.8.3.1到底缺了什么我自己实际踩过几个比较痛的点不支持filter参数导致无法做blob:none部分克隆。你想拉一个带几百MB历史的大仓库只能全量拽下来内网环境还勉强能忍公网环境基本就等吧。不支持commit-graph老版本在大型仓库上执行git log、git status会明显变慢。那种几万次提交的仓库每次操作都感觉像卡住。对HTTP/HTTPS协议的处理比较老尤其是配合Nginx反代的Git服务器偶发报错“RPC failed; HTTP 500 curl 22”。所以如果你只是在自己机器上提交几个文件yum装个1.8.x无所谓。但如果你要做自动化、做CI/CD、管理稍大一点的团队仓库我建议直接上2.x版本。1.2 三种主流安装方式的横向对比装新版Git通常有下面几条路每个都有自己适合的场景我直接列个表对比安装方式版本难度适用场景主要缺点yum默认源1.8.3.1极低临时用、不追求新特性版本太旧坑多IUS第三方源2.x持续更新低日常开发、生产环境最推荐要信任第三方仓库、IUS已进入维护末期源码编译最新版如2.40中需要特定新版本、有编译环境编译耗时、依赖要自己凑官方二进制包2.x低能接受手动解压安装路径管理稍麻烦升级靠手动源码编译这条路我多说一句很多人一听“编译安装”就发怵其实Git的编译在Linux各软件里算非常省心的依赖不多make过程大概三到五分钟而且编译出来的是纯正最新版路径全部在/usr/local下跟系统自带的不冲突。唯一的门槛是你要先装好gcc、curl-devel、openssl-devel这些依赖缺了哪一个都会在编译中途报错后面我会展开讲。1.3 我推荐的选型结论我的建议很简单一次性编译安装最新版或者用IUS源快速装一个2.x。二选一看你有没有耐心等编译。我自己给服务器装的时候倾向于源码编译原因跟洁癖有关——IUS仓库虽然好用但它毕竟是个第三方源万一哪天仓库停止维护或者源地址变更你下次yum update的时候还得处理一堆依赖报错。事实上IUS在2023年就宣布进入维护末期了社区已经把精力转移到其他仓库上了。所以新装环境我基本上都是直接编译安装一劳永逸。2. 动手装两条可行的完整安装路径这一节直接上实操。我会把源码编译和IUS源安装两条路都完整走一遍每一步的命令、作用、以及可能报什么错都给你说清楚。你只需要选一条走到底就行。2.1 准备工作环境检查与依赖安装无论走哪条路先确认系统环境和基础工具链。登录服务器后先看下系统版本和当前git情况cat /etc/redhat-release git --version # 可能提示 command not found也可能显示1.8.3.1如果你是全新的CentOS 7很可能git都没装。如果已经装了老版本后面编译安装新版后默认PATH里的旧版会被覆盖吗这里面有个优先级问题下面讲。接着安装编译所需的依赖sudo yum -y install gcc curl-devel expat-devel gettext-devel openssl-devel zlib-devel perl-ExtUtils-MakeMaker这串依赖是这个场景的核心缺一个编译就会莫名报错。比如少了curl-devel编译时你会看到“curl/curl.h: No such file or directory”直接退出少了openssl-devel后面通过HTTPS拉代码时会提示SSL相关错误。我自己早期装的时候偷懒少装了perl-ExtUtils-MakeMaker结果make阶段一直报perl模块问题浪费了半小时。2.2 路径AIUS源快速安装适合不想折腾编译的IUS这个第三方仓库的做法很直接把官方源的包名加个后缀比如git2u这样你就不会误覆盖系统自带的旧包安装和卸载都很干净。# 安装EPEL和IUS仓库 sudo yum -y install epel-release sudo yum -y install https://repo.ius.io/ius-release-el7.rpm # 安装Git 2.x sudo yum -y install git2u # 验证 git --version装完大概显示git version 2.40.0之类的。这个方案有几条注意事项一个是我前面说的仓库维护状态。IUS的维护者已经公开表示不会再积极更新了如果要长期用建议装好后把git2u这个包的关键依赖记录下来以后迁移时心里有数。另一个是安装过程中可能遇到GPG key导入的提示yum会问你要不要导入仓库的公钥输入y就好。如果你在脚本里自动化执行需要加--nogpgcheck跳过但我不建议这么干公钥校验是对仓库可信度最基本的确认。2.3 路径B源码编译最新版最稳、最可控如果你决定一劳永逸走编译路线步骤也不复杂。先从官方源码地址下载指定版本的tar包。以Git 2.43.0为例# 下载源码包建议先到/git官网页面确认具体版本号 cd /usr/local/src wget https://www.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然后就是标准的编译三连sudo make prefix/usr/local all sudo make prefix/usr/local install这里解释下为什么prefix指定/usr/local。CentOS 7默认PATH里/usr/local/bin在/usr/bin之后但如果你用yum装的旧版本git它位于/usr/bin/git而新编译的git装在/usr/local/bin/git。这样两个版本的git在系统里会共存——git --version实际显示的取决于当前用户PATH里先找到哪个。怎么确认当前使用的是哪个版本用which git查看路径如果指向/usr/local/bin/git说明新版生效了。但如果你想彻底让新版覆盖旧版可以让/usr/local/bin的优先级更高echo export PATH/usr/local/bin:$PATH ~/.bashrc source ~/.bashrc which git # /usr/local/bin/git git --version # git version 2.43.0装完这一套再用系统的yum包管理基本就跟git无关了以后升级只需要再下载新版源码重编一次。2.4 安装后的自动化和环境验证不管用哪条路径装完都建议做一遍全局验证确保基础命令可用git --version git config --global --list git --exec-path其中git --exec-path会输出git子命令的实际目录如果你编译安装执行路径应该是/usr/local/libexec/git-core。如果这里输出异常多半是编译时某些子模块没装全常见的是git-submodule、git-svn这些附加工具缺失后续需要回头查编译日志。3. 装完只是开始全局配置、SSH密钥与首次提交很多人装完git跑通git --version就觉得自己干完活了直到第一次commit提交时看到“Please tell me who you are”才懵。Git不像某些软件装完即用它要求每个提交记录必须关联一个用户名和邮箱这是所有版本管理的基础。所以装完的第一件事不是急着clone而是把身份信息配好。3.1 必须配置的三件套user.name、user.email、core.autocrlf身份信息配置语法很简单git config --global user.name 你的名字 git config --global user.email your-emailexample.com这里的--global表示对当前系统用户全局生效换台机器重新配。命名建议跟你的团队规范对齐比如用真实姓名拼音或者工号不要在邮箱里用花里胡哨的昵称——提交者信息是给所有协作者看的保持可辨识度比彰显个性重要。接下来是core.autocrlf这个参数在Linux和Windows混用的团队里极其重要它是控制换行符转换的开关。Windows上装Git时安装向导一般默认建议你选checkout Windows style, commit Unix style对应的配置就是core.autocrlftrue。Linux/macOS上我建议直接设置core.autocrlfinput意思是提交时把CRLF转成LF检出时不做转换。如果整个团队都是Linux环境那就直接false不做任何转换。为什么要专门提这个因为换行符问题不会立刻暴露而是会在某个人用Windows打开文件后git diff瞬间多出几万个差异行全是每一行末尾的^M。遇到这种情况别慌把core.autocrlf按上述规则统一后重新检出一遍就好。3.2 配置SSH密钥让Gitee/GitHub不再每次输密码这一步是搜索热词里的高频需求。生成SSH密钥的方式在各平台一致ssh-keygen -t ed25519 -C your-emailexample.com -f ~/.ssh/id_ed25519这里推荐用ed25519算法它是目前安全性和性能最均衡的选择。老一些的教程还在用rsa -b 4096也不是不行但新搭的Git服务器有些已经默认拒绝RSA密钥了直接用ed25519省得以后折腾。生成过程中会让你设置passphrase私钥口令这个看你对安全的敏感程度。设了口令每次用私钥都要输一次密码但胜在私钥泄露了也不至于立刻被使用。不设的话更顺滑适合公司内网机器——前提是你的机器物理安全和登录口令要靠谱。生成完之后把公钥加到Git服务器cat ~/.ssh/id_ed25519.pub复制输出内容登录Gitee或GitHub在设置里找到SSH公钥管理粘贴保存。接着验证连接ssh -T gitgitee.com首次连接会提示你确认主机指纹输入yes之后如果看到类似“Hi xxx! Youve successfully authenticated”的信息说明密钥配置成功。之后clone仓库时用SSH地址gitgitee.com:用户名/仓库.git就再也不用输账号密码了。3.3 配置push.default和凭证缓存策略身份和SSH搞定之后还建议设置两个参数它们不是必需的但能让日常操作少很多心智负担。第一个是push.defaultgit config --global push.default simpleGit 2.0之后默认就是simple这个策略的意思是当前分支在upstream分支存在时只推送当前分支到同名远程分支不会出现“一次push把所有本地分支都推上去”的吓人操作。如果你是老版本升级上来的用户建议手动确认一下这个值。第二个是HTTP/HTTPS协议的凭证缓存。如果你公司用的是HTTP协议的Git服务比如内网GitLab走的http://每次push都要输账号密码很烦可以设置一个缓存时间git config --global credential.helper cache --timeout7200这个设置的实质是把凭证在内存里保留7200秒2小时期间不用重复输。注意这是明文缓存在进程内存里一定程度上牺牲了安全性在公司个人开发机上可以接受。如果访问的是第三方公网服务更稳妥的方案是用store模式明文存磁盘或者直接用SSH方式。4. 日常使用中最容易翻车的几个坑环境安装好了配置也做了可真正到了日常使用阶段你会发现还是会遇到各种“莫名其妙的报错”。这一节把我自己踩过、以及帮同事排查过的几个高频问题全部列出来每个都有场景描述和解决办法你可以直接当字典查。4.1 SSL certificate problem: unable to get local issuer certificate这个报错最常见的场景是内网GitLab/自建Git服务器用的HTTPS证书是自己签的并没有经过正规CA机构签发。git默认会校验证书链发现证书不可信就直接拒了。解法有三种按推荐程度排序第一种把自签名证书加到系统信任库正规做法所有命令行工具都能识别sudo cp my-ca.crt /etc/pki/ca-trust/source/anchors/ sudo update-ca-trust前提是你得有那个自签CA的根证书文件。如果公司搞过内部PKI这文件一般能找IT要。第二种针对单个仓库临时关闭SSL验证git config --global http.sslVerify false这个我不建议全局关闭等于把HTTPS的安全防护全部关掉了。如果一定要用也在具体某个仓库目录里设置localhost级别的关闭别把全局搞坏。第三种给特定域名配置自定义CA证书路径git config --global http.https://git.internal.example.com/.sslCAInfo /path/to/cert.pem这个写法很灵活只对特定域名生效既不用改系统信任库也不用全局关闭验证。内网环境尤其推荐。4.2 中文文件名和路径显示成八进制转义在Git仓库里放中文名文件执行git status时看到的是一串“\346\265\213\350\257\225.txt”这就是core.quotepath默认开启的效果本质是Git为了兼容非UTF-8终端故意做的转义。对绝大多数中文用户来说这个特性已经不合时宜了。关掉它git config --global core.quotepath false改完再执行git status中文文件名就能正常显示。注意这只是显示问题不影响仓库内部存储——Git内部存储文件名用的是UTF-8字节序列这个行为不区分系统和语言环境。4.3 编译安装时老是报“make: *** [xxxx] Error 1”这个报错出现时绝大多数人的第一反应是去搜索引擎复制粘贴但真正高效的思路是先看报错前面的几行那里通常藏着真正的原因。我在编译Git时遇到过典型的一种configure阶段没问题make阶段报错往上翻看到类似“cannot find -lcurl”的字样。原因很直接前面第2.1节说的curl-devel没装或者装了但Makefile没找到对应的库文件路径。另外还有一个坑某些云厂商的CentOS 7镜像预装了libcurl但缺libcurl-develconfigure检查时又碰巧能过到make时连接阶段才炸。遇到这种先执行sudo yum -y install curl-devel libcurl-devel openssl-devel然后重新从configure开始跑一遍多数情况下能解决。4.4 push代码时一直提示输入用户名密码即使配置了SSH也没用这个问题的本质是你在clone仓库时用的是HTTPS地址而不是SSH地址。很多人以为生成并配置了SSH密钥就能全局生效其实Git是“按地址走协议”的——HTTPS地址走的是用户名密码或token认证SSH地址才走密钥认证。检查方式git remote -v如果输出开头是https://那SSH密钥再正确也没用。解决办法两种一是把remote地址改成SSH格式git remote set-url origin gitgitee.com:用户名/仓库.git二是继续用HTTPS但配置credential helper或者用token替代密码这个方式今天GitHub已经强制推了Gitee也在跟进。4.5 在服务器上用git pull拉公司仓库总是提示权限不足Permission denied服务器上拉代码碰到“Permission denied (publickey)”经典报错时我一般按下面顺序排查确认当前用户是不是生成密钥的那个用户。很多人用root生成密钥然后切换到普通用户去拉代码普通用户找不到~/.ssh/id_ed25519自然认证失败。确认私钥权限。Git对私钥文件权限要求很严如果~/.ssh/id_ed25519的权限大于600OpenSSH会直接拒绝使用。改一下chmod 600 ~/.ssh/id_ed25519确认连接测试输出。执行ssh -T gitgitee.com如果还是Permission denied多半是公钥没加到Gitee账号下或者加错了把私钥复制上去了。这俩字符串长得不一样复制时注意。5. 一次完整的git clone失败排查链路有一种报错是“fatal: unable to access ...”它是个“症状”不是根因。引发它的可能原因太多了网络不通、代理设置残留、DNS解析失败、SSL证书问题、防火墙拦截、甚至服务器时间不对。我拿一次真实排查过程当例子带你走一遍完整的链路你以后再遇到就照着这个思路一步步缩圈。5.1 从最外层的网络可达性开始验证有一次我给一台新服务器配Git执行git clone时直接报“fatal: unable to access https://github.com/xxx/yyy.git/: Failed to connect to github.com port 443 after timeout”。第一反应不是去改Git配置而是先确认机器到GitHub的网络通不通ping github.com curl -I https://github.comping是验证ICMPcurl是验证HTTP层的真实连通情况。如果curl能返回响应但git报错问题多半出在Git客户端自身的配置上如果curl也超时那就是机器到目标地址的网络链路问题需要检查route -n cat /etc/resolv.conf这一步的排查顺序是有讲究的——先确认网络层通不通再分析应用层配置有没有问题顺序反了往往会越排查越乱。5.2 使用-vv模式让Git把家底全亮出来网络层确认没问题之后还是在clone时报同样的错这时候就要让Git输出更详细的调试信息GIT_TRACE1 GIT_CURL_VERBOSE1 git clone https://github.com/xxx/yyy.git加上这两个环境变量后Git会把HTTP请求的每个细节都打出来包括连接了哪个IP、走了什么代理、TLS握手状态、HTTP请求头等。那次我排查时看到日志里卡在一行“TLS certificate verify failed”——问题立刻锁定在SSL证书验证上不是网络也不是代理。再结合内网环境的自签证书特点基本就是第4.1节的问题。最后用关闭SSL验证或者导入自签CA的方式处理掉。如果你看到日志里明确有“using proxy”之类的字样那要注意是不是系统环境变量里残留了HTTP_PROXY/HTTPS_PROXY。之前帮同事排查时遇到一台机器设置了全局代理后来代理服务器下线了git访问就一直“Failed connect”清掉环境变量立刻恢复。5.3 区分Git自身问题与服务器端问题有时候问题不在客户端而在仓库服务器本身。判断方法很直接用浏览器或者curl直接访问仓库首页能打开说明服务端基本正常打不开就要看服务端的状态。这个判断很关键能帮你省下在客户端云里雾里排查半天、结果发现是对方服务宕机的时间。有一个容易忽略的点服务器系统时间偏差。Git的HTTPS协议依赖TLS证书证书有有效期。如果你的机器系统时间漂移到了证书有效期之外TLS握手会直接失败报“certificate has expired”之类的错。检查一下date再对比一下实际时间。这个问题在长期不重启的虚拟机里挺常见NTP服务没跑或者网络不通导致时间一直没同步。调整时间后git就恢复正常了。5.4 把报错信息完整记录下来的习惯最后想提醒一点遇到git报错不要只看最后一行尽量把前因后果完整复制下来。很多人截图只截了最后“fatal”然后到处发帖问“怎么回事”别人想帮你都无从下手。我在排查时最常用的组合拳是git clone 21 | tee /tmp/git-clone-error.log把完整错误输出保存到文件里再逐行分析。这个方法在处理复杂问题时尤其有效你回头复盘或者求助同事时都能直接甩出完整的日志信息不用靠记忆复述。6. 从“能装能用”到“顺手好使”命令速查与小技巧装好、配好、排好坑之后最后聊点能提升日常效率的东西。我尽量挑实用不花哨的内容每个都是我在真实工作里用得多、见效快的。6.1 高频命令速查表这个表里的命令是日常开发用到的核心场景建议保存下来场景命令说明查看当前状态git status改了什么一目了然查看文件具体改动git diff用小键盘翻页暂存部分文件git add -p一个文件分几段暂存查看提交历史git log --oneline --graph图形化看分支轨迹修改最后一次提交git commit --amend只改提交信息或补漏文件撤销暂存git reset HEAD把误add的文件退回工作区撤销工作区改动git checkout --危险操作会用再碰暂存当前所有改动git stash临时切分支时救急撤到某个历史版本git reset --hard慎用会丢提交拉取远程新分支git fetch git checkout -b origin/比git pull更可控这里提醒一句git reset --hard、git checkout --这两个操作都会丢失未提交的改动使用前务必想清楚。我见过不止一次有人本来只想切换分支手一抖把一天的改动全撤销了非常糟心。6.2 几个让人“用得爽”的小配置一个经常被低估的配置是增加默认的push自动设置upstream。老版本Git第一次push新分支时会提示你指定远程分支名git push -u origin branch每次敲四个关键词很烦。在Git 2.37之后可以设置push.autoSetupRemote为true之后新分支push会自动设置upstreamgit config --global push.autoSetupRemote true这个配置我强烈推荐是这两年Git新增配置里最省心的一个。另外一个是分支提示符。在bash提示符里显示当前git分支能大幅减少git branch和git status的输入频率。CentOS 7自带bash-completion只需在.bashrc里加一行source /etc/bash_completion.d/git PS1[\u\h \W$(__git_ps1 (%s))]\$ 改完source ~/.bashrc提示符就会变成类似[rootlocalhost repo (main)]的样子当前分支一眼可见。6.3 一次大规模升级的验证清单如果是给现有的生产服务器升级Git版本我建议升级前后照着下面的清单过一遍升级前备份当前git配置文件cp ~/.gitconfig ~/.gitconfig.bak确认当前全局配置无异常git config --global --list升级后验证基础命令git --version、git status、git clone验证SSH连接ssh -T gitgitee.com找一个中小型仓库跑一遍完整工作流clone、branch、commit、push、pull如果机器上有CI脚本抽一条最常用的跑一遍确认没问题这个清单是我每次在生产环境动Git版本时都会走的流程虽然简单但能避免大部分“升完级才发现某些脚本跑不动”的风险。6.4 最后再分享一个我踩过坑后的习惯我现在每在一台新服务器上装完Git都会顺手把安装时间、方式、版本号、配置了什么参数记在一个项目笔记里。不是形式化的文档就几行字的事。可一旦这台服务器半年后出问题翻一下笔记立刻就知道当初装的是哪个版本、走的是哪条安装路径排查范围一下子就缩小了。还有一个小习惯升级Git时永远不要直接卸载旧版本再装新版。先装新版测试无误后再决定要不要清理旧版。这样即使新版环境有问题你还能随时切回旧版继续干活不用干等着修复。Git本身是能多版本共存的没必要学其他软件“先卸载再装新版”。
计算原理与投资决策实战指南)
