VS Code图形化Git入门：零基础掌握版本控制

我以前带过不少刚入门的朋友用 VS Code，发现大家对 Git 的态度普遍是“知道它很重要，但一打开那个源码管理面板就发怵”。这个心态我太理解了。你花了一下午把项目搭起来，改了一堆代码，然后突然意识到：我改的什么东西被 Git 跟踪了？这个蓝色的数字 12 是什么意思？我提交了是不是就会被别人看到？我的代码会不会丢？这篇文章就是来把这些问号一个个拉直的。我会严格站在一个零基础小白的视角，从为什么需要 Git、怎么装环境、怎么提交、怎么推送、怎么处理分支和冲突，到那些让人血压升高的报错到底在说什么，全部走一遍。文章里所有操作都在 VS Code 的图形界面里完成，不需要你背命令，但我会在每个环节告诉你背后发生了什么，这样你之后想转命令行，基础也已经在手上了。

1. 先想明白：VS Code 和 Git 各管哪摊事，为什么要绑在一起用

很多新手容易把 VS Code 和 Git 混为一谈，以为装了编辑器就等于有了版本管理。这两样东西其实是完全不同的工具，搞清楚它们的分工，后面所有操作才不会糊里糊涂。

1.1 没有版本管理时，你的项目文件夹通常长什么样

先回忆一下最原始的操作方式。你需要改一个项目，又怕改坏了，于是右键复制一份文件夹，命名为项目_最终版。过了几天要再改，又复制一份，叫项目_最终版2、项目_真最终版、项目_绝对不改了。等到某天要回退到昨天下午那个版本，你得打开四五个文件夹对比，崩溃只是时间问题。

如果你经历过这种“文件夹复制大法”，那你已经天然理解 Git 要解决的核心问题：它把你整个项目的每一次状态都拍成快照，存在一个特殊的地方，随时可以回去。这不是什么高深理论，就是给项目装了一个“时光机”。

1.2 Git 替你解决的三个核心痛点：回溯、协作、备份

第一是回溯。你改了一天代码，发现方向错了，想回到今天早上那个能正常运行的版本。没有 Git 就只能靠记忆手动反向改，有 Git 就一行操作的事，整个项目恢复到那个状态。

第二是协作。你和同事同时改同一个项目，他加了登录模块，你加了支付模块。没有 Git，最常见的做法是把代码打包发来发去，然后互相覆盖。有 Git 之后，每个人在本地各有完整历史，最后把改动合并到一起即可。Git 会自动尝试整合，只有两人改了同一行时它没法判断，才会请你来做决定。

第三是备份。你提交代码后推送到远程仓库，意味着代码至少存在你的电脑和一个远程服务器上。本地硬盘挂了，换台电脑继续干活，代码一点不丢。

这三件事，几乎覆盖了团队开发和独立开发中 90% 的痛点。所以 Git 不是大厂专属，一个人开发也应该用。

1.3 为什么新手不要急着学命令行，先用 VS Code 的图形化 Git 面板

Git 本身是个命令行工具，在终端里敲git commit、git push是它的原生操作方式。但对零基础的人而言，命令行最大的问题是“没有反馈”，敲错一个单词，屏幕上全是英文报错，很容易当场劝退。

VS Code 内置了图形化的 Git 界面，点按钮就能完成大部分操作。我一般建议新手先在图形界面里把“呀，我改了代码、我要保存这个版本、我要传到远程”这套动作练熟，理解了流程，再回过头去学命令行，会发现命令行其实就是图形界面那些按钮的快捷方式，背起来也容易。

下面这张表可以帮你直观对比几条常见路线：

我个人的观点是：VS Code 面板负责让你“敢用”，命令行负责让你“用得深”。两样不冲突，都是从零到一很自然的路径。

2. 环境准备：把 Git 装对、把 VS Code 汉化、把两者接起来

这个阶段最容易被跳过，但恰恰是后面所有操作的地基。我见过太多人卡在“VS Code 里不显示 Git 图标”“克隆按钮是灰的”这类问题上，绝大多数都是安装环节出了岔子。

2.1 Windows 下安装 Git 的几个关键选项，别一路 Next 到底

安装 Git 本身没什么难度，去官网下载对应系统的安装包，双击运行即可。但安装过程中有几个选项，如果不知道含义直接照默认点，可能会给后面埋坑。

第一个是调整 PATH 环境变量。这一步默认选项是“Git from the command line and also from 3rd-party software”，意思是 Git 不止自己的工具，也会让 VS Code 等第三方软件找到它。这个选项保持默认就好。如果你选了第一个“仅使用 Git Bash”，VS Code 可能找不到 Git 的可执行文件，后面打开源码管理面板就会报错。

第二个是行结束符（Line Ending Conversions）。Windows 用CRLF表示换行，Linux 和 macOS 用LF。Git 默认的选项是“Checkout Windows-style, commit Unix-style line endings”，也就是你从仓库里拿到的文件是 Windows 风格，提交时自动转成 Unix 风格。这个默认值对团队项目来说通常是最保险的，不会因为换行符不同导致整个文件被标记成“改动”。个人用户如果完全不确定，保持默认即可。

第三个是选择 SSH 可执行文件。默认“Use bundled OpenSSH”即可，这是 Git 自带的，不用额外装东西。

安装完成后，打开终端（Win+R 输入 cmd 回车），输入git --version，看到类似git version 2.40.0.windows.1的输出，说明装好了。

提示：把git --version这种验证习惯养成，是新手摆脱“不知道环境是否正常”的第一招。

2.2 安装 VS Code 并配置中文界面

VS Code 的安装相对简单。官网下载安装包，一路 Next。安装时建议勾选“添加到 PATH”，这样后面在任何终端里都能直接敲code .打开当前目录，非常方便。

安装完成后打开 VS Code，默认是英文界面。对英文界面不习惯的人，第一步建议先汉化。点击左侧扩展图标（四个方块那个），在搜索框输入Chinese，找到“Chinese (Simplified) (简体中文) Language Pack for Visual Studio Code”，点击 Install 安装，然后重启 VS Code，界面就变成中文了。

注意一个细节：汉化包装完后，VS Code 右下角通常会弹一个提示框，问你是否切换界面语言并重启，直接点“Change Language and Restart”。如果没弹，可以按Ctrl+Shift+P，输入Configure Display Language，手动选择zh-cn。

2.3 验证 VS Code 已正确识别 Git

装完 Git 和 VS Code 后，需要在 VS Code 里确认它认识 Git。打开 VS Code，按Ctrl+Shift+P打开命令面板，输入Git: Enable或者直接看左侧活动栏，有没有出现一个带分支图标的“源代码管理”入口。

把鼠标停在这个图标上，看提示文字是“源代码管理”，点进去，应该能看到“源代码管理”面板。如果你的项目目录还没有 Git 初始化，它会显示一个大大的“打开文件夹”按钮和一个“初始化存储库”按钮。如果能看到“初始化存储库”，说明 VS Code 已经找到 Git 了。

如果这个面板一直提示“未找到 Git”，或者点任何操作都没反应，大概率是 VS Code 的 Git 路径配置有问题。检查文件 -> 首选项 -> 设置，搜索git.path，把它指向安装 Git 的cmd/git.exe路径，比如C:\Program Files\Git\bin\git.exe。这个手动配置一般很少用到，但报错时很管用。

2.4 补充：macOS 和 Linux 用户怎么装

macOS 用户可以在终端输入git命令，系统会提示你安装 Command Line Tools，直接确认即可；也可以先装 Homebrew，再brew install git。Linux 用户使用发行版自带的包管理器，Ubuntu/Debian 用sudo apt install git，CentOS/RHEL 用sudo yum install git。装了之后同样用git --version验证。

3. 提交前先把这些概念弄懂：三个区域＋你的开发者签名

很多人在 VS Code 里就算找不到按钮，也能瞎点完成一次提交。但如果不理解 Git 的三个区域，后面遇到“我明明提交了怎么推送不了”“为什么这个文件一直显示改动”时，会完全抓瞎。这一节是全文最重要的理论基础，我尽量讲得接地气。

3.1 工作区、暂存区、版本库：用买菜流程理解

Git 里有三个位置，必须分清楚。

工作区（Working Directory）是你电脑里看到的项目文件夹，你在这里写代码、改文件。所有改动最初都发生在这里。

暂存区（Staging Area / Index）是一个中间地带。你可以把文件先“选中”，告诉 Git“这些文件我觉得值得保存”，但还没正式形成版本。

版本库（Repository）是 Git 存快照的地方。一次提交（commit）就是把暂存区的内容正式记录成一个版本，存进版本库。

用买菜来类比：工作区是整个超市，你逛的时候看了很多东西；暂存区是购物车，你把想买的东西放进去；结账付款是提交，付完钱之后这批东西才真正归你所有。对应到 Git：你修改文件是“逛超市”，点击“暂存更改”是“放进购物车”，点击“提交”是“付钱”。

这个类比能解释清楚一个很常见的问题：为什么我提交了，远程仓库还没变？因为你只是在本地“付钱”，还没把货寄出去。寄货对应的是“推送（push）”，这一步我们下一节讲。

3.2 配置用户名和邮箱：每个提交都要盖的“章”

在第一次提交之前，Git 要求你必须有一个“签名”，也就是提交者信息。它不会验证这个邮箱是不是真的，但所有历史记录里都会带上这个名字和邮箱，之后如果代码出了问题，别人通过它就能找到你。

配置命令是：

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

--global表示全局生效，也就是这台电脑上所有项目都默认使用这个身份。如果你在未来某个项目里想用不同的身份，可以在那个项目的目录里去掉--global再配置一次，这个叫“仓库级配置”，它会覆盖全局配置。

配完之后可以验证：

git config --global --list

它会输出你设置的两项内容。到这里，你的“开发者签名”就准备好了。

3.3 VS Code 源码管理面板里的几个开关

安装完 Git 并打开项目后，VS Code 左侧的源代码管理面板会显示所有当前有改动的文件。面板顶部有几个设置图标，里面有重要的选项。

一个是自动暂存（Git: Auto Staging）。开启后，你保存文件时不需要手动点“暂存更改”，VS Code 会自动把它放入暂存区。对新手来说这个功能很省事，但要注意它牺牲了对“哪些文件进入本次提交”的精细控制。我建议刚开始可以开，等后面习惯了手动暂存，再把它关掉。

另一个是Git: Post Commit Command，它决定提交完成后做什么。你可以设置为“无操作”“拉取”“推送”“同步”等。新手建议保持默认“无操作”，也就是提交完自己去点推送，这样每一步在干什么你都清楚，不会出现“我明明提交了，怎么远程仓库还是旧的”。

3.4 第一次提交：把“当前状态”变成第一个版本

好，理论讲完，实际操作一下。

在 VS Code 里打开一个项目文件夹，左侧源代码管理面板会提示“初始化存储库”。点击它，VS Code 会在当前文件夹里创建一个隐藏的.git目录，这个目录就是 Git 仓库本体。需要提醒的是，注意区分“仓库”和“项目”的关系：项目是我们业务上说的代码集合，仓库是 Git 在背后维护的那个快照库。点击初始化成功之后，你在文件列表中新建的文件，都会在源代码管理面板里以字母U标记，意思是未跟踪（Untracked）。

把所有文件都“暂存更改”后，面板里会出现一个输入框，需要写“提交信息（commit message）”，也就是给这个版本起个名字，比如“初始化项目”。填好后点击右上角的勾，第一次提交就完成了。再打开终端输入：

git log --oneline

你会看到一条记录，比如a1b2c3d 初始化项目。这就是项目的第一个版本。

4. 在 VS Code 里走通第一次完整的“克隆-修改-提交-推送”

环境配好、概念初步建立之后，现在进入最核心的实战环节。这节会完整走一遍“从远程仓库拿代码 → 本地修改 → 提交 → 推回去”的流程，全程用 VS Code 面板操作。

4.1 用 VS Code 克隆远程仓库：两种打开方式

所谓克隆，就是把远程服务器上的某个仓库完整复制到本地。打开 VS Code，按下Ctrl+Shift+P，输入Git: Clone，回车，会要求你输入仓库地址。

这里解释一下仓库地址的两种常见形式。一种是 HTTPS 地址，形如https://xxx.com/用户名/仓库名.git，输入后它通常会要求你输入平台的账号密码或访问令牌。另一种是 SSH 地址，形如git@xxx.com:用户名/仓库名.git，前提是你已经配置过 SSH 密钥。对零基础用户来说，第一次建议直接使用 HTTPS 地址，流程最直接，后面再升级到 SSH 免密方式。

粘贴地址后，选择一个本地目录，VS Code 会开始克隆。完成后弹出提示是否打开这个仓库，点“打开”即可。整个过程不需要敲任何命令。

另一种方式是直接在源代码管理面板顶部选择“克隆存储库”，效果一样。

4.2 从修改文件到推送成功：四个状态逐个过

克隆下来的项目，第一步当然是改代码。以修改一个index.html文件为例：

打开文件，改动内容，保存。回到源代码管理面板，你会看到index.html出现在“更改”列表里，旁边有一个字母M，表示 Modified（已修改）。这是第一个状态。

点击index.html右边的“+”号，文件会移动到“暂存的更改”列表里，变成已暂存状态。这是第二个状态。如果你继续修改这个文件，它会在“暂存的更改”和“更改”两个列表里同时出现，分别代表“我已经暂存的那份改动”和“我暂存后又改的新的改动”。这个细节很多人第一次都懵，理解了就懂 Git 其实非常严谨。

接下来点击输入框，写下提交信息，比如“修改首页标题”，点击提交按钮，文件状态变为“已提交（Committed）”。这是第三个状态。此时改动已经存进了本地版本库，但远程仓库完全不知道。

最后一步是推送。点击源代码管理面板右上角的“推送”箭头按钮，VS Code 会问你配置远程仓库。因为是从克隆来的，远程地址已经在.git/config里配好了，直接确认推送即可。成功后，远程仓库就和你本地一致了。这是第四个状态。

4.3 远程仓库连接管理：弄清 remote、fetch 和 pull

如果你是先在本地创建了仓库，再想把它推到远程，最常问的问题是“我的远程地址从哪里配”和“怎么配”。这就要说到remote的概念。

先看一个常见流程：你在 Gitee、GitHub 或 GitLab 上新建了一个空仓库，它会给你一段提示，通常有两种方式：要么从命令行推送已有仓库，要么从命令行提交现有仓库。复制那几句命令，在 VS Code 的终端里执行。

git remote add origin https://xxx.com/用户名/仓库名.git git branch -M main git push -u origin main

这三句做什么，我用大白话拆开：

• 第一句：给“远程仓库地址”起个简称，叫origin。以后你说origin，Git 就知道去哪里找。
• 第二句：把当前分支重命名为main。现在创建仓库的默认分支普遍叫main，早期很多仓库用master，这一步是为了对齐。
• 第三句：-u的意思是“把本地 main 分支和远程 main 分支建立关联”，之后你直接点“推送”按钮，Git 就知道推到哪里。

这个流程弄明白后，再看拉取就会清晰很多。VS Code 面板里有两个容易混淆的动作：“拉取（Pull）”和“同步（Sync）”，菜单里还有“提取/拉取（Fetch）”。

• Fetch：只把远程仓库的最新信息下载到本地“缓存”里，不改动你正在编辑的文件。它的作用是让你知道远程有没有新提交。
• Pull：Fetch 之后再把远程的改动合并到当前分支。也就是说，Pull = Fetch + Merge。
• Sync / 同步：先执行一次拉取，再执行一次推送。如果你的本地有未推送的提交，它也会一并推上去。

对新手来说，我用得最多的是先“拉取”再“推送”，不建议直接用同步，因为同步的合并方向有时不受控，尤其在你还不太熟练的时候。

4.4 日常开发中“先拉再推”的习惯怎么养成

我很早就被同事教过一个习惯：每天开工坐下来的第一件事，先点一下“拉取”，而不是直接写代码。原因很简单：代码是团队协作的，别人可能已经推了新提交。你在旧版本上写了大半天代码，再想推送时，远程已经有新东西了，Git 要么拒绝你推送，要么给你制造一个本地无法预料的合并冲突。

所以养成固定节奏：开工先拉取 → 改代码 → 暂存 → 提交 → 推送前再拉取一次 → 推送。这个节奏就像出门前先看天气，花不了半分钟，但能避开一大半合作问题。

提示：如果“拉取”时提示“有冲突”，不要慌，直接看文件里出现的冲突标记，那个问题的处理我放在第 5 节详细讲。

5. 分支不是高手专属：改 bug、加功能都靠它

很多新手第一次听到“分支”两个字，潜意识里觉得那是团队主程才用的高级功能。其实不是。分支是 Git 里保护你日常工作、避免把半成品代码直接弄到主分支上的一种机制。理解它之后，你会改 bug 改得非常有底气。

5.1 分支的本质：给项目开一条“平行时间线”

假设你的项目现在在main分支上，一切运行正常。你想加一个新功能，可能要改很多文件，改到一半突然发现线上出了个 bug 要马上修。你不可能把半成品功能直接推到线上，也不可能把改了一半的文件全部撤销重新开始。

这时候分支就派上用场。你从main上分出一条新的时间线，叫feature-login。你在这条线上改什么都不会影响main。等你把功能做好、测完，再把它合并回main。中间如果线上有 bug，直接从干净的main上再拉一条hotfix分支，修完合并回去发布。两条线互不干扰。

用生活类比：main是家里常住的客厅，feature是你搭在院子里的临时工棚。你可以在工棚里随意折腾，弄脏了也不影响客厅。等一切都合适了，再把成品搬回客厅。

5.2 VS Code 中的分支操作：创建、切换、重命名、删除

在 VS Code 窗口左下角，你会看到当前分支的名字，比如main。点击它，顶部会弹出分支列表和操作选项。

• 创建分支：点击分支面板顶部的“创建分支”图标，输入名字，比如feature-login，回车。此时你已经在新分支上了。
• 切换分支：再次点击左下角分支名，列表里能看到所有本地分支。点击你想要的分支就能切换过去。
• 重命名分支：在分支列表里右键某个分支，选择“重命名分支”。
• 删除分支：分支合并完成后，可以右键删除本地分支。注意，当前正在使用的分支不能被删除，得先切走。

创建分支后你会发现，工作区里的文件内容和main上的一模一样，因为它是从当前位置复制出来的。你在feature-login上做修改、提交、推送，main完全无感知。

5.3 冲突从哪来：两个人改了同一行

即使没有分支，只要你和别人在同一个仓库里协作，“冲突”就迟早会发生。它的发生条件其实很苛刻：两边都修改了同一个文件的同一部分，且 Git 无法判断哪边才是你想要的。

打个比方：你和一个朋友分别改同一篇文章的同一句话。你改成“明天上午开会”，他改成“明天下午开会”。你把你的版本推上去，他也推他的版本。服务器拿到两份改动，发现都没有基于对方的新版本，这时候谁说了算？Git 只能请你们自己商量，于是报出冲突。

也可以理解为这是 Git 的诚实：它能自动合并大部分改动，比如你改了文件 A 第一段，他改了文件 A 第八段，它不吵不闹就合了。只有两个人同时踩到同一块地板，它才必须请你裁决。

5.4 在 VS Code 里解决合并冲突的完整过程

遇到冲突时，以拉取为例，Git 不会让你干净地拉下来。返回源代码管理面板，你会看到出现了一个“合并冲突”分组，列出有冲突的文件，文件名旁边通常有个C（Conflict）标记。

点开某个冲突文件，VS Code 会高亮显示冲突区域。编辑器上方会出现几个按钮，分别是“接受当前更改（Accept Current Change）”“接受传入更改（Accept Incoming Change）”“接受两者更改（Accept Both Changes）”等。同时文件里也会出现特殊的冲突标记：

<<<<<<< HEAD 这是我的版本写在这里 ======= 这是远程拉下来的版本写在这里 >>>>>>> 远程分支名

从<<<<<<< HEAD到=======之间是本地的改动，从=======到>>>>>>>是远程的改动。你要做的只有一件事：把这一整块区域改成你最终想要的版本，然后把<<<<<<<、=======、>>>>>>>这几行标记全部删掉。选择“接受当前更改”或“接受传入更改”是偷懒的办法，更推荐手动逐行判断，尤其在代码场景里，这两者很多时候不是二选一，而是需要融合。

处理完所有冲突文件后，点提交按钮。这时候不要用普通提交，Git 会提示你“完成合并（Complete the Merge）”。点击后相当于告诉 Git：这个冲突我已经处理好了，你把它合并成一个新提交，记录到历史里。

为了让你理解，我列一个冲突处理的自查顺序：

1. 看有哪些文件标了冲突，点进去。
2. 找冲突标记，理解两边各自在表达什么。
3. 决定保留哪边，或手动混合两边内容。
4. 删除所有冲突标记行。
5. 保存文件，点击“完成合并”提交。

5.5 合并后的善后与常用分支策略

合并完成、推送成功之后，我强烈建议顺手把已经合完的分支删掉。本地分支在 VS Code 分支列表里右键删除即可，远程分支也可以在侧边栏右键删除。分支太多会让仓库的蓝图很乱，下次切换时你都不知道哪天拉出来的线还在不在用。

这里也补充一个实际分工建议：小项目一个人开发，直接全在main上其实也没什么，但一旦要加重要功能，还是开分支。因为分支给你提供了一个安全阈值，就算功能开发的代码写得一塌糊涂，合并不过来丢弃掉重来就行，成本极低。

我见过不少新手不敢开分支，总觉得切来切去会把代码弄丢。其实 Git 分支的本质只是一行指向某个提交的“指针”，切分支完全不会丢代码，如果代码不见了，只可能是你在没提交的状态下切走了，或者手动删了却没察觉。只要你有提交记录，一切都可以找回。

6. 新手最容易翻车的几个现场，提前排一遍雷

最后这一章，来自我见到的各种真实踩坑。这部分不按章节顺序讲，而是按“我平时被问得最多的问题”来整理，每个都能单独救一次命。

6.1 每次提交/推送都让输入账号密码

当你用 HTTPS 克隆仓库后，每次推送都要求输入平台账号和密码，很快就能把人逼疯。解决办法有两种。

一种是配置凭据管理器，让系统记住你的登录状态：

git config --global credential.helper manager

设置后，第一次推送输入一次账号和访问令牌（注意很多平台现在不再直接支持密码，需要用你在个人设置里生成的个人访问令牌），之后就不用反复输入了。这是最无痛的方法，Windows 上配置好后，凭据会存在系统的“凭据管理器”里。

另一种是配置 SSH 密钥。原理是你在本机生成一对密钥，把公钥放到你的代码托管平台账号里，之后 Git 通过 SSH 协议连接时，服务器可以确认“这个请求确实来自你的电脑”，从而免密操作。生成方式是打开终端：

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

一路回车，默认保存路径即可。然后打开公钥文件（默认在用户目录的.ssh/id_ed25519.pub），复制全部内容，添加到代码托管平台的 SSH keys 设置中。之后克隆地址记得选 SSH 地址，就不再需要密码了。

新手我建议先走凭据管理器，等对 Git 更熟悉了再换 SSH 密钥。

6.2 commit 写错了或者漏了文件，怎么改

人有失手，马有失蹄。提交信息打错字很正常。如果你已经提交但还没有推送，可以用：

git commit --amend

这会修改最近一次提交的信息，同时把当前暂存区里的改动也并入这次提交。举个例子，你提交时漏了一个文件，就先把漏掉的文件“暂存更改”，然后执行git commit --amend，它会把暂存的文件和原提交合并成一个新的提交，历史看起来就像你想加的文件本来就在里面一样。

注意，--amend只适合提交还没推送的情况。如果已经推送了，就不再建议改了，因为改动历史会影响协作的其他人。已经推送的提交最好是通过新的提交去修正。

6.3 把 node_modules 之类的东西传上去了，怎么办

这个问题出现的频率极高。对于前端项目，node_modules这个文件夹动辄几百 MB，一旦被提交进仓库，后续每次克隆都极其痛苦。

正确做法是提前用.gitignore文件把它排除在外。在项目根目录新建.gitignore，写入：

node_modules/ dist/ .DS_Store

这些路径代表的含义是“让 Git 忽略 node_modules 文件夹、 dist 构建产物文件夹和 macOS 下的系统文件”。如果你是在创建项目初期就加上，后面一切正常。

如果不幸已经传上去了，处理方式稍微复杂：

git rm -r --cached node_modules

--cached表示只在版本库里移除该路径，不动你本地实际文件。执行完提交推送后，远程仓库里的node_modules就会被删除，但你本地的文件依然存在。之后它又会出现在源代码管理面板的“更改”列表里，只要.gitignore已经写好，下一次提交后它就会从 Git 的追踪范围里彻底消失。

6.4 pull 时提示冲突，我该选哪一个

第 5 节已经讲了冲突标记和解决步骤，这里补充几个更具体的判断角度。

如果你看到冲突区域，其中一个版本是你完全不认识的新代码，那么大概率是同事新推的功能，你自己没动过这块，这时候“接受传入更改”通常是安全的。如果两边代码看起来都眼熟，都有你刚改过的痕迹，那就必须逐行比对，不能图省事。我见过最普遍的错误是，新手为了快点解决冲突，直接选了“接受当前更改”，把同事的新代码覆盖掉，最后推上去把别人的功能弄没了。

解决冲突不是越快越好，而是要谨慎合并逻辑。它的本质不是“二选一”，而是“把两边都合理保留下来”。

6.5 误提交、误丢弃、误删分支的补救

误提交这种东西，人人都遇到。如果你只是提交错了信息，用上面说的--amend就好。如果你的提交内容完全错了，想撤销这个提交但保留文件改动，用：

git reset --soft HEAD~1

HEAD~1表示“回到上一次提交的位置”，--soft表示“保留所有改动在暂存区”。相当于你安全地退一步，让一切回到未提交的状态。

如果你把分支删了，发现代码在某条分支上没合并，也别慌。只要你知道那条分支最后一次提交的哈希值，在分支列表里点“创建分支”，输入那个哈希值，分支就从亡灵状态里被拉了回来。几乎所有 Git 数据在你清理（GC）之前都是可恢复的，所谓“删掉的代码”很多时候只是换了种存在方式。

6.6 常见报错速查表

最后整理一个我平时会被问到的报错对照表，遇到问题先排除这几类：

这些报错在图形界面里通常不会显示得那么完整，但在 VS Code 的“输出”面板里能看到更详细的信息。养成看输出面板的习惯，会让你的排错能力强出一大截。

最后分享一点我自己的体会。网上各种教程一上来就铺一堆命令，对初学者确实是劝退神器。我自己后来带人时，始终坚持“图形界面先跑通，再讲命令”的顺序，因为这个顺序尊重了人的认知节奏：先学会观察状态变化，再理解背后抽象规则。VS Code 的 Git 面板本质上就是把这些命令翻译成了按钮，你在面板里点过的每一个动作，都会被记录成一行终端命令，只是它替你把命令藏起来了。

等你用图形界面把一个完整的提交流程走顺十几次之后，可以试着打开 VS Code 的终端，输入git status看一看，你会发现屏幕上输出的内容你基本都能看懂了。到那时候，你再看别人的命令教程，就不再会觉得它们是乱码，而是一套你已经会讲的语言的书面形式。动手练永远比看教程快，找一个临时测试项目，在里面随便改、随便提交、随便删分支，Git 仓库就是你的游戏存档，玩坏了随时可以重启。