1. 为什么 Windows 用户搞 Git 绕不开这几件事
很多刚接触代码或文档协作的人都会碰到这个场景：文件改了几版，最后存成了"报告_最终版_v2_改改_真最终版.doc"，或者写代码写到一半想退回昨天的状态，结果只能靠 Ctrl+Z 一点一点撤销。等到多人一起改同一份文件时，问题就更明显——你改完我改，互相覆盖，最后谁都不知道哪份才是最全的。
Git 解决的就是这三个痛点：版本回退、并行协作、变更追溯。它是一个分布式的版本控制系统，最早是某位内核开发者为了解决 Linux 内核代码维护问题而写的，后来慢慢成了整个软件行业的事实标准。Windows 用户接触 Git 通常有两条路径：一是做开发时被 GitHub、GitLab 这类远程仓库逼着用，二是做文档管理、配置备份时主动引入。不管哪条路，安装和基础使用都是第一步。
这篇教程不打算从"版本控制的历史"这种教科书话术开头，直接用 Windows 系统的实际操作来走一遍：怎么装、怎么配置、怎么完成第一次提交、分支怎么用、以及我这些年用下来最容易踩的坑。适合完全零基础的人，也适合那些"装过 Git 但一直没搞明白到底在干嘛"的朋友。
2. 安装前必读：几种安装方式的选择逻辑
2.1 Git for Windows 是首选，但不是唯一选择
Windows 上没有原生的 Git 命令，所以必须先安装一个实现。最常见的是 Git for Windows，它包含三样东西：真正的 Git 核心程序、一个叫 Git Bash 的模拟终端、以及一个图形界面 Git GUI。官网地址是 git-scm.com，下载页面里会有 32 位和 64 位两个版本，现在绝大多数电脑都是 64 位，直接选 64-bit 就好。
除了 Git for Windows，还有几个替代选项。比如 GitHub 官方推出的 GitHub Desktop，它是纯图形化操作，适合完全不想敲命令的人；还有 SourceTree，也是图形界面。但我个人建议：从 Git for Windows 开始学。原因很简单，Git 的核心操作其实就那么十几条命令，图形界面虽然好看，但遇到合并冲突、分支变基这类复杂场景时，不懂底层命令会非常被动，甚至连报错信息都看不懂。
安装时有几个选项需要留意，我下面详细说。
2.2 安装向导里的关键选项，别一路 Next 到底
安装 Git for Windows 时默认路径是C:\Program Files\Git，一般不用改。到了 "Select Components" 这一步，默认选项基本够用，唯一我建议加勾的是 "Enable Git Credential Manager"——这玩意能帮你记住远程仓库的用户名密码或者令牌，省得每次推送都要重新输一遍。
下一步 "Adjusting your PATH environment" 是重中之重。三个选项分别是：
- "Use Git from Git Bash only"：只在 Git Bash 里能敲 git 命令，对系统环境变量没有任何影响，最保守。
- "Git from the command line and also from 3rd-party software"（推荐）：把 git.exe 加入系统 PATH，这样在 CMD、PowerShell、或者 Visual Studio Code 的终端里都能直接用
git命令。 - "Use Git and optional Unix tools from the Command Prompt"：会把一些 Unix 工具也加进 PATH，不推荐，容易和 Windows 自带的命令冲突。
再往下有一项 "Choose the default editor used by Git"。如果你装了 VS Code，这里可以直接选 "Use Visual Studio Code as Git's default editor"，没有的话选默认的 Vim 也行，但 Vim 对新手不太友好。后面我会介绍怎么改成别的编辑器。
还有一个关键选项 "Adjusting the name of the initial branch in new repositories"。老版本默认创建的分支叫master，近年 Git 社区基本都改用main了。如果安装时看到这个选项，直接选 "Override the default branch name for new repositories" 并填main，省得后面每次初始化仓库都要手动改名。
最后一步的配置项保持默认即可，安装完成后去 CMD 或 PowerShell 里敲一下：
git --version能看到版本号输出，就说明装好了。如果提示"无法识别"，重启一下终端或者注销重登一下，再不行就检查 PATH 有没有配置进去。
2.3 装完之后的第一件事：全局身份配置与换行符策略
Git 装好不等于能用，必须先告诉它"你是谁"。因为每一次提交（commit）都会记录作者信息，没配好这步，提交时要么报错，要么留下一串乱码身份。
打开 Git Bash，或任意终端，输入：
git config --global user.name "你的名字" git config --global user.email "你的邮箱"这里的邮箱不一定要真实存在，但如果之后要往 GitHub 推送代码，建议填写你注册 GitHub 用的邮箱，这样提交记录会自动关联到你的账号上。
配置完之后，Windows 用户还必须处理一个换行符的问题。Windows 里的文本换行符是 CRLF（回车+换行），而 Linux 和 macOS 用的是 LF（只有换行）。Git 默认会在检出代码时把 LF 转成 CRLF，提交时又把 CRLF 转回 LF，这个机制在大多数情况下是贴心的，但遇到编码混乱的文件时会造成告警，甚至让某些工具处理出现问题。
我的建议是执行：
git config --global core.autocrlf true这是 Windows 用户的经典推荐配置。如果团队项目的.gitattributes文件里已经明确了换行符规则，以项目配置为准。
3. 第一次初始化仓库与提交：搞懂工作区、暂存区、版本库
3.1 三种状态是本教程最重要的概念
不少新手把 Git 想象成"另存为"的终极版本，这种理解会走弯路。Git 的模型核心是三个区域：
- 工作区（working directory）：你电脑里看得见的那些文件，随便改。
- 暂存区（staging area / index）：改完之后用
git add把文件放进去，相当于勾选"准备提交"。 - 版本库（repository / .git 目录）：用
git commit把暂存区里的内容永久封存成一个版本。
这么说吧：工作区是你桌上的草稿纸，暂存区是待发文件筐，版本库是档案室。你可以改一堆草稿，挑其中一部分放进待发筐，再一次性地归档进档案室。这种"先暂存再提交"的设计是 Git 区别于很多老式版本控制系统的核心，必须理解，否则后面所有命令都在瞎按。
在 Windows 上验证这个模型很简单。找一个文件夹，比如D:\learn-git，右键选择 "Git Bash Here"，然后执行：
git init这个命令会创建一个隐藏的.git子目录，里面就是版本库。注意：.git目录不要手动删除或修改，否则仓库就废了。
再用git status查看状态：
git status它会告诉你当前在哪个分支（默认是 main）、工作区有没有未跟踪的文件。
3.2 一次完整的首次提交流程
现在我在这个文件夹里新建一个文本文件，比如hello.txt，写入几行内容。然后执行：
git status会看到hello.txt出现在 "Untracked files" 下面。这三个单词的意思是：Git 知道这个文件存在，但还没跟踪过它。
接着把它加入暂存区：
git add hello.txt如果有一堆文件要加，可以用git add .（当前目录全部加进去）或者git add src/。这一步操作完后再git status，文件会变成绿色，代表已暂存。
然后提交：
git commit -m "第一次提交：添加 hello.txt"-m后面是提交信息，一定要写清楚这次改了什么。提交完成后会显示一行统计信息，比如 "1 file changed, 1 insertion(+)"，这就说明版本库已经记录下这个快照了。
此时再执行git log，就能看到刚才的提交记录：
git log --oneline--oneline会压缩显示成一行，只显示提交哈希的前几位和提交信息。这里看到的哈希值就是该版本的唯一 ID，将来回滚时靠它定位。
3.3 修改和撤销：工作区、暂存区、版本库三者的联动
改文件是日常操作，我们把hello.txt里的内容改一行，然后看git status，会发现文件出现在 "Changes not staged for commit" 下面。这代表工作区的改动还没进入暂存区。
这时有两种选择：
- 想把改动提交上去：
git add hello.txt然后再git commit -m "更新内容"。 - 想让文件回到上一次提交的状态（放弃改动）：
git checkout -- hello.txt或新版命令git restore hello.txt。
如果文件已经git add进了暂存区，但突然反悔不想提交了，可以：
git reset HEAD hello.txt旧版命令是这样，新版 Git（2.23 之后）更推荐：
git restore --staged hello.txt这条命令只是把文件从暂存区移回工作区，文件本身的改动不会丢。我在实际教学中最常见的误区是：以为git reset会把改动也删掉，其实在未提交之前，Git 一般不会主动销毁你的文件改动。真要删掉工作区改动，得用git restore（不带--staged）或git checkout --，而且操作前最好确认你确实想放弃。
4. 分支：并行开发的精髓，也是新手最怕的地方
4.1 为什么必须理解分支
有人问："我就一个人写点东西，有必要用分支吗？"有必要。分支不是团队协作专属，它是"平行世界"机制——你可以在一个分支上实验新思路，不行就删掉，不影响主分支的稳定内容。
Git 创建分支的开销非常低，因为它本质上只是创建一个指向某个提交的指针。不像老式版本控制系统那样要复制整个文件树，Git 分支模型里切换只是在不同指针之间跳动。
用一个生活类比：主线（main）就像已经发出去的报纸，副线（feature）是你手里的草稿，草稿能随便改，等确认没问题了再"排版"并到报纸上。不弄脏主线，随时可以丢弃，这就是分支的价值。
4.2 分支的创建、切换、合并
基础命令只有几条：
git branch feature-a # 创建分支 git branch # 查看所有分支 git switch feature-a # 切换到 feature-a（新版） git checkout feature-a # 旧版切换语法，也依然有效如果你希望创建并立刻切换过去，直接：
git switch -c feature-a切到新分支后，你在这个分支里的所有提交都不会影响 main。在feature-a分支上做几次提交后，回到 main：
git switch main此时工作区会变回 main 最近一次提交的状态，你之前在 feature-a 里改的文件"消失"了。别慌，这是 Git 的机制——每个分支有各自独立的历史。切回 feature-a，文件又回来了。
当 feature-a 上的功能确认没问题，把它合并到 main：
git switch main git merge feature-aGit 会把 feature-a 上的提交记录整合到当前分支。如果两边改的是不同的文件，合并通常自动完成，不会问你任何问题。
如果两边改的是同一个文件的同一区域，就会出现合并冲突（conflict）。遇到冲突时 Git 会在文件里插入类似下面这样的标记：
<<<<<<< HEAD 当前分支的内容 ======= feature-a 分支的内容 >>>>>>> feature-a你需要手动打开文件，决定保留哪一份、删除哪些标记，然后保存、git add、git commit。冲突不是错误，是 Git 在跟你确认"我不确定你想要哪个结果"。我见过不少新手在冲突界面吓得不敢动，其实处理一次就明白：冲突标记只是提示两边的不同意见。
4.3 合并后我不推荐立刻删分支，除非你确认无误
分支合并完后：
git branch -d feature-a可以删掉这个分支。但我的习惯是不急着删，等远程仓库也确认合并了再删。本地分支很便宜，多留几天无妨。真要删没合并过的分支，得用-D强制删除，此时该分支上的提交如果没合回其他分支，会彻底丢——所以-D按下去之前，先想清楚。
5. 远程仓库：从本地到 GitHub/Gitee 的推送与拉取
5.1 SSH 还是 HTTPS：Windows 用户的连接方式选择
本地玩 Git 只能解决一半问题，另一半是远程协作。远程仓库相当于所有人都能访问的"公共版本库"，最常用的是 GitHub、GitLab，国内还有 Gitee。Windows 上连接远程仓库有两条路：
- HTTPS：每次推送要求输入用户名和密码（现在大多改用 Token），配置简单。
- SSH：生成密钥对，把公钥配到远程平台，之后不用每次输密码。
我推荐 SSH。虽然首次配置比 HTTPS 多几步，但一劳永逸。生成密钥的命令：
ssh-keygen -t ed25519 -C "你的邮箱"一路回车即可，默认生成到C:\Users\你的用户名\.ssh\id_ed25519.pub。这个.pub文件是公钥，可以随便给别人；私钥（id_ed25519）一定不要泄露。
用文本编辑器打开.pub文件，复制里面全部内容，到 GitHub 的 Settings → SSH and GPG keys → New SSH key 里粘贴保存；Gitee 则在设置里的"SSH公钥"入口粘贴。不同平台入口名称略有不同，但思路一致。
验证是否配置成功：
ssh -T git@github.com如果看到类似 "Hi 用户名! You've successfully authenticated" 的提示，说明通了。
5.2 推送到远程仓库的完整流程
我这里以 GitHub 建好一个空仓库（不要勾选"初始化 README"）为例。远程仓库建好后，它会给一段提示，通常是：
git remote add origin git@github.com:用户名/仓库名.git git branch -M main git push -u origin main解释一下：
git remote add origin 地址：把本地仓库和远程仓库建立关联，origin是这个远程仓库的默认别名。git branch -M main：把本地分支改名为 main（如果建仓库时默认分支就叫 main，可跳过）。git push -u origin main：把本地 main 分支推到远程，-u表示把 origin/main 设为当前分支的上游跟踪分支，之后直接敲git push就能推送。
以后每次提交完推送就两条命令：
git add . git commit -m "改动说明" git push如果是在多人协作项目中，推送前往往要先拉取别人的更新：
git pullgit pull本质上是git fetch+git merge。建议新手先把git fetch和git merge分开用几次，理解拉取和合并是两件事之后，再放心用git pull。
在我实际带过的学生里，最常遇到的推送失败情况是：远程仓库已有一些文件（比如其他人先推了）而本地没有，直接git push被拒绝。解决办法是先git pull origin main --rebase，把远程提交合到本地历史之上，再重新推送。这里用了--rebase而不是默认的 merge，是为了让提交历史更线性、更干净。
6. Windows 专属的坑：换行符、中文乱码、管理器冲突
6.1 换行符告警：CRLF 与 LF 的世纪之争
在 Windows 上拉取某些开源项目时，你可能看到一堆警告，例如：
warning: LF will be replaced by CRLF in somefile.txt这个提示不致命，但很烦人。前面我建议设core.autocrlf true，这个配置在大多数 Windows 场景下是对的。如果团队项目里已经有.gitattributes文件，则项目配置的优先级更高，里面会用类似* text=auto、*.ps1 text eol=crlf的规则显式声明每种文件用什么换行符。
如果克隆一个项目后，运行git status发现大量文件显示为 "modified" 但明明没改过，绝大多数情况就是换行符被 Git 自动转换了。修复思路为：先把本地改动暂存起来，再让 Git 按当前配置重新检出一遍：
git add . git status如果显示的还是"修改"状态，再看是不是行尾问题。更多时候，问题出现在编辑器里。在 VS Code 里可以点右下角的 "CRLF" 按钮切换当前文件的行尾风格，保持一致即可。团队场景下，统一用.gitattributes比每个人手动设置环境变量更可靠。
6.2 中文文件名/提交信息乱码：一种常见但能修的毛病
Windows 老版本 Git 在处理 UTF-8 编码的中文时，记录文件名和提交信息可能出现乱码。现象是：git status里中文文件名显示成"\346\265\213..."这样的转义形式，即八进制转义序列。
修法是在 Git Bash 里执行：
git config --global core.quotepath false这样中文文件名就能正常显示了。至于提交信息的乱码，多半是终端编码问题。Git Bash 本身是 UTF-8 终端，但 CMD/PowerShell 默认代码页可能是 GBK。建议在提交信息里直接用英文，或统一把终端切到 UTF-8 编码（PowerShell 窗口属性里有相关设置，也可用chcp 65001切换）。对我来说，最省心的做法就是代码提交信息用英文，原因不是崇洋，而是 Git 生态工具和日志渲染对英文支持最稳。
6.3 图形工具与系统右键菜单的配合
Git for Windows 安装完后，文件资源管理器右键会多出 "Git Bash Here" 和 "Git GUI Here" 两个选项。很多新手喜欢用 GUI，但 GUI 在分支冲突这种复杂场景下反而不直观。我的建议是：日常问题用命令行，想看可视化历史可以用git log --graph --oneline --all，或者开一个 VS Code 的 GitLens 插件看。
另外，Windows 上如果装了多个 Git 相关工具，比如旧版 TortoiseGit 和新版 Git for Windows 并存，有时会出现右键菜单混乱或者 PATH 里指向旧版的问题。遇到git --version和你预期版本不一致时，用：
where git查看当前实际调用的 git 路径，检查 PATH 环境变量里的顺序。这就是"看起来装了新版本，跑起来还是旧版本"的经典排查方法。
7. 让日常使用更顺手的习惯与命令
7.1 提交信息与颗粒度
Git 最容易被新手忽略的是提交信息的质量。很多人的提交信息是 "update"、"fix"、"xxx改"，过两周后回头翻 log，完全想不起来那次提交做了什么。我自己写字项目的提交信息会按这个格式：
- 第一行：类型（feat/fix/docs/style/refactor...）+ 一句话摘要，控制在 50 字内。
- 必要时空一行，写两三句细节说明。
比如：
feat: 添加用户登录页面的表单校验 - 增加手机号格式验证 - 修复邮箱必填项提示不消失的问题 - 补充对应的单元测试用例这样的信息对日后追溯、发布变更日志都有巨大帮助。
提交颗粒度上，我建议小步提交：完成一个独立小功能、修完一个 bug，就提交一次，不要攒一整天改动一次性 commit。小步提交能让git log清晰展示演进过程，更重要的是，将来用git bisect定位回归问题时，粒度越小越容易找到问题出在哪一次改动里。
7.2 用git diff在提交前检查改动
很多人直接git add .然后git commit，我强烈建议提交前先看一眼改动内容：
git diff # 查看工作区与暂存区的差异 git diff --cached # 查看暂存区与上次提交的差异特别是git add之后，用git diff --cached检查即将提交的内容，能避免把调试用的临时输出、密钥文件、乱七八糟的图片误提交进去。我见过不少人在提交后发现把.env密钥文件推到了远程仓库——如果已经推上去了，单纯删除再提交没用，历史记录里仍然有，需要重写历史或换密钥才能解决。这个教训代价很大，所以最好在一开始就用git status和git diff把关。
如果想从根上避免把无关文件加入暂存区，可以建一个.gitignore文件，比如：
node_modules/ dist/ *.log .env .DS_Store把不需要版本控制的目录和文件列进去，git status就会自动忽略它们。Windows 里如果之前已经提交过某些不该提交的文件，把它们从仓库删除并记录这次移除，之后.gitignore才会真正生效——Git 对"已被跟踪的文件"不理会.gitignore规则。
7.3 遇到不知所措时怎么自救
还有一类场景是操作到一半发现不对劲。面对 Git 的提示报错，先别慌。我的自查顺序是：
git status：看看当前在哪个分支、哪些文件被改动。git log --oneline -5：确认最近几次提交是什么。git reflog：很多新手不知道这个命令，它记录的是 HEAD 的所有移动历史。即使你用git reset把分支退到了过去，甚至误删了分支，只要 reflog 里还有记录，就能找回那个提交。
举个例子，你不小心执行了git reset --hard HEAD~2，相当于把分支回退到两次提交之前。想找回丢失的那两个提交？执行：
git reflog会看到一串历史，找到那两个提交的哈希值，然后：
git reset --hard 对应哈希就能恢复到误操作之前的状态。这是 Git 的后悔药机制，只要你还保留着.git目录，大部分误操作都可挽回。唯一救不回来的是工作区里未提交且被覆盖的改动，这个靠任何命令都救不了，所以才要小步提交、勤提交。
8. 我给新手的最终建议：用三个项目练熟这套流程
讲到这里，安装、配置、提交、分支、远程仓库、坑和自救都覆盖了。但看一百遍不如亲手跑一遍。我给初学者的建议是：分三个难度把流程各做一遍。
第一个项目：本地练习。新建一个纯文本文档的文件夹，git init后每天提交一次，坚持一周，观察git log的变化。
第二个项目：推到远程。注册一个 GitHub 账号，建一个空仓库，把上面的本地仓库推上去，再在网页上看看提交记录的样子。
第三个项目：模拟协作。在本地建两个文件夹，分别从同一个远程仓库克隆下来，在 A 文件夹里改文件并推送，在 B 文件夹里拉取，制造一次冲突再解决冲突。做完这一轮，你对 Git 的畏惧感基本就消失了。
最后分享一个我自己的体会：学 Git 最难的永远是前一个月的"别扭感"。它不像文件管理器那么直观，很多操作先要理解"指针""引用""暂存区"这些抽象概念，但只要熬过最初这段，Git 会成为你电脑上最离不开的工具之一。当初我花了一周才习惯git add和git commit这套节奏，如今每天几十次提交，早就成了肌肉记忆。字项目也好，代码项目也罢，把版本管理纳入日常习惯，到哪都能受益。
