一台在生产网段里跑了两年的应用服务器运维只丢过来一句话这台机器要接代码仓库把 Git 装上机器不能出网。你手里能用的只有一台能联网的笔记本和一个 U 盘或者一个允许单向摆渡的内网跳板机。这就是 Linux 离线安装 Git 的典型现场——它不是把安装包拷过去敲个回车那么简单难点从来不在「装」而在「目标机上什么都没有」。很多人第一次做这件事会下意识去搜索某个 rpm 或者 deb 包拷过去rpm -ivh然后被一串依赖报错打回来第二次改去源码编译./configure就卡在zlib.h: No such file or directory。我前后在几十台隔离环境里做过这件事从 CentOS 6 的老业务机、内网麒麟系统的工作站到没有 yum 源的容器基础镜像路线差别极大。这篇就把三条主流路线源码编译、离线包安装、便携二进制各自的前置条件、依赖打包方法、编译参数取舍以及那些只在离线场景才会出现的坑完整拆一遍。1. 装之前先花十分钟摸清目标机比直接开干省两小时离线安装最忌讳的是「在联网机上按自己的习惯准备好一切然后到目标机上才发现对不上」。目标机的 CPU 架构、发行版版本、glibc 版本、有没有编译工具链这四件事直接决定了你能走哪条路。这一步花十分钟能避免后面反复摆渡几十上百兆的数据包。1.1 三个必须先问清楚的问题第一个问题是架构。x86_64 是老生常谈但现在内网里 aarch64ARM 服务器、部分信创整机非常常见甚至能碰到 loongarch64。架构搞错所有 rpm 和 deb 都是废纸源码编译出来的二进制也跑不起来。uname -m一条命令就能确认别靠猜。第二个问题是发行版和版本号。CentOS 7、RHEL 8、Ubuntu 20.04、Debian 11这四种环境下的包名、路径、CA 证书位置全都不一样。同样是 zlib 的开发包RHEL 系叫zlib-develDebian 系叫zlib1g-dev同样是 CA 证书RHEL 系在/etc/pki/tls/certs/ca-bundle.crtDebian 系在/etc/ssl/certs/ca-certificates.crt。这个差异在最后配 HTTPS 的时候会让你抓狂。第三个问题是目标机上到底有没有可用的软件源。这一点最容易被忽略。很多所谓「离线」的环境其实内网有自建的软件源或者本地 ISO 挂载yum install git直接就能装。上机第一件事是执行yum repolist或者apt-cache policy git能装就别折腾编译。我见过有人花了三个小时源码编译结果发现内网源里躺着现成的包纯粹是自己没先看一眼。1.2 glibc 版本决定了你天花板在哪里Git 主程序本身对 glibc 的要求不算激进但它依赖的 curl、openssl、zlib 这些库会随版本更新不断抬高门槛。更麻烦的是编译链路如果目标机的 gcc 和 glibc 太老典型是 CentOS 6 的 glibc 2.12较新版本的工具链在某些环节会引入对新符号的引用链接阶段就会爆出类似undefined reference to memcpyGLIBC_2.14的报错。这不是 Git 的代码问题是编译器优化策略和新旧 libc 的接口差异导致的历史遗留。所以判断逻辑很简单如果目标机是 CentOS 6 / RHEL 6 这一代不要试图上最新版 Git选 2.20 到 2.30 之间的版本成功率高得多如果是 CentOS 7 / RHEL 7 这一代glibc 2.17Git 2.40 前后基本都能编过RHEL 8 / Ubuntu 20.04 及以上就没什么限制了。判断 glibc 版本用ldd --version | head -n 1一般会输出类似ldd (GNU libc) 2.17。顺带看一眼内核版本uname -r内核主要影响的是 git daemon 这类网络功能的行为对编译本身影响不大。1.3 一份可以直接抄的侦察命令清单下面这些命令按照顺序在目标机上跑一遍输出全部记下来。这套清单我在每台新机器上都会走一遍比凭印象靠谱得多uname -m # 架构x86_64 / aarch64 / loongarch64 cat /etc/os-release # 发行版与版本号 ldd --version | head -n 1 # glibc 版本 gcc --version # 有没有编译工具链版本多少 make --version # make 版本注意 GNU Make 3.81 的并行编译问题 which git git --version # 是否已经装了老版本 Git rpm -qa | grep -E zlib|curl|openssl|expat|perl # RHEL 系看已装库 rpm -q zlib-devel openssl-devel libcurl-devel # 关键开发包是否存在 df -h /usr/local # 预留空间编译加安装至少要 1GB id # 当前是不是 root不是的话有没有 sudo date # 系统时间后面验证 TLS 时要用输出里有两项特别值得单独盯一下。一个是make --versionGNU Make 3.81 是 CentOS 6 时代的产物它的-j并行编译在多核机器上偶发任务调度错乱遇到诡异的中断可以把并发降到-j2试试。另一个是date离线机器的时钟经常飘得很离谱这个问题会在后面做 HTTPS 拉取时以「证书尚未生效」的面目出现让人完全摸不着头脑。2. 源码编译、离线包、便携二进制三条路各自的死穴摸清环境之后就可以选路线了。这三条路没有绝对优劣只有场景匹配度。我自己的判断顺序是有内网源就用源没源但目标机有 gcc 就编译两者都不满足才考虑便携二进制。2.1 源码编译可控性最高代价是依赖链最长源码编译的好处是版本完全可控编译参数可以裁剪装到独立目录不污染系统包管理器的状态。缺点是你要在目标机上凑齐一整套编译依赖这些依赖又必须在联网机上按目标机完全相同的版本提前下载好。编译耗时也要有心理预期。一台 4 核 8G 的机器Git 全量编译加安装大概 3 到 8 分钟如果是单核的老旧虚拟机make十分钟以上很正常。如果开了文档生成asciidoc docbook2x时间会翻好几倍所以我在离线场景下基本都会关掉文档。2.2 离线包安装最快但版本往往老旧RHEL 系走yumdownloader --resolveDebian 系走apt-get --download-only把包和依赖一次性拖下来到目标机用 rpm 或 dpkg 批量安装。这条路最快十来分钟能搞定前提是联网机上有对应版本的仓库。问题出在版本上。CentOS 7 官方源里的 Git 是 1.8.3.1这个版本有多老呢——不支持git worktree2.5 引入、不支持git switch/git restore2.23 引入很多现代 CI 工具链和构建脚本会直接报错退出。如果团队里有人在用新语法写脚本1.8 版本会让你在拉取代码这一步就卡住。所以在离线包里做选择时先确认清楚业务对 Git 版本有没有硬性下限别装完才发现不满足。2.3 便携二进制快但要接受几个妥协有些发行版会提供打包好的静态或半静态 Git 二进制解压到某个目录配一下 PATH 就能用。这条路在应急场景下非常香几分钟就能跑起来。但要接受两个妥协一是来源可信度无法自己验证生产环境要谨慎二是如果它是动态链接的目标机 glibc 版本低于打包机的版本运行时同样会报符号缺失跑不起来。提示如果你选择静态链接的 Git 版本要留意用 HTTPS 拉取时可能出现域名解析相关的告警。静态链接 glibc 对getaddrinfo这类依赖运行时加载的接口并不友好某些情况下会影响网络功能。生产环境优先选动态链接版本。三条路的对照关系我整理成了一张表选型时可以直接照着看对比项源码编译离线 RPM/DEB 包便携二进制版本可控性完全可控任意版本受仓库限制通常偏老取决于打包者依赖准备难度高需要 -devel 包中需要连依赖一起下低直接拷贝目标机是否需要 gcc需要不需要不需要典型耗时10 到 30 分钟10 分钟左右2 分钟对系统污染低装独立目录中进入包管理数据库几乎无卸载便利性手动清理rpm -e干净删目录推荐场景老系统、需要新版本同版本环境批量部署应急排障2.4 为什么不要直接覆盖 /usr/bin/git这是我见过最多的错误操作。目标机上如果已经有 Git 1.8有人图省事直接cp /usr/local/git/bin/git /usr/bin/git覆盖掉。短期内看起来没问题但系统的包管理数据库里记录的还是老版本的元数据rpm -V git校验会全部报异常更麻烦的是某些系统脚本或第三方插件会按老版本的行为调用 git覆盖之后行为发生静默变化排查起来非常痛苦。正确做法是把新版本装到/usr/local/git这样的独立前缀下通过 PATH 顺序或者 alternatives 机制让它优先生效系统的/usr/bin/git保持原样不动。想回退的时候把 PATH 一改就回去了干净利落。3. 在联网机上做一次「逆安装」把依赖完整打包确定走编译路线之后最核心的一步是在联网机上准备依赖包。核心思路是「逆安装」——不实际装到联网机只把包和它的依赖树下载下来。这一步做对了目标机上就是一马平川。3.1 RHEL 系的 yumdownloader 用法先用yum install -y yum-utils把工具装上然后执行下载。关键是--resolve参数它会把依赖树递归解析出来一起下载mkdir -p /tmp/git-offline/rpms yumdownloader --resolve --destdir/tmp/git-offline/rpms \ zlib-devel openssl-devel libcurl-devel expat-devel \ perl-ExtUtils-MakeMaker gettext autoconf--resolve有一个需要注意的行为它默认只会下载「当前系统没有安装」的依赖包。也就是说如果联网机上已经装了 zlib下载结果里可能就不包含 zlib 相关的依赖但这台联网机是全新的最小化安装目标机可能反而缺。稳妥做法是拿一台和 target 完全一致的最小化系统最好是同一个 ISO 装出来的新虚拟机来做下载源这样解析出来的依赖树最接近目标机的真实缺口。另一个更简洁的写法是用--downloadonlyyum install -y --downloadonly --downloaddir/tmp/git-offline/rpms \ zlib-devel openssl-devel libcurl-devel expat-devel gettext autoconf这种方式的好处是它走的是完整的依赖解析流程结果更贴近真实安装时的行为。下载完之后用rpm -qp --requires抽查一两个关键包确认依赖没有明显缺口。3.2 Debian 系的 apt 下载套路Debian 和 Ubuntu 上apt-get download只下指定的那一个包不解析依赖所以需要用--download-only配合缓存目录重定向mkdir -p /tmp/git-offline/debs apt-get install -y --download-only \ -o Dir::Cache::archives/tmp/git-offline/debs \ zlib1g-dev libssl-dev libcurl4-openssl-dev libexpat1-dev \ gettext autoconf装完之后包会落在你指定的缓存目录里。要注意--download-only会把缓存里其他历史包一并留在目录中收集前先清空目录比较干净。如果目标机是完全隔离、连 dpkg 的依赖数据库都可能不完整的极端环境可以再考虑 apt-offline 这类专门做离线包管理的工具用「在目标机生成签名请求、在联网机解析下载、再带回目标机安装」的流程。3.3 每个依赖包背后对应的是哪个功能理解依赖和功能的对应关系能帮你在编译失败时快速定位该补哪个包而不是盲目地把所有 -devel 都拉一遍依赖包对应功能缺失后的表现zlib-devel对象压缩与 pack 文件读写configure 报zlib.h找不到仓库体积暴涨openssl-develHTTPS 传输的加密层无法用 https 协议拉取只有 git 协议可用libcurl-develHTTP/HTTPS 协议实现configure 报cannot find -lcurl完全无法联网拉取expat-devel部分 HTTP 场景的 XML 解析老版本 Git 的 http 抓取可能编译不过gettext多语言提示信息编译时报msgfmt: command not foundautoconf从 Makefile 生成 configuremake configure直接失败perl-ExtUtils-MakeMakergit-svn、交互式 add 等脚本make 中途在 perl 相关目标上中断这里我个人的建议是如果目标机只是用来做常规的拉取、提交、推送perl 相关的功能完全可以不要直接用NO_PERL1关掉能省掉一大堆 perl 依赖。这个取舍在下一节会详细说。4. 目标机上的完整落地链路从解压到 PATH 生效依赖包和源码 tarball 都摆渡到目标机之后正式开工。这一段的每一步都有讲究尤其是 configure 参数的选择。4.1 依赖包安装与 rpm 冲突处理RHEL 系上把 rpms 目录整个拷过来进目录执行cd /tmp/git-offline/rpms rpm -ivh *.rpmrpm -ivh *.rpm会按 shell 展开的文件名顺序安装可能触发依赖顺序问题。更稳的做法是先用rpm -ivh --test *.rpm做一次演练看有没有冲突再真实安装。如果出现「已安装」的提示说明目标机上已经有这个包哪怕版本不同把-ivh换成-Uvh做升级安装即可。警告不要随手加--nodeps --force。这两个参数会绕过依赖检查和文件冲突检查看起来问题消失了实际上可能把系统的关键库换成了不兼容的版本导致其他程序集体崩溃。除非你完全清楚自己在做什么否则不要用。Debian 系上对应的是cd /tmp/git-offline/debs dpkg -i *.deb # 如果报依赖错误用下面的命令补齐离线情况下它只会在本地缓存里找 apt-get -f install --no-download4.2 configure 参数的取舍逻辑源码解压之后先进目录执行make configure这一步需要 autoconf再用./configure生成构建配置。参数不是越多越好每一个都要能说出理由tar -xf git-2.43.0.tar.xz cd git-2.43.0 make configure ./configure --prefix/usr/local/git \ --with-openssl \ --with-curl \ --with-expat--prefix/usr/local/git是刻意选择的不用默认的/usr/local是为了让所有 Git 相关文件集中在一个目录里将来要清理或者整体搬到另一台机器上直接打包这个目录就行不会和/usr/local/bin下的其他东西混在一起。--with-openssl、--with-curl、--with-expat这三个是显式打开 HTTPS 和 HTTP 支持。为什么一定要显式写因为如果 configure 阶段没找到对应的头文件它会静默降级——编译能过但装出来的 Git 只能用git://协议https://会直接报错说不支持。这个坑特别隐蔽因为编译过程风平浪静直到你真正去 clone 才暴露。所以 configure 结束之后一定要回头翻一遍它的输出确认这些特性是yes不是no。4.3 构建时的四个开关和内存陷阱编译阶段我会加上这几个开关来精简依赖make -j$(nproc) NO_GETTEXT1 NO_TCLTK1 NO_PYTHON1 NO_PERL1 make install NO_GETTEXT1 NO_TCLTK1 NO_PYTHON1 NO_PERL1NO_GETTEXT1跳过多语言提示的生成省掉 gettext 依赖NO_TCLTK1跳过图形化工具 gitk 和 git gui服务器上根本用不到NO_PYTHON1跳过 Python 相关脚本NO_PERL1跳过 perl 脚本代价是没有 git-svn 和git add -p的一部分交互能力较新版本的 add -p 已经用内置实现替代影响在缩小。关于-j$(nproc)这里有个真实的坑并行编译的每个进程大概会吃掉几百兆内存一台 2 核 2G 的虚拟机开-j2有可能在链接阶段被 OOM Killer 干掉表现为 make 突然以莫名其妙的错误码退出日志里只有一行Killed。经验值是并发数不要超过内存 GB 数内存紧张就老老实实-j1。4.4 让新版本 Git 真正生效装完之后/usr/local/git/bin/git已经存在了但直接敲git --version大概率还是老版本。原因是 PATH 里/usr/bin排在前面。有三种让它生效的方式我按推荐度排序第一种是写一个 profile 片段让所有用户都能用上cat /etc/profile.d/git.sh EOF export PATH/usr/local/git/bin:$PATH EOF chmod x /etc/profile.d/git.sh写完之后新开的 shell 会生效当前 shell 需要source /etc/profile.d/git.sh或者直接hash -r清一下命令缓存。第二种是用 alternatives 机制适合需要多版本共存的场景update-alternatives --install /usr/bin/git git /usr/local/git/bin/git 100第三种是只给个别用户配改~/.bashrc。生产机上我更推荐第一种因为很多自动化脚本是非交互式 shell 执行的它读的是/etc/profile.d而不是~/.bashrc只改个人配置会导致「我这边能跑定时任务跑不了」的诡异问题。5. 装完不等于能用离线环境特有的验证项版本的输出正确只是第一步。离线环境有几个特别的验证项必须在交付前跑一遍否则问题会在某个别人使用的时刻突然爆发。5.1 基础自检三连第一项是版本和执行路径git --version git --exec-pathgit --exec-path应该指向/usr/local/git/libexec/git-core如果它指向了老版本的目录说明 PATH 生效了但 exec-path 还是旧的通常是环境里残留了GIT_EXEC_PATH变量。第二项是模板目录。Git 在git init时会从模板目录拷贝 hooks、info 等初始文件模板目录缺失会导致新建仓库不完整ls /usr/local/git/share/git-core/templates mkdir -p /tmp/gittest cd /tmp/gittest git init git status第三项是手册页。如果安装时跳过了文档生成git help config会提示找不到手册。这不算致命问题但会影响团队协作体验。可以用MANPATH环境变量指向源码目录里已生成的手册或者接受这个缺失。5.2 HTTPS 证书链离线后最容易翻车的一环这是我踩过最多坑的地方。离线机器往往没有安装完整的 CA 证书包或者证书包版本很旧。表现是git clone https://...报SSL certificate problem: unable to get local issuer certificate。注意这不是网络问题网络是通的是证书链验证不过。处理方式是三选一。最正规的是把 CA 证书包也一起离线安装上去RHEL 系装ca-certificates装完执行update-ca-trustDebian 系装ca-certificates之后执行update-ca-certificates。第二种是从联网机拷贝现成的证书文件过去RHEL 系的目标路径是/etc/pki/tls/certs/ca-bundle.crtDebian 系是/etc/ssl/certs/ca-certificates.crt注意路径必须放对因为 libcurl 是按编译时的默认路径去读的。第三种是给 Git 单独指定证书文件适合没有 root 权限的场景git config --global http.sslCAInfo /home/user/certs/ca-bundle.crt注意git config --global http.sslVerify false能让报错立刻消失但这是关闭证书校验等于放弃了中间人攻击的防护内网环境也强烈不建议作为长期方案。用来临时定位问题可以定位完必须改回来。还有一个容易被忽略的细节如果内网代码仓库用的是自签名证书那不能靠导入公共 CA 解决需要把内网自己的根证书导入到系统的信任库或者用单独的http.sslCAInfo指向内网 CA。5.3 没有中央仓库时怎么在内网里搬代码代码拉下来之后接下来要解决的是内网怎么共享仓库。有三个不需要任何额外服务的方式都只依赖 Git 自身。第一种是文件协议。在一台机器上建裸仓库其他机器通过挂载的共享目录直接 clonegit clone --bare https://example.com/project.git project.git # 把 project.git 整个目录拷到内网共享位置 git clone /mnt/share/project.git my-project这种方式最简单缺点是共享目录的性能和权限管理取决于底层文件系统。第二种是用 Git 自带的守护进程。git daemon不依赖任何 Web 服务器一个命令就能把某个目录下的仓库以只读方式暴露出来git daemon --reuseaddr --base-path/srv/git --export-all --enablereceive-pack --verbose这样内网其他机器就能用git clone git://内网IP/project.git拉取。注意git://协议是明文传输仅限完全可信的内网使用。第三种是用系统自带的简易 HTTP 服务临时分发。如果目标机上恰好有 Python 3可以快速起一个静态文件服务来分发 tarball 和 rpm 包比 U 盘反复拷贝方便得多cd /tmp/git-offline python3 -m http.server 80005.4 系统时间偏差导致的迷惑性报错前面提到过检查date。如果离线机器的时钟比真实时间慢了几个月甚至几年访问 HTTPS 仓库时会出现SSL certificate problem: certificate is not yet valid或者certificate has expired。这类报错极具误导性你会以为是证书链的问题反复折腾证书文件其实只要把时间校准就没了。离线环境没法联外网的 NTP 服务器那就手动设置或者指向内网自建的授时服务date -s 2025-01-15 10:30:00 hwclock -w # 同步到硬件时钟避免重启后又飘回去这里有个额外提醒容器环境里的时间通常继承自宿主机如果在容器里改时间不会有任何效果得去改宿主机的。6. 编译中途失败的六种典型报错与处置源码编译路上会遇到一批高频报错这一节按出现频率排一下把原因和处置方式说清楚。这些报错本身不难解决难的是第一次见的时候不知道往哪个方向找。6.1 msgfmt: command not found这个报错出现在make阶段接在 gettext 相关的目标后面。原因很直接系统缺 gettext 工具无法编译多语言提示文件。两种处置方式一是把 gettext 也纳入离线依赖包二是直接用NO_GETTEXT1跳过。服务器上绝大多数人只看英文提示我一般直接跳过能少摆渡一个包就少一个。顺带说一句如果报错是libintl.h: No such file or directory那是缺 gettext 的开发头文件同样可以用NO_GETTEXT1绕过去。6.2 perl 版本过老导致脚本编译中断老系统上的 perl 往往是 5.10 甚至更早而新版 Git 的部分 perl 脚本用到了较新的语法特性。表现是 make 在某个.pm或者脚本目标上突然中断报一行 perl 语法错误。处置方式也是NO_PERL1代价是失去 git-svn 和部分交互脚本。如果确实需要 git-svn那就得想办法把较新的 perl 也离线装上去这是一条更长的链需要一起打包 perl 本身的依赖。我的判断标准是如果团队里没人用 SVN直接NO_PERL1别给自己找麻烦。6.3 zlib.h 与 curl 相关的头文件缺失这两类报错长得很像都是xxx.h: No such file or directory。区别在于zlib.h缺失说明zlib-devel没装上curl/curl.h缺失说明libcurl-devel没装上。有时候包明明装了但头文件路径不在默认搜索路径里典型是依赖装到了/usr/local下面这时候需要通过环境变量或者 configure 参数指定./configure --prefix/usr/local/git \ CPPFLAGS-I/usr/local/include \ LDFLAGS-L/usr/local/lib还有一个更隐蔽的情况目标机上同时存在多个版本的 opensslcurl 编译时链接的是 A 版本Git 链接的是 B 版本运行时报符号冲突。这种情况用curl-config --version和curl-config --libs确认清楚 curl 到底链的哪个 openssl再统一到同一个版本。6.4 configure 通过但链接阶段报 undefined reference典型输出是undefined reference to SSL_get1_peer_certificate或者类似的 SSL 函数名。原因是头文件版本和库文件版本不匹配——编译时用的是新头文件链接时找的是老库。处置方式是检查openssl-devel和openssl-libs的版本是否一致不一致就统一。如果是undefined reference to memcpyGLIBC_2.14这类就是前面说的 glibc 版本天花板问题解法只有一个降级你要编译的 Git 版本。6.5 装完了还是老版本这个报错不报错但最让人困惑。表现是git --version输出还是 1.8.3.1。排查顺序是这样的which -a git # 列出所有在 PATH 里的 git echo $PATH # 看 /usr/local/git/bin 在不在位置对不对 hash -r # 清掉 shell 的命令路径缓存 type git # 确认最终解析到哪个文件十有八九是三个原因之一PATH 没生效、shell 缓存了旧路径、或者/usr/local/git/bin排在了/usr/bin后面。用which -a一眼就能看出来。6.6 卸载与重装时的残留清理Git 的 Makefile 不是所有版本都提供uninstall目标所以清理要么靠make uninstall先确认支持要么靠安装时留下的记录。我的习惯是在make install之前先把输出重定向一份到文件make install NO_GETTEXT1 NO_TCLTK1 NO_PERL1 | tee /tmp/git-install.log将来要卸载把日志里install -m后面的目标路径提取出来批量删除就行。另一种更省事的做法是直接删掉整个/usr/local/git目录因为我们本来就是装在独立前缀下的删目录就干净了只要别忘了把/etc/profile.d/git.sh一起删掉。7. 我个人在这件事上攒下的几个习惯做了这么多次离线安装有几个习惯是踩过坑之后固化下来的分享出来供参考。第一条是永远准备两台联网机。一台用来下载依赖包另一台什么都不装专门用来验证依赖是否完整。方法很简单把这台干净的机器断网然后按目标机的流程走一遍能编过就说明包齐了。这比在目标机上反复试错省时间得多。第二条是把整个流程脚本化。我会写一个prepare.sh在联网机上跑产出物是一个 tar 包里面包含源码 tarball、依赖包目录、编译脚本、PATH 配置片段和一份 README。摆渡过去之后解压、跑编译脚本、跑配置脚本三步结束。等第二次要给另一台机器装的时候这个 tar 包直接复用成本几乎为零。第三条是版本选择留一手。如果目标机是 CentOS 7 这一代我不会一上来就挑最新的 Git而是选一个上一个稳定大版本成功率明显更高。等环境验证通过、有时间了再考虑升级。第四条是关于摆渡过程的校验。文件在 U 盘、跳板机、共享目录之间转了几道之后出现损坏的概率比想象中高。我在联网机和目标机两端都会跑一遍校验和源码包和依赖包目录都过一遍sha256sum git-2.43.0.tar.xz git-2.43.0.sha256 # 目标机上 sha256sum -c git-2.43.0.sha256这个动作花不了三十秒但能避免那种编译报了一个完全看不懂的格式错误的排查地狱。最后提一个小技巧如果目标机上有 Docker 或者类似的容器运行时很多时候根本不需要在宿主机上编译。找一台能联网的机器用和目标机相同基础镜像的容器里编译出成品再把整个/usr/local/git目录复制到目标机。glibc 版本一致的前提下这条路比在目标机上现场编译快得多也干净得多。前提是两侧基础镜像的 glibc 版本严格一致这一点必须提前用ldd --version核对。