企业官网建设流程全解析

作为一个常年跟代码打交道的开发者，我见过太多人在“装Git”这一步上栽跟头了。你说它难吧，双击安装包下一步下一步就能完事；你说它简单吧，装完一执行命令却提示找不到，或者提交代码时中文文件名乱码，再或者换行符导致整个文件被标记为修改。这篇文章就把Git安装这件事从头到尾讲透，包括不同系统的安装细节、安装后的必做配置，以及我这些年踩过的坑和排查思路。如果你正准备安装Git，不管是Windows、macOS还是Linux，看完这篇基本不会再有悬念。

1. 安装前的准备：先把Git是什么和版本选择搞明白

1.1 Git到底是什么，为什么几乎每个开发者都要装它

简单来说，Git是一个分布式版本控制系统，用来追踪你项目文件的变化。你可以把它理解成一个超级强大的“存档管理器”：每当你完成一个阶段的工作，就可以创建一个“存档点”（Git里叫提交/commit），以后任何时候都能回退到任意一个存档点，或者对比不同存档之间的差异。更实用的是，多个人可以在同一时间各自修改代码，最后再由负责人合并到一起，中间的冲突还可以逐行解决。

之所以强调“分布式”，是因为和早期那种集中式的版本控制工具不一样，Git在你本地就有一份完整的代码历史仓库，即使没有网络，你照样可以提交代码、查看历史、创建分支。等网络恢复或者需要协作时，再和远程仓库同步。这种设计让日常操作几乎不受网络限制，速度和灵活性都非常高。

所以装Git这件事，不仅仅是“装个软件”，而是为后续的所有代码管理、协作流程、自动化部署打地基。如果你只用过把代码打包压缩再互相传文件的方式协作，换成Git之后，你会明显感受到效率的提升，至少再也不用看到“final_v2_最终版_再也不改.zip”这种文件名了。

1.2 版本选择：不是越新越好，但要足够新

安装之前最容易被忽视的问题：到底装哪个版本？这里我给一个明确且务实的结论：装官方发布的最新稳定版，而不是随便用系统自带的旧版。

原因有这么几个。第一，Git本身迭代速度中等，但每个新版本都会修复旧版的安全漏洞和性能问题，像我遇到过的一些大仓库操作卡顿，就是升级到新版后明显改善的；第二，不同版本之间虽然命令基本兼容，但新特性往往只在较新版本里可用，比如更友好的冲突提示、更快的部分克隆（sparse checkout）、以及针对大文件的优化；第三，旧版本在某些新系统上可能存在编译或运行兼容问题。

那是不是要追求“最新版”里的最新呢？也不用。我个人的做法是：只要官方发布页上标注的稳定版，直接装就行，不追求RC候选版或每日构建版。这些尝鲜版可能存在未知问题，没必要在生产环境里当小白鼠。

还有一点要注意，Windows、macOS、Linux三大平台的安装方式完全不同，不要混用。Windows下最省心的是官方图形化安装包；macOS既可以用官方安装包，也可以通过包管理器安装；Linux则几乎全依赖发行版的软件源。下面这个表可以先帮你快速定位：

1.3 动手前先做“环境体检”：确认系统状态和旧版本

很多人拿到安装包直接双击，结果装到一半才发现系统里已经有一个老版本Git，导致冲突或者命令指向混乱。我建议在动手安装之前，先花一分钟做个体检：

• 确认当前系统版本。Windows下按Win+R输入winver查看；macOS点左上角苹果图标然后选“关于本机”；Linux执行cat /etc/os-release或uname -a查看内核和发行版信息。
• 检查是否已经安装Git。在终端（Windows下可以是PowerShell或CMD）里执行：

git --version

如果返回类似git version 2.39.0这样的信息，说明已经有Git了。这时候你要判断的是：这个版本是否满足需要，需不需要升级。如果提示git: command not found或'git' 不是内部或外部命令，则说明系统里没有Git，或者装了但没加入PATH环境变量（后面会专门讲这个问题）。

这里我特别提醒一句：不要因为系统里已经有Git就直接跳过安装步骤。很多系统（尤其是Linux）预装的Git版本比较旧，有些已经落后主版本好几个大版本，部分新命令或参数是不支持的。如果当前不是生产环境、没有正在进行的项目依赖，我建议还是清理后再装一个稳定版，省得之后为版本问题反复折腾。

2. 三大平台安装实操：Windows、macOS与Linux全流程

2.1 Windows系统：图形化安装全流程拆解

Windows上的Git安装，最标准、最不容易出错的方式是下载官方提供的exe安装包运行。下面我把安装过程的关键选项逐一拆开讲，解释每个选项背后的含义，因为这里恰恰是新手最迷茫的地方。

第一步是下载安装包。打开浏览器访问Git官方下载页面，选择Windows版本，一般会看到一个.exe的安装包文件，大概几十兆大小。这里注意选择符合你系统架构的版本：现在的电脑绝大多数是64位，选64-bit版本；如果确实还是32位老机器，就选32-bit版本。下载完成后双击运行，如果Windows弹出用户账户控制（UAC）提示，点击“是”允许安装。

进入安装向导后，前几步基本是许可协议和安装路径，直接默认即可。接下来出现的“Select Components”界面，我建议保持默认全选，尤其是“Git LFS”（大文件存储）和“Additional icons”这些选项，后续使用中会方便很多。

真正需要认真对待的是几个关键选项页，我来逐个说明：

“Select Start Menu Folder”：这步是选择开始菜单目录，保持默认就行，除非你有洁癖不想在开始菜单里出现太多条目。

“Select Default Editor”：这一步非常关键。Git在某些场景下需要打开文本编辑器让你输入提交信息，默认会使用vim。如果你对vim不熟（绝大多数人对vim都不熟），强烈建议在选项里选择你惯用的编辑器，比如VS Code。这样当你执行git commit时，弹出的编辑器就是你能熟练操作的那个，而不是一进去就卡在vim里不知道怎么保存退出。我当年第一次用Git就在vim里卡了好几分钟，最后直接用git commit -m "xxx"绕过编辑器，这个选项后来才改过来。

“Adjusting your PATH environment”：这步问的是要不要把Git添加到系统PATH环境变量中。请务必选择中间那个选项：“Recommended: Use Git from the command line and also from 3rd-party software”。这样你在CMD、PowerShell里就能直接使用git命令。千万不要选“只从Git Bash使用Git”，否则你在CMD里永远找不到git命令。选了Use Git and optional Unix tools from the Command Prompt也不是不行，它会引入一些Unix小工具，但可能会和系统自带命令冲突，不推荐。

“Choosing the SSH executable”：这里有两个选择，建议选“Use OpenSSH”选项（通常是默认推荐）。这是让Git使用OpenSSH作为加密通道，也是继续使用系统的SSH密钥体系。如果你之前用过其他SSH工具，可以选第二个选项，但大多数开发者不需要。

“Choosing HTTPS transport backend”：默认选择“Use the native Windows Secure Channel library”或“Use OpenSSL library”，这取决于安装包版本。一般来说默认即可，两者差别不大。但如果你在公司内网且使用自签名证书搭建了远程仓库，可能会需要额外配置证书信任，这个问题后面会提到。

“Line ending conversions”：这步是关于换行符处理的，极容易引发问题，我要专门讲一下。

Windows系统使用CRLF（回车+换行）作为文本换行符，而Linux/macOS使用LF（换行）。Git默认会在拉取代码时把LF转成CRLF，在提交代码时把CRLF转成LF，以此保证代码仓库里永远存的是LF，避免跨平台混乱。这个逻辑本身没问题，但如果配置不当，或者有些文件是二进制或者混合换行符，就会出现一提交就“整个文件都被修改”的诡异情况。

安装向导中这步一般有三个选项：

• Checkout Windows-style, commit Unix-style line endings：这是推荐选项，也是默认选项，适合绝大多数开发者。
• Checkout as-is, commit Unix-style line endings：适合需要精确保留换行符的高级用户。
• Checkout as-is, commit as-is：不推荐，很容易造成换行符混乱。

“Use a terminal emulator”：选择“Use MinTTY”还是“Use Windows console window”，默认的MinTTY体验更好一些，支持更多颜色和交互，我建议保持默认。

剩下的选项比如“Enable file system caching”、“Enable symbolic link support”等，默认即可，不需要改动。

安装完成后，打开CMD或PowerShell，执行git --version，如果能正常输出版本号，说明安装成功。

这里有一个我踩过的坑：有次安装时我为了省空间，在“Select Components”界面取消了“Git LFS”选项，结果之后遇到一个存储大资源文件的仓库，拉取时出现了奇怪的文件占位符，查了很久才发现是没装LFS组件。所以还是那句话：安装时保持默认全选，尽量不要因为一时觉得“用不上”就去掉核心组件。

2.2 macOS系统：两种主流安装方式对比

macOS下的Git安装，常见方式有两种：官方安装包方式和包管理器方式。你要问我推荐哪种，我可以根据实际体验给你细致对比。

方式一：官方安装包方式

访问Git官方下载页面，选择macOS对应的dmg安装包，下载后双击打开，然后像安装普通软件一样，点击安装器根据提示完成安装。这种方式的好处是安装过程直观，无需依赖任何包管理器；坏处是后续升级不方便，每次都要重新下载安装包覆盖安装，而且首次运行需要去系统设置里处理“隐私与安全性”中的“已验证的开发者”弹窗。如果你安装的是App Store之外下载的软件，macOS默认会拦截，你需要右键点击应用图标选择“打开”，或者在“系统设置 -> 隐私与安全性”里点击“仍要打开”。

官方安装包装的Git，默认会被安装到/usr/local/git目录，然后在/usr/bin下生成一个符号链接。这也意味着你执行git --version时看到的不一定是刚装的版本，因为系统自带的旧版Git可能会排在前面。要解决这个问题，可以检查一下echo $PATH的输出顺序，或者直接重新打开一个终端窗口再试。

方式二：通过Homebrew安装

Homebrew是macOS上非常流行的包管理器，如果你日常用macOS做开发，我强烈建议你直接使用Homebrew，因为后续升级Git只需一条命令，极其省心。安装Homebrew本身其实也很简单：

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

当然，这个脚本是否顺利执行依赖网络环境。装好Homebrew后，先更新索引，再安装Git：

brew update brew install git

安装完成后，你可以执行which git看一下，如果显示路径包含/usr/local/bin/git或/opt/homebrew/bin/git，说明Homebrew版Git生效了。由于Homebrew的安装目录在PATH中通常排在系统目录之前，所以git --version显示的就是新版。如果还是看到系统自带旧版，可以执行brew link --overwrite git来修正，或者在~/.zshrc中调整PATH顺序。

我个人在macOS上更倾向于Homebrew方式，原因有三：一是升级方便，brew upgrade git一条命令搞定；二是不用处理系统安全验证弹窗；三是Homebrew会帮你处理好依赖关系，不会出现莫名奇妙的链接问题。不过如果你是偶尔在macOS上用到Git，不想引入额外的包管理器，那使用官方安装包也完全没问题，两种方式都是官方支持的，没有谁比谁更“正宗”。

另外一个细节：如果你的Mac是Apple Silicon（M1/M2/M3芯片），Homebrew的默认安装路径是/opt/homebrew；如果是Intel芯片，则是/usr/local。这个差异会体现在PATH路径中，遇到命令找不到的情况，先确认一下当前Homebrew安装路径是否在PATH里。

2.3 Linux系统：用包管理器快速安装与更新

Linux发行版众多，但安装Git的思路大同小异：通过系统自带的包管理器安装。我按常见的发行版分类来写。

Debian / Ubuntu 系（apt）

如果你使用的是Ubuntu、Debian、Linux Mint这类发行版，打开终端，执行：

sudo apt update sudo apt install git -y

apt update先更新软件源索引，apt install git安装Git。安装完成后同样执行git --version验证。

这里有个隐藏问题：apt源里的Git版本通常比官方最新稳定版旧得多。比如Ubuntu的长期支持版本（LTS）为了稳定，往往会锁定软件包版本，可能你装到的Git是两年前甚至更旧的版本。如果你的项目不需要新特性，那问题不大；但如果你需要较新功能或修复，可以考虑从源码编译安装（后面我会专门讲），或者先检查当前源里是否有更新版本。

RHEL / CentOS / Fedora 系（dnf / yum）

在CentOS Stream、RHEL、Fedora这些系统上，使用：

sudo dnf install git -y

老版本的CentOS 7等系统可能只有yum，那么就是：

sudo yum install git -y

dnf是yum的新一代包管理器，在较新的系统上命令已经统一为dnf，但两者用法几乎一样。

Arch / Manjaro 系（pacman）

Arch系发行版用：

sudo pacman -S git

Arch系的软件包通常非常新，基本跟官方同步，所以版本方面不用担心。

openSUSE（zypper）

sudo zypper install git

Linux下还有一个细节：装完之后，你可能想确认Git是从哪个路径加载的，执行which git。如果显示/usr/bin/git或/bin/git，就说明安装正确。

如果你是Linux新手，我不建议贸然从源码编译安装Git，除非你清楚自己在做什么。因为通过包管理器安装的版本虽然旧一点，但和系统的库文件兼容性最好，升级维护也都由发行版负责，不容易出问题。等你有了一定经验，再考虑编译安装的玩法也不迟。

2.4 从源码编译安装Git：什么时候才需要这么做

从源码编译安装Git，算是进阶操作，百分之九十的开发者日常用不到。但有几种场景，你可能确实需要这么干：

• 你的发行版软件源里的Git版本太旧，而项目又明确需要新版特性；
• 你需要自定义安装目录，比如装到自己的主目录下，不想动系统级目录；
• 你在没有root权限的服务器上，想使用一个较新的Git；
• 你想开启某些特殊编译选项，比如自定义路径、调整依赖。

步骤大致是这样的（以Debian/Ubuntu系为例，其他系统大同小异）：

先安装编译所需的依赖包：

sudo apt update sudo apt install make gcc libssl-dev libcurl4-gnutls-dev libexpat1-dev gettext zlib1g-dev -y

然后去Git官方仓库获取最新稳定版的源码包，下载并解压（我这里用通用占位符描述，实际下载时请从Git官方发布页面获取最新版本号）：

wget https://www.kernel.org/pub/software/scm/git/git-2.39.0.tar.gz tar -xzf git-2.39.0.tar.gz cd git-2.39.0

接着依次执行：

make prefix=/usr/local all sudo make prefix=/usr/local install

这里的prefix指定安装根目录，默认是/usr/local。如果你没有root权限，可以改成自己主目录下的路径，比如make prefix=$HOME/local all，但那样的话，你需要把$HOME/local/bin加入到PATH环境变量中，否则终端里找不到新Git命令。

编译安装其实不难，但有两个体验问题必须说：第一，编译过程可能要几分钟，不像包管理器几秒搞定；第二，后续升级时你得重复整个下载编译流程，比较繁琐。所以我的建议是：能用包管理器就用包管理器，真的需要编译安装时再折腾。编译安装大多是为了“新”和“自定义”，不是为了“体验安装过程”。

还有一点：编译安装前务必确认依赖齐全，否则会在中途报错。最常见的报错是缺少libcurl库或ssl开发头文件，按上面我给的依赖清单装一遍基本能避开。

3. 安装完成后的第一轮配置：不配置等于白装

很多人安装完Git后得意地敲一下git --version，然后就觉得自己搞定了。但真正要用好Git，还得做几个关键配置。这一步不夸张地说，能决定你未来用Git的心情好坏。

3.1 验证安装状态：不止是版本号

首先，打开终端，执行：

git --version

确认能返回版本号。如果提示找不到命令，说明安装路径没有加入PATH，或者安装过程有问题。这时可以执行where git（Windows）或which git（macOS/Linux）来定位Git安装位置。正常情况下，这会返回Git可执行文件的完整路径。

进一步验证安装完整性，可以执行：

git --help

如果系统弹出一份详细的命令行帮助文档，说明Git的核心功能正常。你还可以用git config --list查看目前的配置信息，不过这一步在新装环境下多半是空白的，正常。

还有一个容易被忽略的验证点：在Git Bash（Windows）或终端中执行git lfs version。如果你在安装时勾选了Git LFS，这个命令应该会输出版本号。如果没有输出，说明LFS组件没装好，可以考虑重新安装一次并勾选该组件。

3.2 配置用户名和邮箱：为什么这步如此重要

Git提交代码时，每一次提交都会记录作者信息。这个信息从哪里来？就是靠下面的配置指令。如果不配置，提交时会报错，或者用系统默认的机器名去提交，最终代码历史里的作者信息乱得没法看，协作时会非常痛苦。

打开终端，执行：

git config --global user.name "你的名字" git config --global user.email "你的邮箱"

这里通常填你注册远程仓库平台时使用的邮箱和用户名，这样你的提交能正确关联到你的账户。--global选项代表“全局配置”，意思是这台机器上的所有Git仓库默认都用这套身份信息。如果你某个项目想用不同的身份，可以在那个项目目录下执行不带--global的相同命令，单独覆盖。

这个配置背后还有一个原理：Git将配置信息保存在用户主目录下的.gitconfig文件中。比如Windows下路径一般是C:\Users\你的用户名\.gitconfig，macOS/Linux下是~/.gitconfig。你可以直接打开这个文件手动修改，也可以用命令修改。

有一点让我印象很深：有一次给一个新项目做代码审查，发现历史提交里有一位同事的名字是“whatever”，邮箱是乱敲的。一问才知道，他当初跳过配置直接提交，结果在工具里映射不到人，代码审查时备注都不知道发给谁。所以，这两个命令虽然简单，但真的别跳。

验证配置是否成功：

git config --global --list

输出的内容里就能看到你刚才配置的user.name和user.email。

3.3 配置SSH密钥：免密连接远程仓库的核心操作

现在绝大多数代码托管平台都支持HTTPS和SSH两种协议。HTTPS方式在推拉代码时，可能会让你反复输入账号密码；SSH方式只要配置好密钥，之后的操作全程免密，体验顺滑得多。因此我强烈建议你在装好Git之后，顺手把SSH密钥配置了。

生成密钥的命令是：

ssh-keygen -t ed25519 -C "你的邮箱"

执行后，系统会提示你选择保存路径和设置密码短语（passphrase）。如果你想一路回车用默认设置也完全可以，密钥默认保存在~/.ssh/id_ed25519（或id_rsa）。关于密码短语，我建议设置一个，虽然每次使用SSH时会要求你输入，但考虑到以后涉及到密钥泄漏时那一层保护带来的安全感，这点麻烦是值得的。当然，如果你追求极致的免密体验，也可以留空，看个人取舍。

生成完成后，第二件事是查看公钥内容：

cat ~/.ssh/id_ed25519.pub

把输出的那一长串文本复制下来，然后登录你的代码托管平台，在个人设置里找到“SSH Keys”或“SSH公钥”入口，粘贴进去保存即可。

配置完公钥后，你可以执行一条测试命令来确认是否成功（以通用方式描述，具体域名以你实际使用的平台为准）：

ssh -T git@your-platform-host

如果返回类似“成功认证”的提示，说明SSH密钥配置成功。这一步是整个免密流程中最后的关键验证。

为什么我强烈推荐SSH？真实体验是：HTTPS方式下，如果你不定期输入密码，很容易被凭证助手缓存的问题困扰，或者在公司有防火墙、代理的环境下被反复要求验证身份；而SSH的密钥机制，一次配置，长期有效，换机器时只要把私钥复制过去或者重新生成一套，就能无缝衔接。

不过这里有几个SaaS平台可能不一样，有的平台默认推荐HTTPS并提供了个人访问令牌（Personal Access Token）的方式，在凭证助手缓存后也不怎么需要输密码。但如果你希望不走额外注册平台的流程、最省心地获得零成本体验，SSH依然是更通用的方案。

3.4 让换行符与中文文件名不再捣乱：三个建议配置

安装完Git，还有两个细节配置对Windows用户尤其重要：换行符和中文文件名显示。

第一个是换行符。前面提到Windows用CRLF，Linux/macOS用LF。为了让仓库里的文件统一使用LF，你可以在安装向导中正确选择换行符转换选项，也可以在安装后再用命令确认：

git config --global core.autocrlf true

这条命令在Windows上非常常见：true表示拉取代码时自动把LF转为CRLF，提交时自动把CRLF转为LF。如果你在macOS或Linux上开发，则建议执行：

git config --global core.autocrlf input

表示提交时自动转LF，但检出时不做转换，保持仓库和本机都使用LF。

第二个是中文文件名显示。Git默认在显示中文文件名时可能会打印成类似\346\265\213\350\257\225.txt这样的八进制转义序列，看着像乱码。要解决这个问题，执行：

git config --global core.quotepath false

设置后，git status和git log里就可以直接看到中文文件名了。

第三个是默认编辑器。前面在安装向导中提到的默认编辑器选择，如果你当时没调整，也可以在命令行中改（这里用VS Code的code命令为例，你需要确认编辑器支持命令行调用）：

git config --global core.editor "code --wait"

设置后，执行git commit没有带-m参数时，会打开VS Code窗口让你填写提交信息，关闭窗口后Git就会完成提交，这个体验很顺滑。

这几个配置我建议在安装完Git后马上做，因为后期遇到问题时，你往往会怀疑是代码问题、工具问题，最后排查一圈才发现是配置问题。

4. 常见安装问题与排查技巧实录

无论安装流程写得多详细，实际执行时还是会冒出各种奇奇怪怪的情况。这里把我这些年遇到的高频问题整理成速查表，再展开讲讲每一步的排查思路。这些经验是我实际踩出来的，绝对不是纸上谈兵。

4.1 Windows下提示“git 不是内部或外部命令”

这是Windows用户最常见的报错。出现这个问题的原因，几乎可以锁定为：Git的可执行文件路径没有加入PATH环境变量。

排查思路是：先在文件资源管理器中找到Git的实际安装路径，比如C:\Program Files\Git\cmd。如果这个目录存在，那问题就是PATH没配对。

解决方法是手动添加PATH。具体操作：右键“此电脑”或“我的电脑”，选择“属性”，进入“高级系统设置”，点击“环境变量”。在“系统变量”列表里找到Path，双击编辑，在末尾追加Git的cmd目录路径，保存后重开一个CMD或PowerShell窗口（重点是重开，因为旧窗口的环境变量还是旧的），再执行git --version验证。

这里有一个高频误区：有些人安装时在“Adjusting your PATH environment”界面选了“Use Git from Git Bash only”，这就导致在CMD里找不到git命令，而在Git Bash里却正常。这种情况你只需要在Git Bash里检查git --version是否正常即可，如果正常就没必要改PATH。

4.2 Windows下安装向导报错或安装到一半卡住

这类问题多半和权限或杀毒软件有关。安装Git时请确认你是用管理员账户操作，并且安装路径不是被系统保护得太严格的目录（如C盘根目录有时候会有权限问题）。如果安装到一半莫名回滚，可以尝试暂时关闭安全软件再安装，装好之后再重新开启。另外，Windows的用户账户控制（UAC）如果拦截，也要选择“是”。

如果安装程序一直卡在“Extracting”阶段，多半是磁盘或缓存的问题，清理一下临时文件（执行%temp%目录里的内容），再重新运行安装包。

4.3 macOS提示“无法打开git，因为无法验证开发者身份”

这种问题只出现在从官方网站下载dmg安装包安装的情况下，而且常见于Apple Silicon或较新的macOS版本。因为macOS默认只允许运行从App Store下载或经过官方认证的应用。

解决办法有两种。第一种：右键点击应用图标，选择“打开”，系统会弹出一个额外的确认对话框，点击“打开”即可。第二种：进入“系统设置 -> 隐私与安全性”，下拉找到被拦截的条目，点击“仍要打开”。这个操作只需要一次，之后Git就能正常启动。

如果你使用的是Homebrew方式安装，则不会有这个弹窗，因为Homebrew安装的软件没有经过公证，且会直接复制到自己的目录中，macOS对命令行工具的拦截相对宽松一些。

4.4 Linux下apt安装后版本太旧，想要新版

这个问题在Ubuntu LTS版本上尤其明显。比如Ubuntu 20.04 LTS自带的Git版本可能是2.25.x，而官方稳定版已经到2.4x了。如果你执着于新版，我建议两条路：

• sudo apt upgrade git：先看看能不能从当前软件源升级（虽然大概率版本不变）；
• 从源码编译安装：参考前面2.4节的内容，源码编译能拿到官方最新版，但之后需要自己负责升级。

我遇到过一位同事，在Ubuntu服务器上用的还是Git 1.8，很多脚本里的新参数全都不支持，最后只能逐步排查哪些命令不可用。所以如果项目对Git版本有硬性要求，尽量在装系统的那一刻就用较新的发行版，或者在服务器上做好版本升级规划，别拖到后面。

4.5 升级或卸载Git的正确姿势

谈到升级，好多人做的操作就是去官网下载最新安装包覆盖安装。这在Windows和macOS官方安装包方式下确实可行，但需要注意：覆盖安装一般不会改掉你已有的全局配置文件（比如用户名、邮箱、换行符设置），这点很让人放心。不过偶尔也会遇到配置被重置的情况，所以升级后建议跑一下git config --list检查一下配置是否还在。

如果用Homebrew安装的Git，升级就是brew upgrade git；如果用Linux包管理器，升级就是sudo apt upgrade git或sudo dnf update git。总之，尽量用包管理器升级，省心。

卸载方面，Windows用户去“设置 -> 应用”里找到“Git”并卸载即可；macOS官方安装包需要在“访达 -> 应用程序”里把Git相关的目录删掉（或者重新运行dmg里的uninstall脚本）；Homebrew方式卸载是brew uninstall git；Linux则是sudo apt remove git或sudo dnf remove git。

卸载前请确认你不需要保留任何Git仓库里的未提交更改。因为卸载Git本身不会删除你的仓库目录，但会让你暂时失去版本控制工具，所以建议先在别的机器上确认仓库状态没问题。

4.6 安装问题排查速查表：实用且直接的引导

这张表可以当做一个临时的急救指南，遇到问题时优先对着查一遍，大多数安装配置问题都是这几类。

我个人的经验是，安装Git这件事，用20分钟认真做完，后面能省下的是大量排查的纠结。尤其是PATH、换行符、SSH密钥这三件事，一定要在安装后的第一时间解决，不要拖到开始提交代码再处理。作为一个经历过在vim里卡住、被中文字符乱码折磨、因为PATH没配好在终端里找不到git命令的人，我真心建议你别跳过这些步骤。如果你在安装过程中碰到了上面没写到的情况，先回忆一下安装向导里的选项你都选了啥，再检查一下终端里的报错原文，大部分问题都能顺藤摸瓜解决。后续再想进阶，还可以研究一下Git的别名配置、提交模板、以及各种钩子脚本，安装只是起点，真正的生产力在后面。