企业官网建设流程全解析

1. 写在前面：Windows上装Git到底会卡在哪

Windows 上装 Git，听起来是双击 next 到底就完事的事情，但真正把整套流程走完的人其实不多。下载下载不全、PATH 没配上、命令敲不了、SSH 密钥讲不清楚，每一步都能把人卡住。尤其是新买的电脑第一次配开发环境，装完 Git 以为自己搞定了，结果打开 GitHub 想克隆一个仓库，又卡在认证上，那种挫败感我见得太多了。

这篇文章不搞虚的，从下载安装包开始，逐项拆解安装向导里每个选项的含义和取舍，再讲环境变量、全局配置、SSH 密钥的生成与多平台绑定，最后附上我日常工作中高频命令速查表和排错清单。无论你是第一次装 Git 的纯新手，还是装了好几次但总在密钥和克隆上传上出问题的老手，这套流程都可以直接照着抄。

整篇教程基于最新版的 Git for Windows，写这篇的时候官方发布渠道已经稳定在 2.5x 系列，安装界面和选项在细节上可能随小版本微调，但核心选项完全一致。你下载到什么版本都不影响操作，方法通用。

1.1 为什么资料很多，你还是装不好

我在做开发工具答疑的时候，见过太多类似场景：照着网上的图文教程一路 next，结果打开命令行敲git --version直接提示"不是内部或外部命令"；还有人卡在git push时控制台弹出授权窗口，密码输了好几遍还是失败；再就是换了新电脑，旧电脑的 SSH 密钥没备份，远程仓库死活连不上。

这些问题归根到底有几个原因。第一，很多教程是某个版本的快照，Git for Windows 更新很快，旧截图和现在的安装界面已经对不上号。第二，教程只给步骤不给原理，选项该勾不该勾全靠猜，理解不深入，一旦出问题就懵。第三，Windows 环境差异大，杀毒软件策略、用户目录权限、系统本身是否启用了 Windows OpenSSH，这些都会影响最终效果。

所以这套教程我沿用一个思路：每个关键选项都解释清楚"选这个而不选那个的原因"，每个环节给出验证方法。你也别急着跳过，通读一遍再动手，其实花不了多少时间，但后面能帮你省下大把排查的功夫。

1.2 这篇教程的路线图

先说路线：下载安装包 → 安装（重点解读每个选项）→ 环境变量与全局配置 → SSH 密钥生成与绑定 → 高频命令与问题排查。这是我在新电脑上每次都要走一遍的完整流程，也应该是你从零配置一套 Windows 开发环境的基本顺序。

适合谁来看？第一次在 Windows 上装 Git 的新手，照着顺序操作基本不会出大问题；已经装过 Git 但不懂配置含义的老手，可以重点看第 4、5 章，里面有不少命令是我这些年实际用下来沉淀出来的；做远程开发的，第 5 章的 Remote-SSH 部分以及 config 多账号管理，建议反复看两遍。

另外说明一下，整篇涉及的命令，我在 Windows 10 和 Windows 11 上都实测过，Git Bash、PowerShell、CMD 三种环境下都能跑通。个别路径写法在不同版本的 Windows 上略有差异，我会在后面提到。

2. 下载Git安装包：官网和国内镜像怎么选

2.1 官网下载的正确姿势

Git 官网是 git-scm.com，Windows 版本下载页会自动识别操作系统并推荐 64 位安装包，下载文件的命名类似Git-2.5x.x-64-bit.exe。打开 Downloads → Windows，看到"64-bit Git for Windows Setup"点击即可。

官网的好处是永远第一时间拿到最新版，页面也不会夹带广告。但直链在某些网络环境下下载速度不一定理想，下载到一半断掉也很常见。遇到这种情况不用硬扛，直接换国内镜像站下载同一个文件，安装包文件本身没有任何区别。

这里有一个判断方法：官网下载页会显示当前最新版本号和上传日期，你可以拿这个版本号去镜像站比对，确保自己下载的是同一个版本。如果镜像站的版本号比官网低一两个小版本，问题也不大，Git 的小版本更新通常不影响基本功能，但对于刚入门的用户，我建议尽量和官网保持一致。

2.2 国内镜像站与版本选择

国内几个主流镜像站都同步维护了 Git for Windows 的安装包，速度和稳定性都足够日常使用。

进入镜像站后，路径一般类似/git-for-windows/，里面按版本号分目录，每个目录下有 32 位、64 位的安装包和 Portable 版压缩包。找-64-bit.exe结尾的文件下载就行。

版本选择上，我只有一个建议：别追 preview 版本，别用 32 位安装包。除非你的 Windows 系统本身就是 32 位的老电脑，否则一律选 64 位。preview 是预览版，可能存在尚未修复的问题，日常开发没必要冒险。

2.3 安装器选 Standard 还是 Portable

Git for Windows 官方给 Windows 用户提供两种形态：标准安装器（Setup）和便携版（Portable）。

标准安装器会把 Git 注册进系统，包含右键菜单、PATH 环境变量、凭据管理器等一整套集成功能，这也是绝大多数人应该选的。Portable 版是一个压缩包，解压就能用，适合放在 U 盘里临时应急，但它默认不参与系统集成，PATH、右键菜单、凭据存储都得手动弄，成本比你想象的高。

所以我的结论很直接：新手一律用标准安装器，Portable 版等你有明确的绿色软件需求时再研究。

3. 安装全程拆解：每一步为什么这么选

3.1 安装前的准备工作

下载完安装包，先别急着双击。我建议你做三件事。

第一，如果你电脑上装过旧版 Git，先确认它是否还能正常卸载干净。Git for Windows 支持直接覆盖安装，但如果你之前装过某个预览版或者修改过安装路径，最好在控制面板的"程序和功能"里先卸载一次，免得残留配置影响新版本。

第二，临时关闭杀毒软件的实时防护，或者至少在安装过程中留意拦截弹窗。Git 的安装包需要往Program Files和用户目录写入大量文件，部分杀毒软件对 Git 的 bash.exe、ssh.exe 会有误报，导致安装进度卡住或文件被隔离。装完恢复防护即可，这一步只是常规的安装期操作。

第三，右键安装包，选择"以管理员身份运行"。虽然 Git 安装不强制管理员权限，但管理员权限能避免 UAC 弹窗在安装过程中反复打断，也能确保写入Program Files时权限足够。

3.2 安装向导的每个关键选项，挨个说清楚

进入到安装向导后，绝大多数选项保持默认没问题，但有几个地方值得花二十秒理解一下，因为它们直接影响你后面的使用体验。

Select Components（选择组件）

这个界面里，Additional icons是桌面图标，可留可不留。重点在Windows Explorer integration里的两个选项：Git Bash Here和Git GUI Here。这两个强烈建议勾选。装了之后，你在任意文件夹的空白处点右键，菜单里就有"Git Bash Here"，直接打开一个当前路径的 Git Bash 窗口，省去cd的功夫。日常操作效率差太多了。

下面的 "Associate .git* configuration files with the default text editor" 和 "Associate .sh files to be run with Bash" 保持默认就行。前者让.gitconfig这类配置默认用文本编辑器打开，后者让.sh脚本默认交给 Bash 解释。

Select Start Menu Folder（开始菜单目录）

保持默认，不用动。它只在开始菜单里创建快捷方式，不影响任何功能。

Selecting the Default Editor（默认编辑器）

默认是 Vim。对新手来说，Vim 最大的问题是误入编辑器界面后不知道怎么退出。你执行git commit没带-m参数时，会弹出一个编辑器让你写提交说明，Vim 环境下新手经常卡在"不知道怎么保存退出"。建议直接选 Visual Studio Code，前提是你电脑上装了 VS Code；如果没装，选 Notepad++ 也行。

这个选择不是随便定的。编辑器是你提交代码时频繁打交道的地方，选一个熟悉顺手的，比硬着头皮学 Vim 要实用得多。当然，等以后你主动想学 Vim 了，再用git config --global core.editor "vim"改回来也不迟。

Adjusting your PATH environment（PATH 配置）

这一步是整个安装过程中最重要的一个选项，三个单选分别对应不同的 Git 使用范围。

• 第一项 "Git from the command line and also from 3rd-party software"：推荐。这样 Git 不仅能在 Git Bash 里用，在 CMD、PowerShell，以及 VS Code 自带终端里都能直接敲git命令。
• 第二项 "Git from the command line and also from 3rd-party software" 其实是第一项的文字说明？不，这里要注意：真正的第二项是 "Use Git from Git Bash only"，第三项是 "Use Git and optional tools from the Command Prompt"。

我实际安装时会选第一项。第二项意味着只有 Git Bash 里能用 git，CMD 和 PowerShell 里敲git会提示找不到命令，对现在很多在 VS Code 集成终端里写代码的人来说会很别扭。第三项会把 Git 附带的一堆 Unix 工具（find、sort、cut 等）也塞进 PATH，与 Windows 系统自带的同名命令容易冲突，不建议勾选。

Choosing the SSH executable（选择 SSH 客户端）

新版本安装向导会有这一步：Use bundled OpenSSH还是Use external OpenSSH。保持默认的 bundled OpenSSH 就行。Git for Windows 自己打包了一个 OpenSSH 客户端，和 Git 的集成度最好。如果选择系统的外部 OpenSSH，版本和配置可能跟 Git 期望的不一致，反而增加排错成本。

Choosing HTTPS transport backend（HTTPS 传输后端）

这里两个选项：OpenSSL 和 Windows Secure Channel。默认 OpenSSL，保持默认即可。Secure Channel 是 Windows 原生安全通道，针对企业内网自签名证书有特殊处理；OpenSSL 更通用，对绝大多数开发者来说，不用在这上面纠结。

Configuring the line ending conversions（换行符转换）

这一步对跨平台协作影响很大。三个选项分别是：

• 第一项Checkout Windows-style, commit Unix-style line endings：默认。检出代码时行尾转成 CRLF（Windows 换行），提交时转回 LF（Unix 换行）。适合团队全员 Windows。
• 第二项Checkout as-is, commit Unix-style line endings：工作区保持原样，提交时统一转 LF。
• 第三项Checkout as-is, commit as-is：完全不转换。

我的建议是：个人学习、团队全 Windows 的，用默认第一项就行。如果你要和 macOS、Linux 同事协作同一个仓库，尤其是仓库里有 shell 脚本的，我更推荐第三项Checkout as-is, commit as-is，然后让全团队统一用这个配置。原因很简单，自动换行转换虽然初衷好，但在 diff 对比、脚本执行时经常带来莫名其妙的坑。CRLF 的 shell 脚本在 Linux 上执行会直接报\r错误，这类问题排查起来非常磨人。

Configuring the terminal emulator（终端模拟器）

默认Use MinTTY，保持默认。MinTTY 是 Git Bash 使用的终端模拟器，复制粘贴、窗口缩放、中文显示都更顺手。Windows 自带的控制台窗口（旧版 conhost）在某些场景下对 ANSI 颜色支持不太好，用户体验差一截。新版 Windows Terminal 做得不错，但 Git Bash 与 MinTTY 的搭配仍然是最稳的。

Choose the default behavior of git pull（git pull 的默认行为）

默认第一项Default (fast-forward or merge)。保持默认，等以后你能分清 merge 和 rebase 的区别，再在git config --global pull.rebase false/true里改不迟。对新手来说，默认行为最容易理解，也最不容易出意外。

Choose a credential helper（凭据管理器）

默认 Git Credential Manager，保持勾选。这个组件的作用是管理 HTTPS 方式的账号密码，第一次访问 GitHub 等平台时，它弹出浏览器让你登录授权，之后就不再反复要密码了。如果你把它选成 None，那么走 HTTPS 协议的每次 push/pull 都要手动输入账号密码，非常痛苦。所以这里千万别手抖。

Configuring extra options（附加选项）

Enable file system caching默认勾选，保持默认。Enable symbolic links建议不要动，Windows 下的符号链接需要开发者模式权限，普通场景用不上。实验性选项更是一律不勾。

3.3 安装完成后的第一轮验证

安装到最后一步，勾选 "Launch Git Bash" 然后 Finish，会弹出一个 Git Bash 窗口。先敲：

git --version

正常会输出版本号，比如git version 2.5x.x.windows.1。然后关掉 Git Bash，打开 CMD 或 PowerShell，再敲一次git --version。

这一步的目的是确认 Git 能被所有常用终端识别。如果 CMD 里提示"不是内部或外部命令"，说明 PATH 没生效，回到下文第 4.1 节检查环境变量。绝大多数人的问题都出在这里，装是装上了，但只在 Git Bash 里能用，出了门就废。

4. 环境变量与全局配置：装完别急着走

4.1 PATH 环境变量的检查与手动修复

安装时如果选了"Git from the command line and also from 3rd-party software"，安装程序会自动把C:\Program Files\Git\cmd写进系统的 PATH 环境变量。正常情况下，安装完重开一个终端，git命令就能用了。

如果你发现 CMD 或 PowerShell 里还是找不到 git，点"开始"搜索"环境变量"，进入"编辑系统环境变量"→"环境变量"→ 在"系统变量"里找到Path，双击编辑，把C:\Program Files\Git\cmd加进去（如果 Git 装在其他盘，就填你实际的安装路径）。

修改完环境变量，务必把终端窗口全部关掉，重新打开。环境变量是在进程启动时读取的，不重开终端的话，新配置不会生效。这个细节很多新手不知道，改完发现还是不行，以为没改对，其实只是没重启终端。

4.2 必须先做的全局用户信息设置

安装完 Git 第一件事，设置用户名和邮箱。Git 的每次提交（commit）都会记录这两个信息，不设置的话，提交时 Git 会报错，或者在提交记录里留下错误的作者信息。

打开 Git Bash，执行：

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

邮箱建议和你注册 GitHub、Gitee 等平台的邮箱保持一致，否则提交记录在平台上无法正确关联到你的账号。如果你在 GitHub 设置过隐私邮箱，用 GitHub 提供的用户名@users.noreply.github.com也可以。

用git config --list可以查看当前所有的 Git 配置。注意，命令里区分了 system、global、local 三个层级：--global只影响当前用户，--local只影响当前仓库，system 影响整台机器。后面的全局配置我们在用户级做，仓库级配置留给具体项目。

4.3 让你少踩坑的几个全局配置

user.name 和 user.email 只是起点，还有几个全局配置我建议你现在就顺手设上，能省掉后面一堆麻烦。

git config --global core.autocrlf true git config --global core.quotepath false git config --global init.defaultBranch main git config --global push.autoSetupRemote true git config --global alias.lg "log --oneline --graph --all --decorate"

core.autocrlf的值要和你安装时选的换行符选项对应。装的时候选的第一项，对应true；选的第三项，对应false。这块如果没把握，就别来回改，保持安装时的设置即可。

core.quotepath false是重点。默认情况下，Git 在显示中文文件名时会转义成\346\226\260\345\273\272这种八进制序列，因为 Windows 下中文路径太多太常见了，不关掉这个选项，git status看到的全是乱码。把core.quotepath设为false，中文就能正常显示。之前有同学在使用 SourceTree 或 VS Code 时看到命令里有-c core.quotepath=false，原理就是通过参数临时关掉同样的转义。

push.autoSetupRemote true是 Git 2.37 之后才有的配置。默认情况下，你在本地新建一个分支，第一次 push 时要用git push -u origin branchname指定上游。设了这个配置后，直接git push就能自动创建远程分支，对我这种经常开分支的人非常友好。

给git log起个别名是个人习惯，执行完上面那句后，敲git lg就能看一个带图形、带颜色、带全分支的提交历史，比默认的 log 输出直观太多。类似的别名你还可以自己加，比如git config --global alias.st status。

4.4 Git Bash 的个性化小设置

Git Bash 本质上是一个运行在 Windows 上的类 Unix 环境，配置文件在用户目录下的.bashrc和.bash_profile。用编辑器打开C:\Users\你的用户名\.bashrc，可以加一些自己的习惯配置。

比如我常用的：

alias ll='ls -al' alias gs='git status' alias gp='git push' alias gl='git pull'

Git Bash 默认已经带了ls命令，但ll这个 Linux 下常见的别名未必有，加上之后体验会顺很多。改完.bashrc执行source ~/.bashrc，或者直接重开一个 Git Bash 窗口生效。

还有个小细节：Git Bash 的默认配色和字体可以在窗口标题栏右键 → Options 里调整。我习惯把 Text 字体设成 Consolas，字号 14，看代码不累眼睛。这个属于纯个人偏好，看你自己。

5. SSH密钥：从生成到绑定远端，一步不落

5.1 为什么推荐 SSH 而不是 HTTPS

Git 操作远程仓库有两种协议：HTTPS 和 SSH。HTTPS 简单，但每次 push 都要把凭据交给 Git Credential Manager，虽然不用反复输密码，但认证过程偶尔会弹出奇怪的窗口，尤其是在公司网络或换了电脑之后。SSH 则是用一对密钥来认证：公钥放到 GitHub、Gitee、GitLab 这样的代码托管平台，私钥留在本地，push/pull 时 Git 用私钥证明"你是你"。

这个机制可以理解成一把锁配一把钥匙。公钥是锁，你可以随便发给别人，挂在平台上就是告诉平台"这把锁认这把钥匙"；私钥是钥匙，必须锁在自己手里，绝对不能泄露、不能发给别人、不能传到公共仓库里。如果私钥泄露，任何人拿到它都能以你的身份操作有权限的仓库，所以私钥文件要像保护银行卡密码一样保护好。

对于日常开发，SSH 的好处是配置好之后完全免密，省去 HTTPS 认证的各类麻烦。代价是最初多花十分钟配密钥，但这是一次性的投入，长期收益非常明显。

5.2 生成 SSH 密钥：ed25519 还是 RSA

在 Git Bash 里执行：

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

-t ed25519指定使用 ed25519 算法，-C是注释，通常是邮箱，方便你在平台后台认出这把钥匙是哪个设备的。

按回车后，它会问你要把密钥保存在哪里，默认是C:\Users\你的用户名\.ssh\id_ed25519，直接回车用默认路径。接着问是否设置 passphrase（密码短语），可以留空直接回车，也可以设一个。如果你设了 passphrase，以后每次用这把钥匙时都要输入一次，但配合 ssh-agent 可以只输一次。我建议至少设一个，尤其笔记本电脑容易丢，没有 passphrase 的私钥文件一旦泄露就完了。

为什么不推荐 RSA？RSA 的安全性没问题，GitHub、Gitee 都支持，但 ed25519 的密钥生成速度快、长度短、签名安全性更好，是当前主流推荐。只有在连接一些老旧服务器，服务端 OpenSSH 版本过低不支持 ed25519 时，才需要改用：

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

生成完成后，进入~/.ssh目录会看到两个文件：id_ed25519是私钥，id_ed25519.pub是公钥。你可以用cat ~/.ssh/id_ed25519.pub查看公钥内容，后面绑定平台要用。

这里有个 Windows 特有的坑：如果你在 PowerShell 里用 Windows 自带的 OpenSSH 生成过密钥，再用 Git 的 ssh.exe 访问，有时候会遇到算法或权限方面的报警。我的建议是从头到尾统一用 Git Bash 生成的密钥，并且在 Git 环境里始终用 Git 自带的 OpenSSH。如果某些外部工具调用了C:\Windows\System32\OpenSSH\ssh.exe，出奇怪问题的时候，可以给系统环境变量添加GIT_SSH指向C:\Program Files\Git\usr\bin\ssh.exe，强制 Git 使用自带 SSH。

5.3 公钥绑定到 GitHub / Gitee / GitLab

公钥内容复制好之后，去代码托管平台的后台绑定。

GitHub 的路径：右上角头像 → Settings → 左侧 SSH and GPG keys → New SSH key。Title 填一个你能认出来的描述，比如"Windows 笔记本"，Key 里粘贴公钥内容，然后 Add SSH key。Gitee 的路径类似：头像 → 设置 → SSH 公钥。GitLab 则在 Preferences → SSH Keys。

粘贴公钥时有个细节：整段内容要完整复制，从ssh-ed25519一直到最后，不要多复制空格、不要漏行。一行就是一个完整的公钥，通常形如：

ssh-ed25519 AAAAC3NzaC1lZDI1...（一串很长的字符） 你的邮箱

绑定完之后先别急着 push，先测一下连接通不通，见下文 5.5 节。

5.4 多账号多平台：用 config 文件分开管理

很多人的情况是一个 Git 对应多个平台，比如 GitHub 和 Gitee 同时用，甚至不同平台想用不同的密钥。怎么办？

先分别生成不同名字的密钥。比如：

ssh-keygen -t ed25519 -C "github邮箱" -f ~/.ssh/id_ed25519_github ssh-keygen -t ed25519 -C "gitee邮箱" -f ~/.ssh/id_ed25519_gitee

-f参数指定文件名。生成完毕后，在~/.ssh目录下新建一个名为config的文本文件，写入：

Host github.com HostName github.com User git IdentityFile ~/.ssh/id_ed25519_github Host gitee.com HostName gitee.com User git IdentityFile ~/.ssh/id_ed25519_gitee

这个配置文件的意思是：当 Git 访问github.com时，使用id_ed25519_github这把私钥；访问gitee.com时，使用id_ed25519_gitee。写完保存，config 文件的编码建议用 UTF-8，换行符最好统一成 LF，虽然 Git Bash 一般也能处理 CRLF，但统一 LF 能少很多奇怪的解析问题。

分号后的缩进不是必须的，但建议保留，方便阅读。每个Host字段就是匹配规则，后续你还可以用这种写法管理多台服务器，比如给远程开发机单独设一个别名。

5.5 测试连接与常见认证报错

配置完成后，在 Git Bash 里测试：

ssh -T git@github.com

第一次连接会让你确认主机指纹，输入yes回车。如果一切正常，GitHub 会回复一句类似：

Hi 用户名! You've successfully authenticated, but GitHub does not provide shell access.

看到就说明 SSH 通道已经通了。Gitee 的测试命令是ssh -T git@gitee.com，回复套路差不多。

如果提示Permission denied (publickey)，通常有四个排查方向：

第一，确认私钥路径和IdentityFile配置一致，ls ~/.ssh/看下文件名有没有拼错。第二，确认公钥确实已经粘贴到了平台的对应账号下，平台之间不通用。第三，检查 ssh-agent 是否加载了密钥，执行ssh-add -l看列表，如果为空，用eval "$(ssh-agent -s)"和ssh-add ~/.ssh/id_ed25519加载。第四，用ssh -vT git@github.com看详细调试信息，会输出具体卡在哪个步骤。

另外，Host key verification failed这个报错很多人在换掉服务器或者重装系统后遇到。原因很简单，本地记录过的 known_hosts 里该主机的指纹和现在的不一致，Git 出于安全考虑拒绝连接。解决方法是删掉旧记录：

ssh-keygen -R github.com

然后重新ssh -T git@github.com，输入 yes 添加新指纹即可。

5.6 Windows 本地怎么用 VS Code Remote-SSH 连远程服务器

很多 Windows 开发者配 SSH 不只是为了 Git 仓库，还要用 VS Code 远程连服务器开发。这一节把这条路也串一下。

前提是本地已经生成好 SSH 密钥（上一节的步骤就有）。然后在 VS Code 里安装Remote - SSH扩展，左侧会出现远程资源管理器图标。点击加号，输入ssh 用户名@服务器IP，回车后选择保存到本地哪个 SSH 配置文件，VS Code 会启动一个新窗口并通过 SSH 连接到远程服务器。

首次连接需要输入服务器密码。如果不想每次都输密码，把本地的公钥追加到服务器的authorized_keys里即可。在本地 Git Bash 执行：

cat ~/.ssh/id_ed25519.pub | ssh 用户名@服务器IP "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 700 ~/.ssh && chmod 600 ~/.ssh/authorized_keys"

这个命令会先提示输入一次服务器密码，之后就免密连接了。如果是多台服务器，可以分别把同一把公钥加到每台服务器的authorized_keys里，或者按第 5.4 节的方式给每台服务器建独立的密钥。

还有一个 VS Code 相关的坑，可能你在网上见过这样的提示："此扩展在此工作区中被禁用，因为其被定义为在远程扩展主机中运行"。这是扩展的安装位置问题。用 Remote-SSH 打开远程目录后，扩展默认分成本地端和远程端两类，有些扩展设计上只在远程端运行，打开远程工作区时本地工作区会自动禁用它们。解决办法很简单：在 VS Code 的扩展面板里，找到这个扩展，选择"在远程安装"或"在 SSH 主机中安装"，让它在远程端重新装一遍，提示就消失了。

6. 高频命令速查与常见问题排查实录

6.1 日常够用的高频命令速查表

配置好环境只是开始，真正天天打交道的是命令。下面这张表是我在实际开发里使用频率最高的命令，按使用场景排好，新手可以先背前五行，后面用到再查。

git status是每个新手最容易忽略但最有用的命令，你随时不知道自己改了什么、加了什么、和远程差了什么，它都会清楚告诉你。记不住其他命令没关系，先记住git status，再配合git log，基本就能在仓库里摸清方向了。

6.2 安装阶段的经典问题汇总

安装阶段的坑我列几个最常见的，照着排查基本能解决。

进度条卡住，提示"安装未完成"。这类问题在 Windows 上很常见，Git 不是唯一受害者，很多开发工具安装包都容易中招。优先怀疑杀毒软件实时防护拦住了安装进程，临时关掉防护再装一次；其次看系统里有没有残留的 Git 进程，打开任务管理器结束所有 git.exe、bash.exe 相关进程，然后清理临时目录（%TEMP%下以 Git 开头的文件夹），最后右键以管理员身份重新安装。

右键菜单里没有 "Git Bash Here"。安装时没有勾选Windows Explorer integration就会出现这种情况。最简单的修复是重新运行安装包，选择 Modify 或者 Repair，把Git Bash Here勾上。

Git Bash 打开就闪退。尝试在 Git Bash 属性里换字体，或者先改用 Windows 控制台模式。如果之前改过终端模拟器配置，可以重装一次恢复默认。老版本在个别显卡驱动上有渲染问题，升级到新版 Git for Windows 一般能解决。

6.3 配置与使用阶段的经典问题速查表

配置和使用阶段的坑更多，我整理成一张速查表，你在网上看到的报错多半都能在这里对上号。

git remote set-url这条命令很有用。有时候你 clone 的时候顺手用了 HTTPS，后面又想换 SSH，不用重新 clone，直接改 remote 地址就行。先git remote -v看当前地址，再 set-url 换成 SSH 的地址，之后 push 就走 SSH 通道了。

6.4 顺手省事的几个小技巧

最后分享几个我用了很多年的小技巧，说不上多高级，但确实省事。

git commit --amend可以修改上一次提交。如果你刚提交完发现注释写错了，或者漏了一个文件，git add后执行git commit --amend --no-edit就能把改动合到上一次提交里，不会多出一条凌乱的提交记录。注意，这个操作只适合还没 push 的提交，push 之后尽量不要改，否则会给协作者添麻烦。

git add -p是分块暂存。这个命令相对冷门，但非常好用。你改了三个功能混在同一个文件里，只想提交其中一个功能，用git add -p会逐段询问你是否暂存，按 y 或 n 就能精确控制提交范围。配合git commit可以做出非常干净的提交历史。

在 Git Bash 里想用 VS Code 直接打开当前目录，如果安装 VS Code 时勾选了右键菜单，在 Git Bash 里直接敲code .就能打开。如果提示找不到命令，在 VS Code 里按Ctrl+Shift+P执行Shell Command: Install 'code' command in PATH即可。

查看 Git 自带的全部命令，用git help -a会列出所有子命令。某个命令的用法记不清了，git help <命令>会在本地打开官方文档，比上网搜要快，而且版本匹配绝对准确。

7. 最后分享几个真实体会

安装配置 Git 这条路，我自己走过好几遍，也在新电脑上帮人配过无数次，最后留几句实在话。

第一，配置是给自己看的，别照抄别人的全套。不同团队、不同项目对换行符、pull 策略、编辑器选择都有偏好，你只需要理解每个配置项在干什么，然后选适合自己的组合。我自己的长期组合是：安装时编辑器选 VS Code，换行符选 "Checkout as-is, commit as-is"，SSH 一律用 ed25519 密钥，多账号用 config 文件管理，这套组合我用了四五年，没出过什么大问题。

第二，Windows 下能用 Git Bash 就用 Git Bash。PowerShell 和 CMD 都能调用 git，但 Git Bash 提供的类 Unix 环境对命令处理、SSH 密钥权限、脚本执行都更友好。很多报错在 Git Bash 里不会出现，换到系统自带终端就冒出来，大多和 Windows OpenSSH 的权限检查机制有关，别在这上面浪费过多时间。

第三，换新电脑时，一定记得备份C:\Users\你的用户名\.ssh这个目录。密钥文件是跟着电脑走的，电脑换了没备份，所有远程仓库的 SSH 访问全部断掉。备份的时候连同 config 配置文件一起拷走，新电脑放回同路径、修好权限就能无缝衔接。

最后再分享一个小细节：装完 Git 后建议立刻执行一次git config --global --edit，把全局配置整体看一遍。这个命令会打开编辑器让你检查所有全局配置，很多问题在源头就能发现。等你在实际项目里遇到乱码、换行、认证问题再回头排查，心态完全不一样。

Git 本身不难，难的是把环境一次配好、把原理理解透。现在你手里的这套流程，够你踏踏实实用上很多年。