Git从下载安装到SSH免密配置：新手完整实操指南

很多人问过我Git怎么下载、怎么用，怎么安装配置。说实话，这类问题我一年到头不知道要回多少遍。如果只是甩一句“去官网下载安装包，敲几个命令就好”，听的人多半还是卡住，转身又去群里问第二遍。这篇文章干脆一次性把我这些年折腾Git下载、安装、配置、免密、常用命令的完整经验整理清楚，尽量做到每一步都能照着操作，同时把背后的原理也讲明白，让你下次遇到别的问题能自己推断，不用到处搜。

这篇文章不是给零基础电脑用户看的纯说明书，但也不需要多高深的技术基础。你只要会打开文件夹、会解压zip、会运行终端，就能跟着走完整条链路。学完之后，你能独立完成从下载安装、全局配置、SSH免密，到日常提交代码、分支管理、推送到远程仓库的完整闭环。以后再遇到陌生的Git命令，也有底子自己去查、自己理解。好，我们直接开始。

1. 先弄明白Git到底在管理什么，下载安装才算没白忙

不管你是下载还是安装Git，如果一开始就搞不清它到底是干嘛的，后面遇到报错的时候，十有八九会觉得这工具“设计反人类”。认知决定了你后续的上手速度，所以这一节值得先耐心看完。

1.1 Git本质上不是网盘，是一套版本快照系统

Git最核心的任务，是帮你记录一个文件夹里所有文件的变化历史。注意，是“文件夹”，不限于代码目录。很多初学者会把Git和百度网盘、坚果云这类同步工具混为一谈，这是大方向上的误解。

网盘的逻辑是“同步”：你本地改了，云端跟着改，历史版本基本拿不回来。Git的逻辑是“快照”：你每提交一次，Git就把当前所有文件的状态完整地存成一个快照，这些快照相互独立，你可以随时回到任何一个历史快照看当时的样子，也可以从任意一个快照拉出分支继续开发。

这就意味着，使用Git的核心思维方式是：主动告诉它“在这里记一笔”。Git不会自动保存你的每一次按键或保存，它只会记录你明确提交的内容。明白了这一点，后面所有命令都有了解释基础。

1.2 四个区域的概念，是你理解Git命令的骨架

日常操作Git时，脑子里始终要有四个区域的概念：

• 工作区（Working Directory）：你电脑上看到的实际文件目录，编辑器里改代码的地方。
• 暂存区（Staging Area / Index）：提交之前，先把你准备纳入这次提交的文件放进去的过渡区。
• 本地仓库（Local Repository）：项目根目录下.git文件夹里存的全部历史快照。
• 远程仓库（Remote Repository）：放在GitHub、GitLab、Gitee等平台服务器上的仓库副本。

这四个区域之间的流转，就是Git命令发挥作用的地方。工作区的改动通过git add进入暂存区，暂存区通过git commit形成本地仓库的新版本，本地仓库通过git push同步到远程仓库。反过来，远程仓库通过git pull更新到本地，本地仓库通过git checkout或git switch切换到某个历史版本，把对应文件内容还原到工作区。

等实际操作时你会发现，绝大多数命令做的事情，就是“把改动从一个区搬到另一个区”。一旦建立这个框架，很多命令根本不用死记，看到名字就能猜出大致作用。

1.3 在动手前，想清楚你的使用场景

你是个人开发者、学生做课程设计，还是团队成员协作开发？这个需求区别，会影响你后面很多配置的选择。

如果你是单机使用，暂时只需要版本管理，不急着注册托管平台账号，本地仓库已经能满足需求。如果你需要备份作品或多人协作，就必须配置远程仓库，并且尽早设置好免密登录，否则每次推送都卡在口令输入上，用几天就不想用了。

我见过一个项目组，开发了三个多月，所有代码靠微信发压缩包来回传，直到某天有人改坏了一个核心文件，又因为找不到历史版本，只能对着代码逐行恢复。后来引入Git，把提交记录和分支梳理清楚，工作节奏才真正顺起来。所以，与其把Git理解成“程序员的仪式感工具”，不如说它是工程层面的保险。明白这一点，再进入下载安装环节，你会更清楚自己每一步配置为了服务什么。

2. 下载环节的核心细节：版本选择、官方源和镜像源

一提到下载Git，很多人的反应是“直接搜Git下载，找个网页点一下不就行了”。确实，下载本身不难，但选错版本、用了来路不明的第三方渠道，后面会平白多出一堆问题。

2.1 版本怎么选：不追新，也不落伍

Git版本号通常是2.x.x的格式，比如2.43.0。我建议优先选择官方发布的新稳定版本，不要碰带rc、beta这类标识的预览版，也不要用几年不更新的老版本。

新版Git主要是修复安全漏洞、提升性能和增强协议支持。比如较新的凭证管理、子模块行为、大仓库性能都有明显改进，这些在协作场景里能体现出差异。但如果公司内网有特殊旧环境，老版本反而可能更“稳妥”。个人学习场景，最省心的做法是直接用官方最新稳定版，遇到问题容易搜到同版本资料。太偏门的版本，在IDE、CI/CD工具链集成时反而容易报依赖错误。

另外，网上那些“绿色免安装版”“精简优化版”Git，我不推荐。Git本身是开源软件，安装包体积很小，没必要为了省几MB去冒险丢失功能或者引入安全问题。这个工具将来要处理你最重要的代码，来历不明的版本风险太高。

2.2 Windows用户该下载哪个文件

进入Git官网下载页面，Windows平台下通常能看到两个主要选项：64-bit Git for Windows Setup和32-bit Git for Windows Setup。判断该选哪个很简单：

按Win + I打开系统设置，在“系统” -> “关于”里找到“系统类型”。显示“64位操作系统，基于x64的处理器”，就选64位安装包；显示“32位操作系统”，就选32位。

现在绝大多数电脑都是64位，但极少数老设备、虚拟机可能是32位。下载后可以瞄一眼文件名，确认类似Git-2.45.0-64-bit.exe这样的格式，避免下错。

如果官网下载速度慢，可以使用镜像源。国内常用的清华开源镜像站、阿里云镜像都有Git for Windows的仓库，找到对应版本的exe即可，速度通常快很多。官网直连慢的情况，换镜像能省下不少等待时间。

2.3 macOS和Linux的获取方式

macOS用户有两种主流选择：第一种是直接下载官方提供的dmg安装包，图形化安装，一步到位，适合不熟悉命令行的用户；第二种是用Homebrew执行brew install git，优点是后续升级方便，执行brew upgrade git即可。

Linux用户优先使用系统自带的包管理器。Debian/Ubuntu执行sudo apt install git，CentOS/RHEL系列执行sudo yum install git，Fedora执行sudo dnf install git。用包管理器安装，依赖关系会被自动处理，卸载也干净。

这里有个容易被忽略的共性：不管哪个平台，装完后先打开终端（Windows上打开Git Bash），输入git --version，能看到版本号才算真正装好。很多人双击安装完就以为万事大吉，结果在IDE里找不到Git路径，又来回折腾。

3. 安装向导选项的逐个拆解：这几步选错，日常使用会很难受

Windows的Git安装向导步骤不少，如果全程无脑点“下一步”，也能装完，但有些选项默认值并不适合绝大多数人的实际开发环境。我把关键步骤逐个拆开讲。

3.1 组件勾选：Git Bash和Git GUI建议保留

进入“Select Components”步骤时，默认会勾选Git Bash Here和Git GUI Here，这两个建议保留。

Git Bash是一个在Windows上模拟Unix命令行环境的终端，它最大的价值在于，让Git命令的写法在Windows和Linux/macOS之间保持一致，团队协作时不会因为平台不同出现命令语法差异。Git GUI虽然界面朴素，但在某些可视化操作、比较合并冲突时能当兜底方案。至于关联.git配置文件、增加桌面图标这类选项，看个人习惯，不影响核心功能。

3.2 PATH环境变量：这里选错，命令直接“不是内部或外部命令”

到“Adjusting your PATH environment”步骤，默认有三个选项：

• Use Git from Git Bash only：只能在Git Bash里使用git命令。
• Git from the command line and also from 3rd-party software（推荐）：CMD、PowerShell以及各种IDE都能直接调用git。
• Use Git and optional Unix tools from the Command Prompt：把一些Unix工具也加入PATH，但可能与Windows自带命令冲突。

我强烈建议选第二项。因为实际开发中，大部分人是打开VSCode、JetBrains这类IDE，在IDE集成终端里敲命令的，而IDE内部终端默认是PowerShell或CMD。如果选了第一项，IDE终端里敲git会提示找不到命令，你还得手动去设置里指定Git安装目录，非常麻烦。

3.3 默认编辑器选择：别被Vim困住

“Choosing the default editor used by Git”这一步，默认是Vim。但对不熟悉Vim操作的人来说，第一次执行git commit，编辑器直接打开Vim，光标又不能正常输入，退又退不出去，体验相当劝退。

建议在安装向导里直接改成Visual Studio Code或你日常用的编辑器。选完之后，Git需要打开编辑器时会自动调用它，提交信息的填写窗口也友好得多。前提是电脑里已经装了对应编辑器。如果平时完全不用VS Code，保持Vim也可以，但要提前记得Vim的保存退出方式：按i进入编辑模式，写完按Esc，输入:wq回车。

3.4 换行符处理：CRLF和LF的选择要认真对待

“Configuring the line ending conversions”这一步提供三个选项：

• Checkout Windows-style, commit Unix-style line endings（推荐）
• Checkout as-is, commit as-is
• Checkout Unix-style, commit Unix-style

默认第一项。意思是：Windows下检出文件时自动把LF转成CRLF，提交时再转回LF。这样团队如果Linux和Windows成员混用，仓库内历史始终是LF，文件格式跨平台不混乱。如果项目里已有严格的格式规范或统一使用Linux环境，可以按项目情况选第三项。但新手阶段，建议保持默认，减少换行冲突是最重要的。

3.5 终端模拟器、文件缓存和凭据管理器：知道默认值为什么合理

“Configuring the terminal emulator”默认是“Use MinTTY”。MinTTY对快捷键和历史命令的原生支持比Windows默认控制台更好，粘贴操作也符合Unix习惯，建议保留。

“Configuring extra options”默认勾选“Enable file system caching”，没勾选“Enable symbolic links”。文件系统缓存能提升Git对大仓库的响应速度，建议保留；符号链接在Windows下涉及权限问题，不建议新手自行开启。

后半程的“Configuring Git Credential Manager”，默认选“Git Credential Manager”，这个必须保留，后续使用HTTPS方式免密配置全靠它。如果你用的Git版本较新，可能还会看到“Enable experimental support for pseudo consoles”之类的实验选项，保持不勾选即可，那是试验性功能，稳定性没有保证。

3.6 macOS和Linux安装后的补充操作

macOS的dmg安装和普通软件一样，拖进应用程序文件夹即可。但macOS首次运行Git可能会弹出“无法打开，因为无法验证开发者”的提示，需要到“系统设置” -> “隐私与安全性”里点击“仍要打开”。

Linux用包管理器安装时，需要留意源里的Git版本会不会太旧。比如某些老版本Ubuntu源里的Git还停在2.25，功能基本能用，但遇到新版协议或者特定工具链时可能踩兼容性的坑，按需升级即可。

安装完成后不管什么平台，建议都重启一下终端或IDE，让系统重新读取PATH配置。很多人装完Git直接在同一个旧终端里执行git --version发现“命令找不到”，换个新开的终端就好了，这是很常见的“假故障”。

4. 装完立刻做的三件配置：身份、换行、凭证存储

Git装好后不配置也能运行，但你会发现提交记录里作者信息为空，远程平台也不认你的身份。所以第一件事不是急着建仓库，而是做全局初始化配置。

4.1 设置全局身份信息

打开Git Bash（Windows）或终端（macOS/Linux），执行：

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

这里的名字和邮箱就是提交记录里的署名。重点是邮箱最好用注册GitHub、GitLab或Gitee时填的那个邮箱，因为远程平台会依据邮箱把提交记录关联到你的账号头像和主页。如果邮箱不一致，平台会把提交显示成匿名或灰色未关联账号，后续追溯谁改了什么代码会非常麻烦。

另外，git config有几个作用域：

• --global：对当前系统用户生效，绝大多数个人项目都推荐用这个。
• --system：对整个系统生效，一般不建议动。
• --local：只对当前仓库生效，适合公司或团队场景里覆盖全局配置。

查看当前所有配置用git config --list。如果想改，重新执行相同命令覆盖即可。

4.2 换行符配置再次确认

安装向导里选的换行处理，已经写入了系统配置，装完后可以再确认一次：

bash复制git config --global core.autocrlf

Windows下正常回显true；macOS/Linux一般没有显式配置。如果安装时选了默认，这里基本不用动。

换行配置出问题最常见的现象是：明明只改了一行代码，git diff却把整个文件标成全部改动。这种“整个文件变红”通常就是CRLF和LF不一致导致的。遇到这种问题，要么统一调整core.autocrlf，要么在仓库根目录增加.gitattributes强制指定换行规则，后者对团队协作更稳定。

4.3 凭证存储配置：给HTTPS路线铺路

Windows安装流程一般会自动配置Git Credential Manager。可以在命令行确认：

bash复制git config --global credential.helper

正常回显是manager或manager-core。如果为空，需要手动执行：

bash复制git config --global credential.helper manager

这是HTTPS方式记住账号令牌的入口。它的意义在于：第一次通过HTTPS推送时输入一次账号密码或令牌，Git会把它安全存进系统凭据管理器，后续推送不再弹窗询问。SSH方式的免密和这个是两套体系，下一节单独展开。

做完这三件事，你的Git已经达到个人开发的可用标准。不用急着把所有配置背下来，先用起来，有问题再回头补。

5. 免密登录的完整链路：从SSH密钥生成到remote地址调整

“Git免密”是搜索热度最高的需求。所谓免密，就是推送代码到远程仓库时不用反复输入账号密码。这件事有两条路线：HTTPS路线和SSH路线。个人更推荐SSH，下面重点讲SSH，顺带提一下HTTPS。

5.1 为什么推荐SSH而不是HTTPS

HTTPS方式最直观的问题是每次git push都要输入用户名和密码。即使配置了credential helper，GitHub等平台现在也早已要求用Personal Access Token认证，不再接受普通密码。新手第一次push失败，很大概率是卡在这一步：提示认证失败，又不知道上哪儿找“密码”。

SSH方式只要把公钥放到远程平台、私钥留在自己电脑，之后所有操作都不会再被认证问题纠缠。密钥本身作为身份凭证，安全性也更高。所以个人项目、小型团队协作，SSH基本是首选。

5.2 密钥生成与算法选择

在Git Bash或终端执行：

bash复制ssh-keygen -t ed25519 -C "你的邮箱"

生成过程会询问保存路径和passphrase（密码短语）。路径默认在~/.ssh/id_ed25519，直接回车即可。passphrase如果设置了，每次使用私钥时需要输入；如果想让“免密”效果最大化，个人电脑留空就行。想要更高安全级别又不想每次输入，可以使用ssh-agent把私钥缓存起来。

为什么推荐ed25519？它生成的密钥长度短、速度快，安全性高于老旧的RSA，而且GitHub、GitLab、Gitee现在都支持。如果碰到特别老的服务器或内部系统只认RSA，再用：

bash复制ssh-keygen -t rsa -b 4096 -C "你的邮箱"

生成完成后，你的~/.ssh目录下会有两个文件：id_ed25519是私钥，自己留着，绝不外传；id_ed25519.pub是公钥，需要放到远程平台。

5.3 把公钥配置到GitHub/GitLab/Gitee

查看公钥内容：

bash复制cat ~/.ssh/id_ed25519.pub

复制输出的一大段文本（以ssh-ed25519开头）。然后到对应平台：

• GitHub：右上角头像 -> Settings -> SSH and GPG keys -> New SSH key
• GitLab：头像 -> Preferences / Edit profile -> SSH Keys
• Gitee：头像 -> 设置 -> SSH公钥

粘贴时整段复制，中间不要加空格或换行，标题可以随意起，方便自己识别是哪台机器。

5.4 验证连接与远程地址调整

配置好公钥后，测试连接（以GitHub为例）：

bash复制ssh -T git@github.com

首次连接会提示确认host key，输入yes回车。成功的话会看到类似“Hi 用户名! You've successfully authenticated”的提示，说明本机到平台的SSH通路已经打通。

下一步，把已有仓库的远程地址从HTTPS改成SSH。先看当前远程地址：

bash复制git remote -v

如果显示的是https://github.com/用户名/仓库名.git，就执行：

bash复制git remote set-url origin git@github.com:用户名/仓库名.git

之后再git push就不会要求输入账号密码了。新建远程仓库时，平台创建页面会给出对应的SSH地址，直接复制使用即可。

5.5 HTTPS方式的免密补充

如果某些场景必须用HTTPS（例如公司网络限制了SSH端口），可以通过配置credential helper实现“输入一次，后续免密”。

Windows下用Git Credential Manager，macOS下用osxkeychain，Linux下可以用cache或store。比如缓存15分钟：

bash复制git config --global credential.helper 'cache --timeout=900'

或者永久存储：

bash复制git config --global credential.helper store

但要注意，store方式是明文把凭据写在~/.git-credentials里，要自己留意文件权限。另外，HTTPS在GitHub/GitLab上已经不是普通密码，而是一个Personal Access Token。首次推送输入token，后续由credential helper保存。Token一旦生成要妥善保管，密码管理工具里存一份是明智的选择。

6. 常用命令跑通一个完整提交流程：从init到push

免密已经解决，下面用一条连贯的场景串起最常用的Git命令。假设你本地有一个项目文件夹叫test-project，里面有几个代码文件，现在要把它纳入版本管理，并和远程仓库对齐。

6.1 初始化仓库与查看状态

进入项目目录：

bash复制cd /path/to/test-project
git init
git status

git init会在当前目录生成一个.git文件夹，完成本地仓库初始化。git status会显示当前哪些文件已被跟踪、哪些未跟踪、哪些有改动。

这里有个习惯想养成：操作前先敲git status。你可能觉得多余，但很多误操作都源于对当前仓库状态不清不楚。多看一眼状态，成本很低，收益很高。

6.2 暂存与第一次提交

把文件加入暂存区：

bash复制git add README.md
git add src/     # 添加整个目录
git add .        # 添加当前目录所有文件

git add是把工作区的改动“选进”下一次提交的候选名单。确认无误后提交：

bash复制git commit -m "初始化项目"

提交后，这次快照就永久保存在本地历史里了。查看历史：

bash复制git log --oneline

你会看到一条条简短提交记录，每条前面是一串哈希值，后面是提交信息。如果想丢弃工作区某个文件未提交的改动，恢复到上一次提交的状态：

bash复制git checkout -- 文件名

注意这个命令有风险，它会直接丢弃未提交改动，执行前要确认自己真的不想要这些内容了。

6.3 分支：并行开发的根基

查看当前分支：

bash复制git branch

新项目默认在master或main分支上。创建新分支并切换过去：

bash复制git branch feature/login
git checkout feature/login

新版Git还支持更直观的写法：

bash复制git switch -c feature/login

分支的本质是“指向某次提交的游标”，创建分支几乎零成本。在分支里做实验、改代码，稳定后再合并回主分支。合并：

bash复制git checkout main
git merge feature/login

合并时如果同一文件的同一位置在两分支上都有修改，会产生冲突。冲突文件里会出现<<<<<<<、=======、>>>>>>>标记，手动编辑保留需要的代码后，再git add、git commit完成合并提交。新手第一次遇到冲突会慌，其实本质就是Git在说“这里有两份改动，你来决定留哪个”。

6.4 远程、推送与拉取

添加远程仓库（最好用SSH地址）：

bash复制git remote add origin git@github.com:用户名/test-project.git

推送本地分支到远程：

bash复制git push -u origin main

-u参数会把本地main和远程main建立关联，之后直接git push就能推送到正确分支。

远程有更新时：

bash复制git pull

git pull相当于git fetch加git merge，先拉取远程最新提交，再合并到当前分支。多人协作时，pull之前先git status确认本地没有未提交的重要改动，避免发生冲突或覆盖。

走完这一趟，你已经覆盖了日常八成以上的操作。剩下的git stash（临时保存未提交改动）、git rebase（改写提交历史）、git cherry-pick（挑选某个提交合入当前分支），都是在这个基础上派生出来的。等到实际场景需要时，对照文档很快就能上手。

7. 这类报错和反直觉行为，实际操作中最容易遇到

最后聊几个我在实际使用和带新人过程中反复遇到的坑。这些场景官方文档未必会写，但真碰上了非常耽误时间。

7.1 推送失败“fatal: unable to access ...”，排查顺序很重要

遇到推送失败，先按顺序排查：网络策略是否允许访问目标平台、git remote -v确认远程地址有没有写错、凭据或密钥是否过期。

在部分网络环境下访问海外平台不稳定，可以考虑配置镜像或等待重试，但我不建议为提速去使用来路不明的中转服务。代码安全永远比省几秒重要。最终还是要确认remote地址没问题，再检查凭证配置，一般都能定位到原因。

7.2 提交记录里作者信息不对

换了电脑后忘记配置user.name和user.email就提交，远程平台会把这些提交显示成“Unknown”或灰色未关联账号。解决方式是先把全局配置补齐，让之后提交正常。如果要修改历史提交里的作者信息，可以搜索git filter-branch或git filter-repo，但这类操作有风险，操作前务必备份仓库。

7.3 文件改名后“消失”的错觉

在Windows或macOS上，把文件名从demo.TXT改成demo.txt，git status可能不显示任何改动。这是因为Git默认把文件名视为不区分大小写。但这会给Linux平台的同事造成困扰，他们拉下仓库会发现文件名和你预期的对不上。

解决方式是使用git mv强制重命名并记录大小写变化，或者在仓库里设置core.ignorecase false。这个坑不常遇到，但遇到就很迷惑，值得记下来。

7.4 换行符导致整个文件diff全红

团队里Windows和Linux混用，如果core.autocrlf设置不统一，极容易出现“只改一行，整个文件都标红”的情况。解决方案是项目启动时就在根目录放.gitattributes，例如：

code复制* text=auto
*.js text eol=lf
*.bat text eol=crlf

这样无论团队成员用什么系统，仓库内的文本格式都被统一处理，换行问题基本一次性解决。很多老项目没做这一步，后期只能靠团队成员自觉，摩擦成本非常高。

7.5 大文件提交后仓库体积失控

不小心把一个几百MB的压缩包或数据集提交进Git仓库，之后即使删掉这个文件，历史记录里依然保留着它，仓库体积不会缩小。后续所有同事的clone、pull都会因此变得异常缓慢。

预防大于补救。第一步写好.gitignore，把build、dist、node_modules、*.zip等不该进版本库的内容排除掉；如果确实需要管理大的二进制文件，用Git LFS。若不慎已经提交了，那就得趁早检查历史，把大文件从所有提交记录里抹除。这个操作需要谨慎评估，在团队确认无影响的前提下进行。

说实话，我见过最多的场景是：项目做到一半做不下去，不是功能写不出来，而是版本混乱到不敢改代码。Git带来的最大价值，不是那几条命令，而是一整套“可以后悔”的工程安全感。所以最后一条建议是：提交信息认真写，提交频率适中，一个功能点一次commit是底线。按语义写提交信息，比如“feat: 增加登录接口”“fix: 修复空指针”，三个月后再回看，你会感谢当时认真的自己。