Windows下Git与Gitee从零到推送：安装配置、SSH密钥及避坑指南

最近好几个同事都在问 Windows 上怎么把代码推到 Gitee，有的是刚接触 Git 的小白，有的用了几年 Git 但一直在 IDE 里点按钮，遇到命令行就发怵。我干脆把从零开始到正常推送的完整流程梳理了一遍，包括安装时哪些选项要勾、SSH 密钥到底怎么配、推送报错怎么排查，争取一篇文章把 Git 在 Windows 上配合 Gitee 使用的全过程讲透。

这篇内容适合两种人：一是完全没装过 Git 的纯新手，照着一步步做就能跑通；二是已经能用 Git 但经常被各种报错卡住的人，可以重点看后面的排查部分。我会把每一步背后的原因也讲清楚，这样以后遇到类似问题你自己就能判断该怎么处理。

1. 整体设计与方案选型

1.1 为什么选择 Git + Gitee 这个组合

Git 作为分布式版本控制系统，几乎成了现代软件开发的基础设施。Gitee（码云）是国内流行的代码托管平台，提供 Git 仓库托管服务，在国内的访问速度和稳定性通常优于境外平台，而且免费账户就能建私有仓库，对个人开发者和小团队非常友好。

Windows 上使用 Git 的通行方案是安装 Git for Windows，它会同时提供 Git Bash（一个模拟 Linux 终端的命令行环境）、Git GUI（图形界面）以及 Git 命令本身。虽然 Windows 也有其他 Git 客户端，比如 SourceTree、TortoiseGit，但 Git for Windows 是官方维护的版本，升级及时、兼容性好，也是绝大多数教程和文档默认的基准环境。就算你平时用 IDE 集成的 Git 功能，底层调用的仍然是这一套 Git 程序。

将 Git 与 Gitee 组合，本质上是在本地版本管理和远程协作之间建立一条稳定通道。本地 Git 负责记录每一次代码变更，Gitee 负责存储和同步这些变更，实现多设备、多人的协作。理解了这层关系，后面所有操作都是围绕“本地仓库”和“远程仓库”的交互展开的。

1.2 Windows 环境下要提前避开的几个坑

Windows 和 Linux/macOS 在使用 Git 时有一些天然差异，提前了解能省去后面排查问题的精力。

第一个坑是换行符问题。Windows 使用 CRLF（回车+换行）作为文本换行符，而 Linux/macOS 使用 LF（换行）。如果处理不当，Git 会提示“LF will be replaced by CRLF”之类的警告，甚至导致文件内容被意外修改。这个在安装时选择合适的换行符处理策略就能解决，后面我会详细说明。

第二个坑是命令行环境差异。Windows 自带的 CMD 和 PowerShell 对很多 Git 命令的支持不够友好，比如路径转义、环境变量传递等。Git for Windows 自带的 Git Bash 模拟了 Unix 风格的 shell 环境，能避免大量兼容性问题，强烈建议使用。

第三个坑是中文乱码。Windows 系统默认的字符集是 GBK 而不是 UTF-8，这可能导致 Git 输出信息、文件名出现乱码。通过调整 Git 的 core.quotepath 配置和终端编码可以解决。

第四个坑是 SSH 密钥路径。Windows 下 SSH 密钥默认存储在 C:\Users\你的用户名\.ssh 目录，有些教程写的路径不完整，导致密钥生成成功却找不到文件。这些细节我都会在对应步骤中标注。

1.3 HTTPS 还是 SSH：传输协议选择的逻辑

Gitee 支持 HTTPS 和 SSH 两种方式访问远程仓库。两者各有适用场景，选择依据不复杂。

HTTPS 方式的特点是配置简单，克隆仓库时使用仓库主页的 HTTPS 地址即可，首次推送时输入用户名和密码（或私人令牌）验证身份。缺点是每次推送都可能要求验证，虽然可以配置凭据缓存，但总归要多一步操作。

SSH 方式的特点是免密推送，只需把本地生成的公钥添加到 Gitee 账户，之后所有 Git 操作都不需要再输入账号密码。适合需要频繁推送的日常开发场景。缺点是首次配置比 HTTPS 多几个步骤。

我个人的建议是：日常开发项目使用 SSH，一次配置长期受益。如果只是临时拉取公开仓库，保持 HTTPS 也可以，因为克隆公开仓库本身不需要身份验证，只有推送私有仓库时才需要。这个选择不影响 Git 本身的功能，纯粹是接入方式的偏好，下面我会按 SSH 方案展开，这也是多数开发者的主流选择。

2. 核心细节解析与实操要点

2.1 Git for Windows 安装过程的选项抉择

到 Git 官网下载 Windows 版本的安装包，然后开始安装，整个过程会弹出好几个配置界面，很多新手就卡在这。大多数选项保持默认即可，但有两个关键项需要留意。

关键项一是选择默认编辑器。Git 在提交时如果遇到需要填写提交信息的情况，会调用默认编辑器。默认选项是 Vim，但对 Windows 用户来说 Vim 的操作方式不熟悉，很容易出现打开编辑器后不知道怎么保存退出的情况。建议直接选择列表中的 VS Code（如果已安装），或者用下拉框选 Notepad++，总之选一个你熟悉的编辑器，能把精力集中在 Git 本身。

关键项二是调整 PATH 环境变量。安装程序会问你要不要调整 PATH，有三个选项：第一个是“仅从 Git Bash 使用 Git”（默认），第二个是“从命令行以及第三方软件使用 Git”（推荐），第三个是“从命令提示符使用 Git 和 Unix 工具”。建议选择第二项，这样在 CMD、PowerShell、VS Code 终端里都能直接调用 Git 命令。选了第三项可能会导致 Windows 自带的某些命令被 Git 的 Unix 工具覆盖，比如 find 命令，容易引发意外问题。

关键项三是行尾换行符处理方式。安装程序会询问 Checkout Windows-style, commit Unix-style line endings 之类的内容，默认选项就行。它的意思是检出到工作区时自动转换成 CRLF，提交到仓库时转换成 LF。这个策略适合纯 Windows 环境。如果你在 Windows 上开发的项目也会同步到 Linux/macOS 上使用，可以选择第二项（按当前系统决定），或者用第三种方案（不转换），并在项目里放一个 .gitattributes 文件来统一规范。刚开始不用纠结，先选默认，等遇到实际问题再调整也不迟。

安装完成后，可以在任意终端执行 git --version 验证是否成功，看到版本号输出就说明安装正常。

2.2 Git 用户信息配置：为什么必须设置

Git 的每次提交都会记录作者信息和邮箱，这是版本历史的组成部分。没有配置用户信息的 Git 在提交时会报错。配置方式是在 Git Bash 中执行：

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

其中 --global 参数表示全局生效，即这台机器上所有 Git 仓库都使用这个身份信息。如果某个项目需要单独使用不同的身份，可以在项目目录下执行同样的命令并去掉 --global。

这里特别提醒一点：邮箱建议和 Gitee 注册邮箱保持一致，这样提交记录能正确关联到 Gitee 账户。不过 Gitee 也支持在账户设置中手动关联多个邮箱，所以即使之前用别的邮箱提交过，也不用担心关联不上。

想查看当前配置时执行：

bash复制git config --list

会列出所有生效的配置项，包括全局配置和仓库本地配置。配置文件分别是 ~/.gitconfig（全局）和 .git/config（仓库内）。

2.3 SSH 密钥生成的完整过程

SSH 密钥的本质是一对公钥和私钥。公钥放在 Gitee 账户上，相当于一把锁；私钥留在本地电脑上，相当于钥匙。推送时 Gitee 用公钥验证持有私钥的就是你本人。这个机制保证了免密操作的安全性，不需要在网络上传送密码。

在 Git Bash 中执行以下命令生成密钥：

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

参数说明：-t rsa 指定密钥类型为 RSA，-b 4096 指定密钥长度为 4096 位（比默认的 2048 位更安全），-C 是备注信息，便于识别密钥用途。

执行后会有三次交互提示：

• 第一次问密钥文件的保存位置，直接回车使用默认路径 C:\Users\你的用户名\.ssh\id_rsa
• 第二次和第三次要求输入私钥的密码短语（passphrase），可以直接回车留空。留空意味着私钥文件本身不加密，持有私钥文件的人就能直接使用。如果输入了密码短语，每次使用私钥时需要输入密码，安全性更高。开发机上通常建议留空，方便推送；公司电脑或共享电脑可以设置密码短语。

生成完成后，在 .ssh 目录下会得到两个文件：id_rsa 是私钥，id_rsa.pub 是公钥。公钥的内容需要添加到 Gitee。

查看公钥内容的方式：

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

复制输出的完整内容，打开 Gitee 网站，进入右上角头像菜单中的“设置”，找到“安全设置”里的“SSH 公钥”，粘贴公钥内容并保存。标题可以随便填，一般填电脑名称或使用场景，方便日后管理。

添加完后可以在 Git Bash 中验证是否连通：

bash复制ssh -T git@gitee.com

首次连接会提示是否确认主机的指纹信息，输入 yes 回车即可。如果看到类似 Hi xxx! You've successfully authenticated, but GITEE.COM does not provide shell access. 的输出，说明 SSH 配置成功。

2.4 Gitee 上创建仓库的选项建议

在 Gitee 网站上点击“新建仓库”，要填的内容主要有仓库名称、路径（URL 后缀）、开源许可证、初始化设置等。

仓库名称和路径可以用中文，但建议使用英文或拼音，避免命令行操作时出现编码问题。开源许可证按你的实际需求选择：如果想做开源项目，可以从 MIT、Apache 2.0、GPL 中选择适合自己的；如果只是自己的私有项目，选“不使用许可证”或者直接建私有仓库即可。

初始化设置中的“是否初始化仓库”“选择分支模型”“添加 .gitignore”等选项，建议按需处理。如果你打算完全从本地推送代码上去，可以不勾选“初始化仓库”，这样远程仓库就是一个空仓库，后面通过本地关联推送。如果你希望远程仓库直接生成 README 文件作为初始内容，可以勾选初始化选项。两种方式都是常用做法，区别只在于第一个推送时是否需要处理“远程已有内容”的合并问题。

我个人的经验是：在 Gitee 上创建一个空的仓库，不在线初始化任何文件，然后从本地推送上去。这样仓库历史完全由本地控制，不会出现远程有 README 而本地没有、导致第一次推送需要 pull 合并的麻烦。

3. 实操过程与核心环节实现

3.1 建立本地仓库并完成首次提交

以 Gitee 上创建的空仓库为例，在本地新建一个项目目录，或者进入已有的项目目录，打开 Git Bash，执行初始化命令：

bash复制git init

这会在当前目录下创建一个隐藏的 .git 文件夹，这就是本地仓库的核心。关注一下这行命令的输出，如果提示 Initialized empty Git repository，说明初始化成功。

然后创建或修改项目文件。比如新项目通常会先创建一个 README.md 文件，介绍项目用途。可以用任意文本编辑器编写，保存到项目目录下。

添加文件到暂存区并提交：

bash复制git add README.md
git commit -m "初始化项目：添加README"

git add 将文件从工作区加入暂存区，git commit 把暂存区的内容正式记录到版本历史中，-m 参数后面的字符串是提交说明。这里特别注意：提交说明最好写清楚这次变更的目的，而不是写一堆废话。后面代码多了以后，清晰的提交历史能在回溯问题时节省大量时间。

如果想一次添加所有变更文件，可以用 git add . 或 git add -A。但要注意，如果项目目录里已经有不需要纳入版本控制的文件（比如编译缓存、临时文件），最好在首次提交前就配置好 .gitignore 文件，否则这些文件会被跟踪，时间长了仓库会变得臃肿。Gitee 创建仓库时也支持自动生成 .gitignore 模板，选择你项目对应的语言或框架即可。

3.2 关联远程仓库并完成首次推送

在 Gitee 仓库主页找到仓库地址。点击“克隆/下载”按钮，选择 SSH 方式，地址类似 git@gitee.com:你的用户名/仓库名.git。

在本地仓库目录中执行：

bash复制git remote add origin git@gitee.com:你的用户名/仓库名.git

origin 是远程仓库的默认别名，你可以理解为给这段长长的地址起的短名字。后续推送、拉取时都用 origin 代替完整地址。

然后执行推送：

bash复制git push -u origin master

如果创建仓库时选择的默认分支是 main，就把 master 换成 main。-u 参数的作用是建立本地分支和远程分支的关联，之后再次推送时可以简化为 git push。

首次推送后，Gitee 仓库里就能看到刚才提交的文件了。到这里，本地仓库和远程仓库的通道已经打通，之后每次修改代码后，只需要执行 git add、git commit、git push 三步操作，就能把最新代码同步到 Gitee。

3.3 日常迭代的核心循环

日常开发中的 Git 操作循环非常简单，本质上就是“改代码 -> 暂存 -> 提交 -> 推送”。

假设你修改了项目中的一个文件，可以先查看当前状态：

bash复制git status

输出会显示哪些文件被修改了、哪些是新文件、哪些已经进入暂存区。养成每次提交前先看 status 的习惯，能避免把不相关的文件误提交进去。

确认无误后执行提交：

bash复制git add .
git commit -m "修改了XXX功能"
git push

如果之前已经用 -u 关联过远程仓库，直接 git push 就行。推送的机制是把本地提交历史同步到远程分支，远程分支的指针移动到最新的提交上。如果远程分支上存在本地没有的提交，Git 会拒绝推送并提示先 pull，这是保护机制，避免覆盖别人的代码。遇到这种情况，先执行 git pull 拉取远程变更，解决冲突后再推送。

3.4 免密失效的排查与修复

SSH 免密配置完成后，理论上推送是不需要密码的。但偶尔会出现一个问题：创建 SSH 密钥时设置了 passphrase（密码短语），导致每次推送仍然提示输入密码短语。如果觉得每次都输入太啰嗦，可以用 ssh-agent 会话缓存解决：

bash复制eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_rsa

第一条命令启动 ssh-agent 代理进程，第二条命令把私钥添加到代理的缓存中。执行后，当前终端会话内的推送不再要求输入密码短语。如果想在 Git Bash 每次打开时自动加载，可以把这两行命令加入 ~/.bashrc 配置文件。

另外，如果你把私钥文件名改过，需要让 Git 知道去读取哪个私钥文件。在 ~/.ssh/ 目录下创建 config 文件，写入：

code复制Host gitee.com
  HostName gitee.com
  User git
  IdentityFile ~/.ssh/你的私钥文件名

保存后，Git 会按配置读取指定私钥。

3.5 分支管理与提交规范实操

团队协作或稍微正式一点的项目，都不会直接在主分支上开发。常用的模式是：从主分支切出一个功能分支，在分支上开发，完成后合并回主分支。

常用命令：

bash复制git branch                 # 查看本地分支列表
git checkout -b dev        # 新建并切换到 dev 分支
git switch -c dev          # Git 2.23+ 推荐写法
git merge dev              # 将 dev 分支合并到当前分支

分支命名建议遵循一定的规范，Gitee 官方推荐的分支模型包括 master/main（主分支）、develop（开发分支）、feature/xxx（功能分支）、release/xxx（发布分支）、hotfix/xxx（紧急修复分支）。这样命名的好处是看到分支名就知道它的用途和生命周期，避免混乱。

提交规范方面，主流的是 Conventional Commits（约定式提交），格式为：

code复制type(scope): subject

type 是提交类型，常见的有 feat（新功能）、fix（修复）、docs（文档）、style（格式）、refactor（重构）、test（测试）、chore（构建或辅助工具变动）。scope 是可选的影响范围，subject 是简洁的描述。

举例：

• feat(user): 新增用户注册功能
• fix(cart): 修复购物车数量为负的问题
• docs(readme): 更新部署说明

这种规范的好处不止是好看，它还能直接配合工具生成 CHANGELOG、自动决定版本号，团队协作时能快速定位某次提交对应什么改动。

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

4.1 推送时报错 Could not read Username：身份验证怎么破

如果使用 HTTPS 方式推送且没有配置凭据，Git 会提示输入用户名和密码。如果没有正确输入 Gitee 的用户名或私人令牌，或者输入的是 Gitee 登录密码，会一直报身份验证失败。

Gitee 出于安全考虑，现在要求使用私人令牌（Personal Access Token）代替登录密码进行 HTTPS 推送。在 Gitee 设置 -> 安全设置 -> 私人令牌中生成一个令牌，把它当作密码使用即可。

如果是 SSH 方式遇到这个问题，通常是远程地址写错了，写成了 HTTPS 地址，或者 SSH 公钥没有正确添加到 Gitee。检查一下 git remote -v 输出的地址格式，如果是 https://gitee.com/... 开头，说明当前使用的是 HTTPS 方式。

4.2 Gitee 克隆报错 git did not exit cleanly 的源头排查

这个报错通常出现在 IDE（如 VS Code）中执行克隆操作时。可能的原因有三个：

一是仓库地址不合法，检查地址是否写错、仓库是否公开或你是否有访问权限。二是本地网络环境无法正常访问 Gitee，可以试用浏览器访问 Gitee 网站确认连通性。三是 SSH 密钥配置不正确，导致 SSH 握手失败。

在 Git Bash 中执行同一个克隆命令，看具体的错误输出。比如 Could not resolve host 说明域名解析异常，Permission denied (publickey) 说明身份验证失败。命令行输出比 IDE 弹窗提供的错误信息详细得多，从命令行排查是最高效的方式。

4.3 “用撤销上次提交可以回滚吗”：万用回滚方案

热词里提到的这个问题很典型：在 VS Code 的 Git 面板里看到“撤销上次提交”按钮，想知道能不能用它回滚代码。

答案是：可以，但要区分两种情况。

第一种情况，提交尚未推送到远程仓库，只在本地。这时点击“撤销上次提交”（git reset --soft HEAD^）会撤销最近一次提交，但保留文件的修改内容，改动仍然留在暂存区或工作区。这是一种安全的操作，可以实现回滚且不丢失代码。

第二种情况，提交已经推送到远程仓库。这时不建议直接 reset，因为本地和远程的历史会产生分叉，下次推送会被拒绝。更稳妥的做法是使用 git revert，它会在历史中新增一条反向提交，把代码状态恢复到之前的样子，同时保留原有提交记录。

bash复制git revert HEAD

上面的命令会生成一个撤销最近一次提交的新提交。git revert 的好处是不改变历史记录，适合对已推送的提交执行。

如果确实想改写已经推送的历史（比如提交信息写错了），可以用 git reset --hard 配合 git push --force，但这会覆盖远程历史，如果仓库有其他人使用，会造成混乱。强制推送属于危险操作，能用 revert 解决就优先用 revert。

4.4 Git 输出乱码的常见原因与修复方法

命令行里 Git 输出中文出现乱码，通常是终端编码与 Git 输出编码不一致导致的。Windows 下 Git Bash 默认使用 UTF-8，而部分中文 Windows 环境下的系统区域设置仍为 GBK。

查看当前 Git 是否启用了配额路径显示：

bash复制git config --global core.quotepath false

将 core.quotepath 设为 false 后，Git 输出文件名时会直接显示中文而不是转义后的八进制序列。这个改动对已提交的文件名显示立竿见影。

如果 Git 提交信息本身有中文，还需要确保终端能正常显示中文，以及提交信息以 UTF-8 编码写入。Git Bash 通常默认没问题，如果使用 Windows Terminal 或 VS Code 终端，一般也默认 UTF-8。CMD 的话可以先执行 chcp 65001 切换代码页，然后重启终端。

4.5 新手常见操作误区整理

这里整理几个我在指导新人时经常遇到的操作误区，每一个都踩过坑，希望你能避开。

误区一：git add . 无脑添加所有文件，也不看 .gitignore 是否配置。结果是把 node_modules、bin、obj、out 之类的目录提交进仓库，仓库体积越来越大，克隆越来越慢。正确做法是先配置 .gitignore，每次提交前用 git status 检查已暂存的文件列表。

误区二：提交信息写得毫无意义，比如 update、fix、test，隔一周再回来看根本不知道改了啥。提交信息是给未来的自己和其他协作者看的，多写几个字说明变更原因，收益远大于成本。

误区三：在不了解 git reset --hard 后果的情况下执行了它，结果丢失了大量未提交的修改。--hard 会同时重置暂存区和工作区，未提交的修改会彻底消失。不确定时先备份文件，或者仅仅使用 git reset --soft 回退到提交前的状态。

误区四：在本地修改了代码但忘记 pull 远程最新代码就直接 push，导致冲突。虽然不是大问题，但频繁冲突会消耗时间。建议在每次开始开发前先 git pull，保持本地分支与远程同步。

误区五：把 Gitee 的 HTTPS 地址和 SSH 地址混用。远程地址关联后很少改，但一旦误用，推送时会要求输入账号密码，而这账号密码可能已经忘了。检查方式是在仓库目录执行 git remote -v，地址前缀是 git@ 就是 SSH 方式。

4.6 Gitee Pages 托管页面现状说明

关于 Gitee Pages，这是一个静态页面托管功能，可以把仓库中的网页文件发布成一个可访问的网站。如果之前能正常使用但突然不行了，先确认服务状态和新的使用规则，Gitee 官方会在页面上说明。另外仓库必须是公开的才能使用 Pages 服务，私有仓库无法开启。我通常用这个功能托管一些前端演示页或个人项目展示页，确实方便，但依赖平台的服务状态，重要项目建议本地保留完整备份。

5. 配置细节与扩展技巧

5.1 Gitee 仓库的开源许可证选择

建仓库时，如果决定开源，会面临一个选择：MIT、Apache 2.0、GPL、BSD 哪个更合适？我的建议是：

• MIT 和 BSD：最宽松，别人可以用你的代码做几乎任何事，只需保留版权声明。适用于你希望代码被广泛使用的情况。我个人的多个工具类项目用的是 MIT，不限制使用场景，省心。
• Apache 2.0：比 MIT 多了一些条款，包括专利授权和对贡献者的保护。适合企业级项目或与专利相关的项目。如果你在公司的开源项目，通常会选这个。
• GPL v3：要求使用者在分发修改后的代码时也必须以 GPL 协议开源。适合你希望后续使用者也开源自己改动的项目。开源界的理念保护派会选择它。
• 如果只是把代码放上去留存，不打算让别人使用，完全可以选择“不使用许可证”，在仓库 README 中说明保留所有权利即可。

5.2 .gitignore 的编写逻辑

.gitignore 是 Git 仓库里非常重要但经常被忽略的文件。它的作用是告诉 Git 哪些文件不要跟踪。常见的规则：

gitignore复制# 编译产物
*.class
*.o
dist/
build/

# 依赖目录
node_modules/
vendor/

# 环境配置
.env
.env.local

# IDE 配置
.idea/
.vscode/

# 系统文件
.DS_Store
Thumbs.db

规则语法并不复杂：* 匹配任意字符，/ 在开头表示相对于项目根目录，在结尾表示只匹配目录。! 表示排除（重新包含）。比如：

gitignore复制# 忽略所有 .log 文件
*.log
# 但保留 important.log
!important.log

编写 .gitignore 的最实用技巧是：如果某个文件已经被误提交了，.gitignore 不会让它自动停止被跟踪，因为 Git 是根据文件是否已被跟踪来决定的。你需要先执行 git rm --cached 文件名 将其从版本控制中移除，再提交一次，之后它才会遵守 .gitignore 规则。

5.3 Gitee 的分支命名建议

分支命名的规范直接影响多人协作的效率。推荐一套简单实用的原则：

• 主分支：master 或 main，始终保留可发布状态。
• 开发分支：develop，日常开发集成分支。
• 功能分支：feature/功能简述，比如 feature/login、feature/pay。
• 修复分支：fix/问题简述，比如 fix/cart-bug。
• 发布分支：release/版本号，比如 release/v1.2.0。

这套命名规则的优势是，结合 Gitee 的 PR/MR 流程，分支名能直接告诉审查者这个分支的目的。实际上很多团队也是这么用的，虽然不是强制规范，但能减少沟通成本。用 git branch 查看长度和可读性，过长的名字要精简，否则输入命令时容易出错。

5.4 在 VS Code 里使用 Git 的高效姿势

虽然命令行操作是基本功，但日常开发中我经常在 VS Code 里直接用 Git 面板。左侧栏的源代码管理图标，查看变更文件、输入提交信息、点击提交、推送，一气呵成，效率很高。

注意事项：VS Code 的 Git 操作底层调用的还是命令行 Git，所以之前配置的所有内容（用户信息、SSH 密钥、提交规范）在这里同样生效。如果在 VS Code 里遇到 Git 报错，大概率是同一套配置问题，去 Git Bash 里排查能更快找到原因。

VS Code 的源代码管理面板支持查看文件差异，可以看到修改前后的具体内容，比在命令行用 git diff 直观得多。在提交前先检查一下 diff 是一个好习惯，能避免把调试代码和测试输出误提交进去。

5.5 撤销、回滚的完整命令速查

整理了日常最常用的撤销/回滚场景与对应命令：

标注一下：HEAD^ 表示最近一次提交的父提交，HEAD~2 表示最近两次提交之前的版本，以此类推。在不确定参数含义之前，尽量先查帮助文档，git help 命令名 会打开本地帮助页面。

6. 一些实在的建议

写了这么多，最后分享几个我在实际使用中领会到的东西。

第一，Git 的学习曲线不在命令多，而在理解工作区、暂存区、本地仓库、远程仓库这四个概念的关系。把这四个概念想清楚，绝大多数命令都能自然推理出来。我给同事讲的时候经常用一个类比：工作区是办公桌，暂存区是整理箱，本地仓库是文件柜，远程仓库是公司档案室。办公桌上杂乱的文件先放进整理箱，确认没问题后再归入文件柜，定期把需要共享的档案送到档案室。文件丢失时你就知道应该去哪一层找。

第二，遇到 Git 问题时，第一步永远是看完整报错信息。新手容易只看到“报错了”三个字，但真相就藏在具体文本里。复制报错内容搜索，通常能快速找到解决方案。

第三，提交规范不要等团队大了再定，从现在开始就按规范写提交信息、按规范命名分支，将来需要协作时完全没有迁移成本。习惯的养成越早越轻松。

第四，Gitee 作为一个国内平台，在国内网络环境下访问稳定，对新人友好，文档也全，拿它练手完全够用。等熟悉了这套流程，GitHub 和 GitLab 的使用逻辑是类似的，切换成本几乎为零。

本篇内容基本上把 Windows + Gitee 的完整流程和常见的坑都覆盖了，你可以保存下来，实际操作时对照着一步步来。如果在配置过程中遇到这里没写到的问题，先从报错信息出发排查，再看是不是环境差异导致的，多半能自己找出答案。