人人都经历过那个阶段：项目文件夹里塞满了项目最终版.zip、项目最终版2.zip、项目最终版_再也不改.zip。我是从这种"文件备份大法"里逃出来的人，后来真正让我把版本管理这件事想明白的工具，就是 Git。这篇博文不讲虚的，就围绕"下载和安装 Git"这件事，把从零到能用的完整路径走一遍，顺便把安装过程中那些默认选项背后的含义、装完之后的必要配置、以及连接 IDEA、远程仓库、分支合并这些高频操作一并解决掉。适合刚接触代码管理的新手，也适合装过几次但始终没搞懂安装选项的人。
1. 为什么要用 Git：版本管理是最值得先搞懂的事
1.1 "文件备份大法"的痛，对比一下就有答案
你肯定遇到过这种情况：写了几天的代码，改来改去，最后发现还是三天前的版本能跑。如果是靠文件复制备份，你能找到三天前的版本吗？能，但代价是满屏的v1、v2、final、final2，而且你根本记不清每个版本之间改了什么。Git 解决的就是这个问题：它把你每一次有意义的修改记录成一个"提交"（commit），像游戏存档一样，任何时候都能回到任意一个存档点，还能看到每个存档之间到底动了哪些文件、哪些行。
多人协作的场景里，Git 的价值更明显。传统方式是一个人改完打包发给另一个人，合并时全靠手工比对。Git 给每个人一个完整的本地仓库，大家各自提交，最后由一个人把所有人的修改合并起来。现在几乎所有互联网公司都把 Git 作为代码管理的底座，GitHub、Gitee、GitLab 这些托管平台都是在 Git 之上做的二次封装。你下载安装的 Git，是那个真正干活的本地引擎。
1.2 下载之前，先把这3个概念分清
第一次接触这个概念的人容易把三样东西搞混：Git、GitHub、Git GUI。
Git 是核心，是 Linus Torvalds 开发的那个分布式版本控制系统，本质是一堆在命令行里运行的命令。你下载安装的就是它。GitHub 和 Gitee 是远程托管平台，你把本地仓库的代码推送到这些平台上保存、协作，它们不是 Git 本身，而是"寄存代码的中转站"。Git GUI 指的是图形界面工具，比如 GitKraken、TortoiseGit，它们包装了 Git 命令，让你用鼠标操作，但底层调用的还是你安装的这个 Git。
我见过有人用了半年 GitHub Desktop 和 IDEA 的图形界面，却压根没在命令行敲过git commit，遇到图形工具覆盖不到的场景就完全懵了。所以我的建议是：装完 Git 先老老实实把命令行基本命令跑熟，再回去用图形界面，你会发现很多之前看不懂的操作一下就通了。
1.3 如何选择适合自己的 Git 版本
进入官网 git-scm.com，首页会自动识别当前操作系统，点击下载按钮就好。需要注意两点：系统位数和版本类型。Windows 下安装包通常有 32 位（x86）和 64 位（x64）之分，现在的电脑基本都是 64 位，但如果你用的是老机器，先右键"此电脑"查看属性确认一下。
版本类型方面，官网提供的都是稳定版，你可能会看到类似2.47.1这种版本号，数字越大代表功能越新。对绝大多数人来说，直接下载最新的稳定版即可，没必要追历史版本，新版本修复了旧版本的已知 bug，安全性也更好。另外，如果你用的是 Linux，系统自带的软件源里通常也有 Git，但版本可能偏旧，后面我会讲怎么处理。
提示：下载时认准 git-scm.com 官方域名，不要从第三方下载站下载。那种"高速下载器"安装完之后，桌面多出一堆全家桶软件的教训，我一哥们已经用亲身经历帮大家测过了。
2. Windows 安装完整教程：每一步选项都给你说透
2.1 从哪里下载：官方渠道的下载方法
打开 git-scm.com，页面上会显示最新的版本信息，点Download for Windows按钮就能拿到 64 位安装包。如果你需要其他版本，点 Download 页面里的Windows链接，能看到多个安装包选项：
64-bit Git for Windows Setup：常规安装包，推荐绝大多数人用。64-bit Git for Windows Portable：便携版，适合放在 U 盘里，安装时不写入系统注册表。32-bit Git for Windows Setup：老机器专用。
下载速度如果不太理想，可以用国内高校的开源软件镜像站，比如清华大学的 tuna 镜像源、中科大的软件源，里面都会同步 Git for Windows 的安装包。这类镜像站的更新会有一定的延迟，但用于安装完全没问题。不建议用任何"下载加速器"或第三方下载站，源码被替换的风险完全不值得冒。
2.2 安装向导里那些选项到底怎么选
双击安装包进入向导后，一路点 Next 也可以，但有几个选项我强烈建议你搞清楚，因为它们直接影响后面的使用体验。
选择组件（Select Components）这一步，默认勾选的项目里有两项尤其重要：Git Bash Here和Git GUI Here。这两项会在你的右键菜单里加上"Git Bash"和"Git GUI"入口。Git Bash 是一个运行在 Windows 上的模拟终端环境，里面用的是类 Linux 的命令语法，很多教程里的命令都是基于 Bash 的，所以我建议保留这两个勾选。Add a Git Bash Profile to Windows Terminal如果勾上，能在 Windows Terminal 里直接打开 Git Bash，有这习惯的人可以留着。
默认编辑器（Choosing the default editor）这一步，默认是 Vim。如果你没用过 Vim，第一次在 Git 里需要写提交说明时，会被卡在"怎么退出 Vim"这个千古难题上（答案是按 Esc 后输入:wq回车）。我建议直接在这里选成你熟悉的编辑器，比如 Visual Studio Code 或者 Notepad++，选完之后 Git 用到的编辑器就会是你选的那个，写提交信息时体验友好得多。
调整 PATH 环境变量（Adjusting your PATH）这一步有三个选项：
Use Git from Git Bash only：只有 Git Bash 里能用 git 命令，CMD 和 PowerShell 里不行。Git from the command line and also from 3rd-party software：推荐，把 Git 加入系统 PATH，你在任意终端都能执行 git 命令。Use Git and optional Unix tools from the Command Prompt：不推荐，它会把大量 Unix 命令覆盖到 Windows 系统命令里，容易引起混乱。
绝大多数教程都会让你用第二种，因为开发时命令行操作文件、脚本调用都是常态，只把 Git 塞进 Bash 里会到处碰壁。
HTTPS 传输后端（Choosing the HTTPS transport backend），默认选Use the OpenSSL library。直接保持默认就好。它负责你用 HTTPS 方式克隆远程仓库时，如何验证服务器的 SSL 证书。OpenSSL 这个选项对 GitHub、Gitee 等主流的平台的证书验证都没问题。
**行结束符转换（Configuring the line ending conversions）**这一步，是新手最容易踩坑的地方。Windows 系统换行用的是回车加换行（CRLF），Linux 和 macOS 用的是换行（LF）。如果 Git 不做任何处理，同一个文件在不同系统间就会产生大量"整个文件都被修改"的假象。默认选项是Checkout Windows-style, commit Unix-style line endings，意思是检出代码到本地时转成 Windows 的 CRLF，提交时转回 LF。多人协作时如果队友大多用 Windows，选默认就好；如果你的项目需要在 Linux 服务器上跑日常脚本，也可以选第二个选项（按文件原有格式不做转换）。我的建议是新手先选默认，等你在不同系统间来回切时踩了坑，再回过头来理解这个选项也不迟。
终端模拟器（Choosing the terminal emulator），默认选Use MinTTY。MinTTY 比 Windows 默认的 Console 窗口表现好，支持更好的字体、颜色和快捷键，而且和 Git Bash 的配合更流畅。这里保持默认即可。
其他几个选项，比如Default Git branch name（默认分支名），新版本会建议你用main，老版本习惯用master，两者没有本质区别，保持默认即可。git pull 的行为、凭据管理器这两项保持默认就好，凭据管理器（Git Credential Manager）留着是必要的，不然每次 HTTPS 拉取远程仓库都会让你输账号密码。
2.3 装完怎么验证：三条命令确认安装成功
安装完成后，在任意文件夹空白处右键，选择Git Bash Here，在弹出的终端里依次输入以下命令：
git --version git config --global user.name git config --global user.email第一条命令会输出你安装的 Git 版本号，比如git version 2.47.1.windows.1，能看到就说明安装成功。第二、三条命令是用来检查全局配置的，如果相对卡在空输出，别急，第三步我会专门讲配置。
既然走到了命令行，顺手把 Windows 上的右键菜单熟悉一下，你会发现Git Bash Here这个入口的使用频率远远高于桌面图标，它能让你在任意文件夹直接打开终端，省去来回 cd 目录的麻烦。
3. macOS 和 Linux 安装：一份差异对比清单
3.1 macOS 两条安装路线：包管理器 vs 安装包
macOS 装 Git 有两个主流路径。第一是下载官网提供的安装包，安装后 Git 会被放在/usr/local/git下，优点是图形化、官方维护，缺点是后续想升级 Git 版本时还得重新去官网下载。第二是通过 Homebrew 安装，命令只有一行：
brew install gitHomebrew 装完的 Git 在/usr/local/opt/git，升级时执行brew upgrade git就好，日常维护更省心。我个人推荐用 Homebrew，一个原因是它是 macOS 开发者装机必装的东西，既然早晚要装，不如统一用它管；另一个原因是它能自动处理 Git 的依赖，比如 OpenSSL 等动态库，省掉各种编译冲突的麻烦。
macOS 还隐藏着一个"系统自带 Git"的问题。就算你没装过，某些 Xcode 相关操作会触发系统装一个老旧版本的 Git，git --version可能显示git version 2.39.x。我的建议是：如果只是单纯用 Git 做版本控制，系统自带版本也够用，但如果安装过程中报错或者版本过旧，还是用 Homebrew 替换一下比较干净。
3.2 Linux 各发行版的安装命令
Linux 不同发行版用的软件包管理器不一样，命令也不同。Debian/Ubuntu 系：
sudo apt update sudo apt install gitCentOS/RHEL/Red Hat 系：
sudo yum install gitFedora 用 dnf：
sudo dnf install git装完之后同样用git --version验证。需要注意，软件源里的 Git 版本可能偏旧，比如某些 CentOS 默认源里带的还是 2.x 的早期版本。如果项目对 Git 版本有要求，或者你想用更新的功能，有两个办法：一是配置发行版的软件源补充仓库，二是在官网下载源码编译安装。源码编译是个体力活，依赖多、耗时长，不是特殊需求我不推荐。记住：能用包管理器解决的别手动编译，系统级的东西让包管理器管会更省心。
Linux 下还有一个细节：如果你的系统里同时存在多个 Git 版本，执行which git看看当前使用的是哪个路径，如果指向了系统自带版本，要注意修改 PATH 优先级。
3.3 无论哪个平台，装完先做的三项基础配置
Git 安装完成后，第一件事不是跑代码，而是做身份配置。在终端执行：
git config --global user.name "你的名字" git config --global user.email "你的邮箱"这两条配置写入的是~/.gitconfig文件。为什么重要？因为 Git 每次提交时都会把这两项信息写进提交记录里，别人在代码仓库里看到的提交人就是你设置的名字和邮箱。如果不配置，Git 在提交时可能会提示Please tell me who you are，并把提交卡住。
第三个配置是我个人强烈建议每个新人都做一下的：
git config --global init.defaultBranch main这一条把仓库默认分支名设为main，避免新版本 Git 初始化仓库时出现master和其他人main不一致的混淆。另外，Windows 用户如果遇到中文乱码问题，还可以加一条：
git config --global core.quotepath false这条配置的作用我后面在问题排查里会专门讲。配置完成后，用git config --list可以查看当前所有配置项，确认刚才的设置已经生效。
4. 从下载完成到第一次提交：4步跑通完整流程
4.1 本地仓库初始化：init、add、commit 一条龙
安装和基础配置做完，接下来是实操环节。选择一个项目目录，打开终端进入该目录，执行：
git init这条命令会在当前目录生成一个隐藏的.git文件夹，这个文件夹就是仓库的"数据库"。之后你对这个目录做的所有版本记录，都保存在这里。随便写一个文件，然后执行：
git add . git commit -m "第一次提交"git add .是把当前目录所有改动加入暂存区，git commit才是真正生成一个存档点。这两条命令的组合频率会贯穿你整个 Git 使用生涯。提交完成后，用git log --oneline能看到刚才生成的提交记录。
这里有一个容易绕晕的概念：暂存区。你可以把它理解成一个"候选席"，你决定哪些改动进入本次提交，就先git add把它们请进候选席，再git commit一次性定稿。这样同一个文件的不同部分，也可以分多次提交，非常灵活。
4.2 配好 SSH 密钥：免密连接远程仓库的关键
本地仓库建立后，下一步是把它和远程仓库对接。这里强烈建议你配置 SSH 密钥，而不是每次都用 HTTPS 输账号密码。SSH 方式的好处是：配置一次之后，push 和 pull 都不需要输入用户名密码，而且加密传输更安全。
生成密钥的命令如下：
ssh-keygen -t ed25519 -C "你的邮箱"一路回车，默认保存在~/.ssh/id_ed25519.pub。然后查看公钥内容：
cat ~/.ssh/id_ed25519.pub把输出的整段内容复制下来，登录你的代码托管平台（GitHub、Gitee，或者公司内部的 GitLab），在设置里找到 SSH Keys 入口，把公钥粘贴进去保存。GitHub 的入口是Settings -> SSH and GPG keys，Gitee 的入口是头像 -> 设置 -> SSH 公钥。
配置完成后用ssh -T git@github.com测试连通性，如果返回欢迎信息就代表配置成功。如果你所在团队的代码托管在 Gitee 这类国内平台，操作方式完全一样，只是地址换成git@gitee.com:用户名/仓库名.git。
提示：
id_ed25519.pub是公钥，可以放心给别人看；对应的id_ed25519是私钥，绝不能泄露，也不能把它提交到代码仓库里，否则就意味着拿到你私钥的人可以以你的身份往仓库里推代码。
4.3 在 IDEA 里拉取 Git 项目：新版 Toolbox 的操作路径
很多 Java 和前后端开发者习惯在 IntelliJ IDEA 里直接操作 Git。这里有个高频操作：从远程仓库拉取（clone）项目。
IDEA 启动后，在主界面点击Get from VCS，或者菜单栏File -> New -> Project from Version Control，在弹出的对话框里粘贴远程仓库 URL。URL 有两种格式：SSH 格式git@github.com:用户名/仓库名.git和 HTTPS 格式https://github.com/用户名/仓库名.git。
如果使用的 SSH URL，IDEA 会读取你本机~/.ssh下的密钥文件，前提是 IDEA 能定位到 Git 可执行文件。你可以打开File -> Settings -> Version Control -> Git，在Path to Git executable里确认 Git 安装路径是否正确。Windows 下通常会在C:\Program Files\Git\bin\git.exe。如果这里显示红色报警，说明 IDEA 没找到 Git，你需要手动指定路径。
拉取成功后，代码会自动下载到本地并打开项目。之后在 IDEA 右下角可以看到当前分支信息，直接在这里切换分支、同步代码、提交推送都很直观。IDEA 里的分支操作本质上调用的还是 Git 命令，你在 IDEA 里右键项目选择Git -> Repository -> Branches，就能看到所有远程和本地分支。
4.4 分支合并：最常用也最该谨慎的操作
分支是 Git 最强大的特性之一。你可以开一个分支修 bug，不影响主分支上的正常工作，改完再合并回去。基本命令：
git branch dev # 创建 dev 分支 git checkout dev # 切换到 dev 分支 git add . && git commit -m "开发中的修改" git checkout main # 切回主分支 git merge dev # 把 dev 合并进 main分支合并时最让人紧张的是冲突。当两个分支修改了同一个文件的同一行代码时，Git 不知道应该保留哪个版本，就会停下来让你手动解决。冲突文件里会出现类似这样的标记：
<<<<<<< HEAD 当前分支的内容 ======= 被合并分支的内容 >>>>>>> dev你需要手动把这几个标记清理掉，保留真正需要的内容，然后重新git add和git commit。解决冲突不是技术难事，难的是判断哪个版本更合理——这需要对业务改动足够了解。我的经验是：合并前先看一眼两个分支各自改了哪些文件，用git log --oneline --graph梳理分支走向，能提前预判可能的冲突点，真冲突了也能更快定位。
5. 常见问题排查实录：下载、安装、配置的坑我都踩过
5.1 安装包下载慢或卡住怎么办
Windows 下最常遇到的就是官网下载安装包速度慢或是下到一半中断。这种情况我建议你换两样东西：一是换下载源，国内高校镜像站同步了 Git for Windows 的安装包，下载速度通常很可观；二是换浏览器或下工具，有些浏览器的下载管理容易在大文件中断线，换个下载工具或者直接用系统自带下载都能绕开。
但有一种情况需要注意：如果下载页面能打开，下载进度却始终为零，多半是网络链路的问题，这时候请勿尝试任何非官方手段，直接用国内镜像站就好，操作路径和官方下载没区别。装完之后，如果git clone访问远程仓库时卡住、报超时，排查思路也一样：先确认网络能连通目标平台，再考虑是不是地址写错了。
5.2 "git 不是内部或外部命令"的排查思路
Windows 用户在 CMD 或 PowerShell 里执行git时报不是内部或外部命令，几乎都是 PATH 环境变量没配好。检查路径：打开系统属性 -> 环境变量 -> Path，确认有没有下面这几项：
C:\Program Files\Git\cmd C:\Program Files\Git\bin如果安装时选了"Use Git from Git Bash only"，Git 就不会加入系统 PATH，就会出现这个现象。两种解决办法：一是改环境变量把以上路径加进去（需要重启终端才能生效）；二是在 Git Bash 里执行 git 命令，绕过系统终端。
还有一种容易被忽略的情况：你明明装了 Git，但在某个终端里执行却报命令不存在。这通常是终端会话的环境变量没有刷新，重启终端，或者新开一个窗口再试。
5.3 中文乱码问题：两处配置解决
中文乱码分两种。一种是在 Git Bash 里git status看到中文文件名显示成类似\346\265\213\350\257\225的转义字符，这不是 Git 把文件搞坏了，只是默认把非 ASCII 字符转义了。执行：
git config --global core.quotepath false就能让中文文件名正常显示。另一种是终端里输出的中文变成菱形问号，这通常是终端编码和 Git 不一致造成的。Git Bash 窗口标题栏右键打开Options -> Text，把字符集设为 UTF-8，基本就能解决。如果提交信息里的中文在git log里乱码，检查一下提交时终端是否用的是 UTF-8 编码，Windows 默认的 GBK 编码会导致提交到仓库里的中文本身就错乱。
5.4 换行符差异导致的"假冲突"
这是跨平台开发必踩的坑。两个同事，一个用 Windows，一个用 macOS，没有统一换行符策略，合代码时就会出现"我什么都没改，但整个文件都是冲突"的诡异现象。同一份文件的每一行，在 Windows 下是 CRLF，在 Unix 下是 LF，Git 对每一行都做对比，自然判定每一行都变了。
避免这种假冲突，从源头就要统一换行符策略。Windows 安装器里的行结束符选项保持默认（checkout CRLF、commit LF）是一个方案；也可以让团队里在项目根目录加一个.gitattributes文件，直接声明所有文本文件的换行符规则：
* text=auto *.sh text eol=lf如果你的某个旧项目已经因为换行符差异产生了大量"假冲突"，可以通过以下命令批量规范化一遍（注意这会改写文件，执行前先提交所有改动）：
git add --renormalize .5.5 IDEA 中拉取 Git 报错的三个高频原因
IDEA 里拉取项目失败，报错各有不同，但最常见的就三类。
第一，Cannot run program "git"或Could not find Git executable。这是 IDEA 没找到 Git 路径，按前面说的去Settings -> Version Control -> Git里手动指定。
第二，SSH 方式拉取时提示Permission denied (publickey)。这是公钥没配对好，检查一下密钥是否已经添加到远程平台，以及是否用的是正确密钥。可以通过ssh -T git@github.com测试，也可以确认一下~/.ssh下的私钥文件名是否符合默认规则（id_ed25519或id_rsa）。
第三，HTTPS 方式拉取私有仓库时反复弹登录框。IDEA 内置的凭据管理有时会冲突，可以把系统凭据管理器里对应的旧凭据清掉（Windows 在控制面板 -> 凭据管理器 -> Windows 凭据），重新登录一次就好。
写在最后的经验
安装 Git 这件事，表面看是下载一个软件，实际上一整套环境建设。我的个人经验是：安装时花五分钟认真看每个选项，比事后踩坑再排查要划算得多；装完之后顺手把user.name、user.email、core.quotepath、init.defaultBranch全部配置好，后面省下的是数不清的零碎麻烦。
还有一个小建议，新装好的 Git 请先建一个测试仓库，把初始化、提交、分支创建、合并、冲突解决的流程完整跑一遍，再带着这套手感去操作真实项目。不用怕搞坏测试仓库，随便折腾，反正版本管理工具最不怕的就是折腾——这也正是我们用它来管理代码的初衷。
