1. 锁定 2.41.0什么场景值得这么干什么场景纯属折腾先把结论放在最前面。Git 2.41.0 安装教程这类内容之所以一直有人搜核心原因并不是这个版本有什么石破天惊的新能力而是版本统一这件事在真实项目里的权重远比大多数人想象的高。我带过的几个外包交付项目甲方内网镜像里只放了一个版本的 Git 安装包开发机、构建机、运维跳板机全都要对齐谁多装了个新版git fsck出来的 pack 结构差异、钩子脚本的行为差异都会在联调那天集中爆发。所以先分清楚你属于哪一类人。第一类是交付型团队代码最终要跑在别人的机器上构建流水线的镜像已经固化了工具链版本这时候你装 2.41.0 不是为了尝鲜是为了两边行为一致。这类情况下版本号本身就是需求的一部分。第二类是教学与培训场景课程讲义、实验手册里写的路径、菜单文案、命令输出全部基于某个确定版本。学生装了最新版菜单位置一变第 5 步勾选 XXX就对不上了答疑成本直接翻倍。第三类是个人开发者跟着最新版走这类人其实完全没必要专门装 2.41.0直接拿当前稳定版就行。Git 的向后兼容做得相当克制老仓库在新版本上几乎不会出问题。我个人的判断标准很土但很好用只要你的机器上有任何一台是别人给的、你不能随便动的就锁版本全都是你自己的就跟着新版本走。这条规则帮我省掉了至少十几次无意义的排查。另外要澄清一个常见的误解Git 的版本号不是越大功能越多的线性关系。Git 长期保持着大致每两三个月一个功能版本的节奏小版本号里塞的东西经常是性能调优、边界修复、以及给大型仓库做的底层改造。你从 2.30 跳到 2.41.0日常敲的命令基本感觉不到区别真正能感觉到差异的是超大仓库的status速度、部分克隆和稀疏检出这类偏工程化的能力。所以不要指望装完就变快它的价值更多体现在稳定和一致上。2. 拿到正确的安装包三个平台的下载路径与哈希校验下载这一环最容易出问题而且出问题的方式很隐蔽你装上了命令也能跑但某个模块缺失直到半年后要用git lfs才发现压根没装。2.1 各平台该拿哪个文件官方发布页会同时挂出源码包和各平台安装包命名规则相对固定认准这几类后缀就不会拿错平台典型文件名形态说明Windows形如Git-x.x.x-64-bit.exe64 位图形化安装向导绝大多数人用这个Windows 便携版形如PortableGit-x.x.x-64-bit.7z.exe免安装解压即用适合不能写注册表的机器Windows 精简版形如MinGit-x.x.x-64-bit.zip给第三方程序内嵌 Git 用没有 Bash 环境macOS形如git-x.x.x-intel-universal-mavericks.dmg官方图形安装包源码形如git-2.41.0.tar.xz或.tar.gz编译用.xz体积更小校验文件各类.sha256/.sha512务必一起下载Fetch 版本通常还带一个-rc0之类的后缀那是候选版本别拿来做正式环境。2.2 为什么必须做哈希校验我知道很多人看到校验哈希四个字就直接跳过。但下载安装包这件事有三个现实风险传输中断导致的截断文件、缓存节点返回的旧文件、以及某些公司内网网关对可执行文件的二次包装。这三种情况的表现都是能装、能用、偶尔诡异。校验命令本身很简单Windows 上用 PowerShellGet-FileHash .\Git-2.41.0-64-bit.exe -Algorithm SHA256macOS 和 Linux 上shasum -a 256 git-2.41.0.tar.xz # 或 sha256sum git-2.41.0.tar.xz把输出和官方的.sha256文件内容比对一个字符都不能差。注意哈希比对是大小写不敏感的但长度必须一致如果长度都不一样说明你下的是另一个文件。提示比对时建议直接把哈希值复制到文本编辑器里逐段核对。我曾经因为肉眼把c和e看混白折腾了四十分钟重下一次。2.3 下载慢怎么办体积大的源码包在跨区域传输时确实会慢。可行的做法是找可信的开源软件镜像站取包比如各高校和云厂商维护的公共镜像。但这里有个原则哈希值一定要以官方发布页为准镜像站只用来加速传输不用来替代校验。镜像同步有延迟也可能同步到错误的文件校验这一关不能省。如果实在下不动还可以直接下便携版或者用包管理器这条路后面会讲。3. Windows 安装向导 15 屏逐屏拆解Windows 上的 Git 安装向导是这套流程里信息密度最高的部分十来个界面里有将近三十个选项而且每个选项下面都有一小段说明文字绝大多数人的做法是一路 Next。我把每一屏拆开讲重点说清楚为什么这么选。3.1 目标目录与组件勾选哪些必须留目标目录这一步没什么争议默认C:\Program Files\Git就好。唯一要注意的是路径里不要出现中文和空格某些构建脚本在处理带空格的路径时不会加引号这是经典的踩坑点。组件选择这一屏才是重头戏逐项说明Additional icons - On the Desktop / Windows Explorer integration资源管理器右键菜单里的Git Bash Here和Git GUI Here非常实用强烈建议保留。不想污染右键菜单的可以取消但不建议。Windows Explorer integration 的 Open Git Bash here这是我最常用的入口定位到某个目录右键直接开 Bash比先开终端再cd快得多。Git LFS如果你不确定要不要留着。它在安装包里几乎不占空间但等你某天要拉一个用了大文件存储的仓库时缺了它就只能重新跑一遍安装程序。Associate .gitconfiguration files with the default text editor*会在安装时把.gitconfig、.gitattributes这类文件关联到默认编辑器对新手挺友好。Associate .sh files to be run with Bash把.sh文件关联到 Git Bash 执行。这一项要谨慎它会改变系统对.sh的默认打开方式如果你机器上还有 WSL 或者别的 Shell 环境可能会互相抢。我个人倾向取消。Use a TrueType font in all console windows让所有控制台窗口使用 TrueType 字体解决某些老系统下中文显示成方块的问题建议保留。Check daily for Git for Windows updates每天检查更新。建议取消。理由和前面锁版本是一个逻辑——你既然专门装了 2.41.0就不要让它在某个安静的下午自己变成别的版本。Add a Git Bash Profile to Windows Terminal如果你用 Windows Terminal勾上会多一个一键开 Git Bash 的配置项很舒服。Scalar微软那套为大仓库做优化的工具集会作为scalar命令提供。它本身不占什么资源但普通人一年也用不到一次。勾不勾都行我一般留着反正不碍事。3.2 默认编辑器与初始分支名默认编辑器这一屏向导会给出 Nano、Vim、Notepad、Visual Studio Code、Notepad、WordPad 等选项还有 Custom。这里的关键认知是Git 会在需要你写提交信息、处理合并冲突、编辑 rebase 计划时调用这个编辑器。所以标准只有一个——你顺手就行。完全不熟命令行的选 Notepad 或者已经装好的 VS Code最不容易卡住。老手选 Vim 或者 NanoNano 在界面底部直接标了快捷键学习成本最低。选 Custom 的要注意写完整路径而且路径带空格时必须加引号否则 Git 会找不到程序。初始分支名这一屏是 Git 2.28 之后才有的给了你master、main和自定义三个选项本质是往init.defaultBranch里写值。这一步建议不看习惯看协作方你的远程仓库默认分支叫什么本地就跟着叫什么。本地master远程main第一次push之后就得手动改上游分支多出来的这一步没有任何意义。3.3 PATH 三个选项为什么我永远选中间那个这一屏是整套流程里最重要的选择没有之一。第一项Use Git from Git Bash only不写 PATH只能从 Git Bash 里用。如果你的机器上要跑任何脚本、任何 IDE 集成这一项都会让你后悔。第二项Git from the command line and also from 3rd-party software把 Git 的可执行文件路径加进系统 PATH同时把 Bash 相关工具留在 Git 自己的目录里。这是官方推荐项也是我永远的选择。第三项Use Git and optional Unix tools from the Command Prompt会把 Git 自带的 Unix 工具比如find.exe、sort.exe、sort相关的一批也塞进 PATH。听起来很方便但这意味着系统的find会被 Git 的版本覆盖某些依赖系统原生find的老脚本会直接报错。我见过至少三起装完 Git 之后某个 Java 构建工具就挂了的案例最后定位下来都是手快选了第三项。中间那一项能覆盖 99% 的需求没必要冒险。3.4 SSH 与 HTTPS 后端两屏联动SSH 这一屏是二选一用 Git 自带的 OpenSSH还是用系统上已有的外部 OpenSSH。判断逻辑很简单。如果你机器上有 Windows 自带的 OpenSSHWindows 10 1809 之后基本都有并且你在C:\Users\你的用户名\.ssh\下已经存了密钥选外部的能直接复用如果是全新环境、什么都没有选自带的最省事。怕麻烦就选自带的你所有配置都会落在 Git 自己的目录里孤立性好卸载也干净。HTTPS 传输后端这一屏选项是 OpenSSL 库和 Windows 原生安全通道库。OpenSSL跨平台行为一致和 Linux/macOS 上的表现对齐证书链的处理方式你也熟悉。Windows 原生安全通道能直接复用系统证书存储里的企业根证书在装了内部 CA 的公司网络里非常省事。这一屏的取舍取决于你的网络环境有没有自建的证书体系。没有的话选 OpenSSL有的话选原生安全通道能帮你省掉大量证书报错的排查时间。3.5 换行符、终端模拟器与 pull 行为换行符这一屏三个选项是 Git 在 Windows 上最容易出问题的地方必须讲清楚原委。Windows 的文本换行是CRLF回车换行Linux 和 macOS 上是LF。Git 如果不管这件事你从 Linux 仓库拉下来的文件在 Windows 上会被记事本显示成一大坨反过来你提交的文件在构建机上又会带上多余的\r导致某些脚本报bad interpreter之类的错。三个选项Checkout Windows-style, commit Unix-style对应core.autocrlftrue检出时把换行转成CRLF提交时转回LF。仓库里存的始终是LF本地编辑器看到的是 Windows 风格。这是 Windows 单机开发的推荐项。Checkout as-is, commit Unix-style对应core.autocrlfinput检出不动提交转LF。适合你在 Windows 上主要编辑的是 Shell 脚本或者 Dockerfile 这类对换行敏感的文件。Checkout as-is, commit as-is对应core.autocrlffalse完全不管。只有在团队已经用.gitattributes统一管理了换行、或者仓库里确实存在必须保留CRLF的文件时才选它。我的建议是第一项然后立刻在项目根目录加一个.gitattributes做更细粒度的控制这个后面配置章节会讲。终端模拟器这一屏MinTTY 和 Windows 默认控制台二选一。MinTTY 支持窗口自由缩放、支持更多终端特性但它是自己实现的终端和某些依赖原生控制台的交互式程序比如某些需要读取控制台句柄的工具会打架。Windows 默认控制台兼容性更好但体验差。默认选 MinTTY遇到具体程序不兼容再单独处理。git pull默认行为这一屏同样三个选项默认合并、变基、仅快进。这里不展开讲原理只说结论——保持默认。理由是你一旦在这里改了全局默认以后接手别人项目时git pull的实际行为会和对方的预期不一致冲突处理方式也会不一样。真要变基敲命令时显式加参数就够了别改默认值。3.6 凭据管理器与最后那几项凭据管理器这一屏选项是 Git Credential Manager 和 None。一定要选 Git Credential Manager。它的作用是把你的仓库账号凭据存进系统的凭据存储里第一次输入之后就不用再输了。不装的话每次push都要重新敲一遍账号如果你开了两步验证还得每次生成一次临时凭据那个体验能让人当场放弃命令行。而且这个组件在 Windows 上还能处理浏览器授权流程配合主流代码托管平台都挺顺畅。它本身是独立维护的开源组件卸载 Git 时不会自动清掉这个后面卸载章节会提。最后一屏是几个额外选项Enable file system caching启用文件系统缓存对大仓库的status、add提速明显。建议保留。代价是极小概率下文件状态读取会有短暂延迟实践中基本感知不到。Enable symbolic links启用符号链接支持。这一项需要管理员权限而且 Windows 上创建符号链接本身就要特殊权限建议先不勾等确实需要时再回来打开避免安装时弹权限提示。Enable experimental support for pseudo consoles实验性的伪控制台支持主要是让 Git Bash 里能正常跑一些需要交互输入的 Windows 原生程序比如 Python 的交互式解释器、Node 的 REPL。勾上实用性很高出问题的概率很低。点完 Install 就是等待解压和写注册表几十秒的事。4. Linux包管理器与源码编译两条路怎么选Linux 上装 Git 有两个思路选错了会浪费大量时间。4.1 发行版自带版本够不够用Debian/Ubuntu 系和 RHEL/CentOS 系都有现成的包# Debian / Ubuntu sudo apt update sudo apt install git # RHEL / CentOS / Fedora sudo yum install git # 或 sudo dnf install git问题在于发行版仓库里的 Git 版本通常落后官方好几个身位尤其是那些以稳定为卖点的长期支持发行版。如果你只是要个能用的 Git装完就完事如果你必须精确到 2.41.0包管理器这条路基本走不通。想查当前能装到哪个版本apt-cache policy git # 或 yum info git输出里会直接列出候选版本号一目了然。如果候选版本不是你要的又不想编译还有第三条路用第三方维护的新版软件源。这条路能用但要接受这个源由谁维护、会不会哪天停止更新的风险生产机器上我一般不用。4.2 从源码编译的完整链路要精确锁 2.41.0源码编译是唯一可靠的方式。整个流程分四步。第一步装编译依赖。Git 的核心依赖不多但缺一个都会导致功能缺失# Debian / Ubuntu sudo apt install -y build-essential libssl-dev libcurl4-openssl-dev \ libexpat1-dev gettext zlib1g-dev libz-dev libpcre2-dev # RHEL / CentOS sudo yum install -y gcc make curl-devel expat-devel gettext-devel \ openssl-devel zlib-devel perl-devel这里面几个关键项的作用值得说清楚libcurl是 HTTPS 传输的基础缺了它git clone https://...直接不可用expat负责解析 XML 格式的仓库元数据gettext提供多语言支持缺了它 Git 的输出全是原始英文标识符openssl负责 TLS 握手。第二步解压并配置。tar -xf git-2.41.0.tar.xz cd git-2.41.0 ./configure --prefix/usr/local --with-openssl --with-curl --with-expat--prefix/usr/local把 Git 装到独立目录不会和系统自带的抢位置出问题也好回退。如果你希望编译出来的文档也能用可以加--with-doc但要额外装asciidoc之类的工具编译时间会显著变长服务器上通常不需要。第三步编译并安装。make -j$(nproc) sudo make install-j$(nproc)让 make 用满所有 CPU 核心比单线程快好几倍。这台机器如果是虚拟机且只分了一两个核那就老老实实等着源码编译十几分钟很正常。第四步处理路径冲突。这一步最容易被忽略。系统里原本可能有一个/usr/bin/git新装的是/usr/local/bin/git两者谁生效取决于PATH的先后顺序。which -a git git --versionwhich -a会列出所有匹配到的 Git如果顺序不对就调整PATH或者直接给编译出来的版本做软链。我强烈建议先which -a看清楚再动手盲目创建软链会把系统工具链搞乱。提示源码编译的 Git 不会自动获得补全脚本。需要手动把contrib/completion/git-completion.bash复制到 shell 的补全目录否则你敲git ch按 Tab 什么都不会发生。5. macOS 上的三种装法对比macOS 有个特殊之处系统自带一个 Git但那个版本通常很老而且是被 Xcode 命令行工具借用的身份存在的。所以第一步是先看看现状git --version xcode-select -p如果git --version能输出但版本号很老说明系统那套在生效。三种装法各有适用面。Homebrew 装法是最主流的brew install git它会装到 Homebrew 自己的前缀目录下Intel 机器是/usr/localApple Silicon 是/opt/homebrew然后靠PATH顺序覆盖系统版本。装完之后which git应该指向 Homebrew 的路径如果还指向/usr/bin/git就去检查 shell 配置文件里的PATH顺序。要注意 Homebrew 默认装的是当前最新版不保证给你 2.41.0需要锁版本得去翻它的版本历史比较折腾。官方图形安装包是唯一能精确指定版本的方式。下载对应.dmg双击挂载运行里面的安装脚本。它会装到/usr/local/git并把链接放到/usr/local/bin重启终端后PATH里如果有/usr/local/bin就会生效。Xcode 命令行工具这条路是xcode-select --install装的是系统配套的版本版本号完全不受你控制只适合我只要有个 Git 能用的场景。我自己的做法是主力用 Homebrew 的需要精确版本时用官方安装包并且从不删系统自带的那个。系统自带的 Git 是很多底层工具的依赖动了它可能引发一堆莫名其妙的报错收益远小于风险。6. 装完之后必须先做的几项初始配置安装程序跑完不等于能干活。下面这几项配置缺了任何一项都会在你开工之后某一天突然咬你一口。6.1 身份标识与换行符第一件事是告诉 Git 你是谁git config --global user.name 你的名字 git config --global user.email 你的邮箱这两个值会写进每一个提交记录而且是永久留在历史里的。邮箱填错你会在一堆提交上看到错误的署名改起来要重写历史非常麻烦。命令行里区分全局和仓库级靠--global参数不加就是只对当前仓库生效这个区别要记牢。邮箱建议和你托管平台的账号邮箱保持一致否则提交记录不会和你的账号头像、贡献图关联起来。这算是使用体验上的小事但强迫症会很难受。换行符的处理前面安装向导里选过全局默认值但更靠谱的方式是在每个项目根目录放一个.gitattributes* textauto *.sh text eollf *.bat text eolcrlf *.png binary *.jpg binary *.zip binary这几行的含义是默认由 Git 自动判断文本文件并统一为LFShell 脚本强制LF避免在 Linux 上执行时报解释器错误批处理文件强制CRLF图片和压缩包明确标记为二进制禁止任何换行转换。二进制文件被误判为文本是极其严重的问题转换过程会损坏文件内容而且损坏是静默的。6.2 让中文不再乱码Windows 上装完 Gitgit status里中文文件名显示成一堆\344\275\240这样的八进制转义字符是非常经典的场景。原因是 Git 默认不把非 ASCII 字节序列当作文本对待。解法是三条命令git config --global core.quotepath false git config --global i18n.commitEncoding utf-8 git config --global i18n.logOutputEncoding utf-8第一条关掉路径的转义输出中文文件名就能正常显示后两条分别指定提交信息和日志输出的编码方式。这三条我建议所有中文环境都加上加上之后终端里看着舒服太多。如果提交信息里的中文在别人的机器上是乱码还要检查对方的终端编码而不是急着改 Git 配置——Windows 老版本控制台的默认代码页不是 UTF-8改终端的代码页或者换 Windows Terminal 才是正解。6.3 别名与长路径Git 的子命令名有些挺长可以定义别名省事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 --decorate --all其中lg这个别名最值得配一行命令就能看到带分支图提交历史的紧凑视图比默认的log输出直观得多。Windows 上还有一个必须配的git config --global core.longpaths trueWindows 的路径长度历史默认上限是 260 个字符。某些项目尤其是前端项目的node_modules嵌套目录路径长度轻松超过这个限制症状是clone到一半报文件名或扩展名太长。开启长路径支持能解决这个问题但它需要系统层面也开启对应策略只在 Git 里配可能不生效。另外还有一个容易被忽略的git config --global core.ignorecase truemacOS 和 Windows 的文件系统默认大小写不敏感Linux 敏感。这个配置让 Git 在大小写不敏感的系统上少做一些无谓的误判。唯一要小心的是如果你把Readme.md改名成README.md在大小写不敏感的系统上 Git 可能认为你什么都没改这时候要用git mv两步走先改成临时名再改回目标名。6.4 凭据保存与全局忽略文件凭据保存Windows 上安装时选了 Git Credential Manager 就已经配好了Linux 和 macOS 需要手动配# macOS用系统钥匙串 git config --global credential.helper osxkeychain # Linux用缓存方式默认缓存 15 分钟 git config --global credential.helper cache # 改成缓存一小时 git config --global credential.helper cache --timeout3600 # 想要长期保存可以用文件方式存储 git config --global credential.helper store最后那个store会把凭据明文写在用户目录下的.git-credentials文件里。个人机器上问题不大共享机器、跳板机、CI 环境上绝对不要用这一点没有商量余地。还有一个我强烈推荐配的全局忽略文件git config --global core.excludesfile ~/.gitignore_global然后在这个文件里写上各种机器相关的垃圾文件比如编辑器产生的临时目录、系统生成的元数据文件、编译产物缓存等。这样你就不必在每个项目里都重复添加一遍也不会因为手一滑把.DS_Store或者Thumbs.db提交进去。7. 验证安装是否真的成功装完了和装对了是两回事。下面这几条命令建议逐条跑一遍任何一条不符合预期都要回头查。git --version which -a git git config --list --show-origin git config --global --list第一条输出必须精确是git version 2.41.0注意后面可能跟着.windows.1之类的发行方后缀那是正常的。第二条列出所有生效的 Git 路径确认排在最前面的就是你要的那个。第三条会显示每个配置项的来源文件排查某个配置到底从哪来的时候极其有用这是我用得最多的一条排错命令。第四条只列全局配置确认你刚才写的那些值都进去了。再补几条功能性验证# 测试本地仓库能否正常初始化 mkdir /tmp/git-test cd /tmp/git-test git init echo hello a.txt git add a.txt git commit -m test git log --oneline这一套跑通说明核心功能、提交签名、日志输出都正常。如果commit报错说不知道你是谁说明前面身份配置那一步漏了。再测一下网络相关的能力用ls-remote这类只读命令比直接clone轻量得多git ls-remote https://github.com/git/git.git HEAD能输出一串哈希值说明 HTTPS 传输后端、证书链、DNS 全都是好的。这条命令是判断网络问题还是 Git 问题的分水岭我排错时第一步就是跑它。如果 SSH 方式也要用再测一条ssh -T gitgithub.com看到欢迎语就说明密钥配置没问题。注意这个命令返回的退出码可能是非零的那不代表失败看输出内容判断。8. 排查手册我踩过的那些坑前面都是应该怎么做这一节讲做错了会怎样。这些都是我在真实环境里遇到过的每一条都花过时间。8.1 git 不是内部或外部命令这是最高频的一个。装完了命令行敲git说找不到。排查顺序是固定的先开一个全新的终端窗口再试。安装程序修改的是系统环境变量已经打开的终端进程用的是它启动时的那份快照不会自动刷新。这一条能解决一半以上的装完不能用。新窗口还是不行就检查 PATH。Windows 上在终端里敲$env:Path -split ;看看里面有没有C:\Program Files\Git\cmd这一条。没有的话说明安装时 PATH 选的是第一项需要手动加或者重跑一次安装程序选第二项。有的话再确认这个目录下的git.exe是不是真的存在——有时候是因为装到了别的位置配置里写的却是默认路径。Linux 上类似用echo $PATH看/usr/local/bin是否在列表里且排在/usr/bin前面。8.2 中文乱码的三种不同表现中文乱码要分情况症状不同根因也不同。表现一文件名显示成八进制转义。比如\346\226\207\344\273\266.txt。这是core.quotepath的问题前面 6.2 节的三条命令能解决。表现二终端里中文能显示但日志里是乱码。这是终端编码和 Git 输出编码不匹配。检查i18n.logOutputEncoding再检查终端的代码页设置。表现三提交信息在别人机器上乱码。这是对方终端的问题不是你的问题。但如果对方用同样的终端看英文提交信息正常那就得怀疑提交时写进去的编码不对检查i18n.commitEncoding。这三种情况我都遇到过关键是不要一看到乱码就无脑复制三行配置先看清楚是文件名乱码还是内容乱码是本地显示问题还是提交记录问题。8.3 大仓库克隆到一半失败现象是clone或fetch跑到 80% 左右卡住然后报传输错误或者超时。大仓库常见。可调的参数有几个git config --global http.postBuffer 524288000 git config --global http.lowSpeedLimit 0 git config --global http.lowSpeedTime 999999第一条把 HTTP 传输缓冲区调大单位是字节这里大约是 500MB。默认值在某些网络条件下会导致大数据量推送失败报RPC failed; HTTP 413之类的错。后两条关掉低速连接的中断判断避免网络抖动导致长时间传输被掐断。要注意的是postBuffer调大只是缓解真正的大仓库更应该用浅克隆git clone --depth 1 仓库地址只拉取最近一次提交速度提升是数量级的。代价是丢失完整历史需要的时候可以用git fetch --unshallow补齐。浅克隆是应对超大仓库的第一选择改缓冲区配置是第二选择很多人顺序搞反了先去调参数折腾半天。另外如果clone反复失败在同一位置先怀疑本地磁盘空间和路径长度而不是网络。我遇到过一次是目标目录所在分区只剩几百兆Git 跑到一半写不下去报的错误信息却完全是网络相关的很有误导性。8.4 图形客户端与命令行版本打架TortoiseGit、SourceTree、以及各家 IDE 内置的 Git 集成都会用到 Git 命令行的某一部分。常见问题有两个。问题一客户端用的是它自带的 Git不是你装的那个。TortoiseGit 有独立的设置项指定 Git 可执行文件的路径默认可能指向它自己打包的版本。如果你专门装了 2.41.0一定要去客户端设置里把路径指过去否则你以为在用 2.41.0实际用的是别的版本行为差异排查起来非常费劲。问题二IDE 报Git 版本过低。某些 IDE 的新版本会要求 Git 达到某个最低版本才启用某些功能。2.41.0 在主流 IDE 上不存在这个问题但如果你装 2.41.0 是因为某个老项目的构建脚本要求而你的 IDE 又比较新可能会出现 IDE 抱怨配置项缺失的情况。这时候的做法不是升级 Git而是在 IDE 设置里关掉对应的实验性集成。判断到底用的是哪个版本最可靠的方式是在 IDE 的终端里敲git --version因为 IDE 内置终端继承的环境变量和它自己调用的环境可能不是同一个。8.5 卸载重装时的残留清理Git 装坏了要重装这一步比想象中麻烦因为安装目录之外还有好几处残留。Windows 上需要检查的位置安装目录本身默认C:\Program Files\Git、C:\Program Files\Git LFS、用户目录下的.gitconfig和.git-credentials、系统环境变量 PATH 里手动加过的条目、以及 Git Credential Manager 这个独立组件。最后这个不会跟着 Git 一起卸载要单独在应用和功能里找。Linux 上源码编译装的卸载就是sudo make uninstall但如果你之前改过PATH或者做过软链那些要手动清掉。包管理器装的用对应的 remove 命令。用户目录下的.gitconfig我个人建议保留。它只包含你的身份信息和偏好设置重装之后直接复用没有任何副作用。删掉反而要重新配一遍。注意如果你在.git-credentials里存过明文凭据卸载前记得手动删掉这个文件不要让它留在磁盘上。8.6 一个关于分支名的小麻烦最后这个坑不算报错但很烦人。安装时如果初始分支名选了main而你拉下来的老仓库默认分支是master第一次push会提示上游分支不存在git push -u origin master加-u参数把上游关联起来就行。如果本地分支名和远程不一致还要先改名git branch -m master main改完之后远程分支还叫原来的名字需要重新推送并调整仓库的默认分支设置。这套操作本身不难但如果团队里有十几台机器各自装成不同的默认值每次新人进来都要解释一遍那才是真的麻烦。所以还是那句话装的时候看一眼协作方的默认分支叫什么一次选对永远省事。我个人在实际操作中的体会是Git 的安装过程本身十分钟就能搞定真正花时间的是装完之后那几项配置以及遇到问题时判断到底是 Git 的问题还是环境的问题。前面反复强调的那条命令git ls-remote以及那条git config --list --show-origin把这两个用熟能帮你把绝大多数看起来玄学的问题缩小到一个很具体的范围里。至于版本号装 2.41.0 也好装更新的也好只要团队内部统一、并且你清楚自己为什么选它就没问题。