VS Code Git 源代码管理使用教程

VS Code Git 源代码管理使用教程：看懂分支、提交记录和 Git History 按钮

这篇文章适合刚开始用 VS Code 管理 Git 代码的人。

你截图里看到的页面主要是 VS Code 的 Git History 视图。它不是 Git 本身，而是把 Git 的提交记录、分支关系、常用操作用图形界面展示出来。看起来按钮很多，其实核心就一句话：Git 是在记录“谁在什么时候改了什么”，分支就是不同的开发路线。

一、先用大白话理解 Git 在干什么

我们平时写代码，大概会经历这几件事：

  1. 改代码。
  2. 看看自己改了哪些文件。
  3. 把确认要提交的文件放进暂存区。
  4. 写一句提交说明。
  5. 提交到本地 Git 仓库。
  6. 推送到远程仓库，比如 GitLab、GitHub。

Git 可以理解成一个“代码存档系统”：

工作区：你正在编辑的文件
暂存区：你准备放进下一次提交的文件
本地仓库：你电脑里的提交记录
远程仓库：公司 GitLab / GitHub 上的提交记录

最常见的一条流程是：

改代码 -> 暂存 Stage -> 提交 Commit -> 推送 Push

如果别人也改了代码，你还需要：

拉取 Pull -> 解决冲突 -> 再提交 / 推送

二、VS Code 左侧的“源代码管理”图标是做什么的

你截图左侧红框标出来的图标，是 VS Code 的“源代码管理”入口，也就是 Source Control。

点进去以后，通常会看到这些内容：

Changes / 更改：还没有提交的文件改动
Staged Changes / 暂存的更改：已经准备提交的改动
Commit message / 提交信息：这次改动的说明
Commit / 提交：把暂存区内容保存成一次 Git 记录
Sync / Push / Pull：和远程仓库同步

最常用的操作顺序是：

  1. 写代码。
  2. 点开源代码管理，看有哪些文件变了。
  3. 点文件可以查看差异，确认自己改了什么。
  4. 点文件右侧的 +，把文件加入暂存区。
  5. 在输入框里写提交说明，比如 fix: 修复课表显示问题。
  6. 点击提交。
  7. 点击推送，把本地提交推到远程仓库。

一句话总结：

VS Code 左侧源代码管理面板，主要用来处理“我当前改了什么”和“我要不要提交”。

而你截图中间那个 Git History 页面，主要用来看：

以前提交过什么、分支是怎么走的、某个提交在什么分支上。

三、先认识几个最重要的 Git 名词

1. Commit：一次提交

Commit 就是一次代码存档。

比如你修了一个 bug，然后提交了一次，那么 Git 就会生成一个提交记录。每个提交都有一个唯一编号，也叫 commit hash。

你截图右侧看到的：

0575c30c9
f3befaa2f
78d80f6a4

这些就是提交编号的短写。完整编号很长，界面上通常只显示前几位。

2. Branch：分支

分支可以理解成一条开发路线。

比如：

master：主分支，通常放比较稳定的代码
feature/login：开发登录功能的分支
fix/bug-table：修复课表 bug 的分支

你可以在自己的分支上开发，不影响主分支。开发完成后，再把自己的分支合并回主分支。

3. HEAD：你当前站在哪个提交上

HEAD 可以理解成“当前指针”。

大白话就是：

Git 现在认为你正站在哪个位置上。

通常情况下，HEAD 会指向当前分支的最新提交。

比如你当前在 master 分支，那么 HEAD 大概率就在 master 的最新提交上。

4. origin：远程仓库的默认名字

origin 不是分支，它是远程仓库的名字。

当你从 GitLab 或 GitHub 克隆项目时，Git 默认会把远程仓库叫做 origin。

所以：

origin/master
origin/dev
origin/feature/user

意思是：

远程仓库 origin 上的 master / dev / feature/user 分支在我电脑里的记录。

注意：origin/master 不是你本地真正正在编辑的分支，它更像是“我上次从远程同步下来时，远程 master 在哪里”。

四、截图一右侧的 origin/HEAD、origin/master、master 是什么意思

截图一右侧红箭头指向了一组标签：

origin/HEAD
origin/master
master

这几个标签都贴在同一个提交 0575c30c9 附近，说明它们目前指向的是同一个提交。

可以这样理解：

master：你电脑上的本地 master 分支
origin/master：远程 origin 仓库里的 master 分支，在你本地保存的一份同步记录
origin/HEAD：远程仓库默认分支的指针，通常指向 origin/master 或 origin/main

如果这三个标签在同一个提交上，通常说明：

本地 master 和远程 master 当前是同步的，没有谁比谁多提交。

如果它们不在同一个提交上，就要注意了。

情况 1：master 在 origin/master 前面

意思是：

你本地 master 有新提交，但还没有推送到远程。

这时候通常需要 Push。

情况 2：origin/master 在 master 前面

意思是：

远程 master 有新提交，但你本地还没有拉下来。

这时候通常需要 Pull。

情况 3：master 和 origin/master 分叉了

意思是：

你本地有提交，远程也有别人提交，而且两边不是一条直线。

这时候通常需要 Pull、Merge、Rebase 或解决冲突。新手不要急着点 Hard、Rebase、Force Push 这类操作，先问团队或先备份分支。

五、截图一左侧的彩色线条和圆点是什么意思

截图中间左侧有很多彩色线条和圆点，这就是 Git History 的提交图。

你可以把它看成地铁线路图：

圆点：一次 commit 提交
线条：分支的发展路线
线条分开：有人从这里拉出了新分支
线条合回来：有人把分支合并回来了
不同颜色：不同分支路线，方便你看清历史

比如你看到很多 Merge branch ...，这说明以前有人做过合并操作。

Merge branch 'xxx' 的意思是：

把 xxx 分支的代码合并进当前分支。

如果你看到线条很乱，不一定代表代码有问题，只是说明这个项目有多人、多分支、多次合并。

六、截图一右侧每一行按钮是什么意思

在每条提交记录右边，你能看到类似这些按钮：

Soft
Hard
+Tag
+Branch
More

这些按钮比较危险，尤其是 Hard 和 Rebase。下面逐个解释。

1. Soft

Soft 通常对应 Git 命令：

git reset --soft 某个提交

它的意思是：

把当前分支指针移动到某个提交，但保留你后面的代码改动，并且通常会把这些改动放在暂存区。

大白话：

我想撤回提交记录，但代码内容先别丢。

适合场景：

刚刚提交信息写错了，或者想把几次提交合成一次，但还想保留代码。

新手建议：

如果提交已经推送到远程，别随便 Soft Reset 公共分支。

2. Hard

Hard 通常对应 Git 命令：

git reset --hard 某个提交

它的意思是：

把当前分支强行回到某个提交，并且丢掉后面的本地改动。

大白话：

我要让代码彻底回到这个提交当时的样子，后面那些改动不要了。

这个按钮要非常谨慎。

因为它可能会让你本地未保存、未提交、提交后的部分内容消失。尤其是在团队项目里，如果你对已经推送过的公共分支做 Hard Reset，再强推，可能会影响其他同事。

新手建议：

没确认清楚之前，不要点 Hard。

3. +Tag

Tag 是标签，通常用来标记版本。

比如：

v1.0.0
v1.2.3
release-2026-06-18

大白话：

我想给这个提交贴一个版本标签，以后方便找到。

适合场景：

项目发版、上线、打包、保留稳定版本。

4. +Branch

+Branch 是从这个提交创建一个新分支。

大白话：

我想从这一次提交开始，另起一条开发路线。

适合场景：

你想基于某个历史版本修 bug。
你想从某个稳定提交拉一个临时分支。
你不想直接改主分支。

这是一个比较安全、常用的操作。

5. More

More 是更多操作菜单。你截图二展示的就是点开 More 以后出现的菜单。

里面包含：

Cherry pick
Checkout
Select for compare
Revert
Merge
Rebase

这些操作都和“当前分支”有关。点之前一定先看清楚 VS Code 左下角当前分支名。

七、截图二 More 菜单逐项解释

截图二里的菜单内容大概是：

Cherry pick this commit into current branch
Checkout this commit
Select this commit for compare
Revert this commit
Merge this commit into current branch
Rebase current branch onto this commit

下面用大白话逐个讲。

八、Cherry pick this commit into current branch：把某一次提交拿过来

Cherry pick 的意思是：

只把某一次提交的改动拿到当前分支，不把整个分支都合并过来。

假设有两个分支：

master：主分支
feature/table：课表功能分支

feature/table 上有 5 次提交，但你只想把其中一次“修复课表人数显示”的提交拿到当前分支。

这时就可以用 Cherry pick。

大白话：

我不要你整个分支，我只要你这一个提交里的改动。

适合场景：

某个 bug 修复已经在别的分支上提交了，现在我想把这个 bug 修复单独拿到当前分支。
某个小功能在别的分支上可用，但整个分支还不能合并。
线上分支急需一个修复，但开发分支上还有很多暂时不能上线的内容。

使用前一定确认：

我当前在哪个分支？
我选中的提交是不是我真的要拿过来的？
这个提交有没有依赖前面的其他提交？

为什么要确认依赖？

因为有些提交不是独立的。

比如：

提交 A：新增一个函数
提交 B：调用这个函数修复 bug

如果你只 cherry-pick 提交 B，但没有提交 A，代码可能会报错，因为函数不存在。

Cherry pick 可能遇到冲突。遇到冲突时，VS Code 会提示你哪些文件冲突了，你需要手动选择保留哪部分代码，然后继续完成 cherry-pick。

九、Checkout this commit：临时切到某个历史提交

Checkout 某个 commit 的意思是：

把代码切换到这个提交当时的状态。

大白话：

我想看看当时的代码长什么样。

它适合用来排查问题：

昨天还正常，今天坏了，我想切回昨天的提交看看。
我想确认某个历史版本里有没有这个文件。
我想运行一下旧版本代码。

但是这里有一个很重要的点：

直接 Checkout 到某个 commit，经常会进入 detached HEAD 状态。

detached HEAD 可以理解为：

你现在站在一个历史提交上，但没有站在任何正常分支上。

这时候你可以查看代码、运行代码，但不建议直接在这里继续开发。

如果你想基于这个历史提交继续改代码，更推荐：

先从这个提交创建一个新分支，再在新分支上开发。

也就是用 +Branch 会更稳。

十、Select this commit for compare：选中这个提交用来对比

这个操作不会改你的代码。

它的意思是：

先选中这个提交，等会儿再选另一个提交，看看两个提交之间代码差了什么。

大白话：

我要拿这个版本和另一个版本比一比。

适合场景：

我想看某个 bug 是什么时候引入的。
我想看两个版本之间改了哪些文件。
我想确认某次上线前后代码差异。

这个功能比较安全，因为它主要是查看差异，不会直接修改当前代码。

十一、Revert this commit：用一次新提交撤销旧提交

Revert 的意思是：

生成一个新的提交，用来抵消某个旧提交的改动。

注意，它不是删除旧提交。

假设有一个提交：

0575c30c9：新增了一个按钮

你点 Revert 后，Git 会创建一个新的提交：

xxxxxxx：撤销 0575c30c9 新增按钮的改动

历史记录里原来的提交还在，只是新增了一个反向修改。

大白话：

我不抹掉历史，我再提交一次，把之前那次改动反着改回去。

适合场景：

某次提交已经推送到远程了，但后来发现有问题。
公共分支上的提交需要撤销，但不想破坏大家的提交历史。
线上发现某次改动有 bug，需要回滚这一次改动。

新手推荐：

已经推送到远程的提交，优先考虑 Revert，而不是 Hard Reset。

因为 Revert 不会重写历史，团队协作更安全。

十二、Merge this commit into current branch：把提交所在的历史合进当前分支

Merge 的意思是合并。

菜单里的：

Merge this commit into current branch

意思是：

把这个提交背后的历史合并到当前分支。

大白话：

把另一条路线的代码合到我现在这条路线里。

适合场景：

功能分支开发完了，要合进主分支。
你当前分支需要同步另一个分支的完整代码。
团队采用 merge 的方式保留完整分支历史。

Merge 的特点：

会保留分支历史。
可能产生一个 Merge commit。
历史图上能看到线条合并。
如果两边改了同一个地方，可能会有冲突。

如果你截图里看到很多 Merge branch ...，就是因为项目里经常使用 Merge。

十三、Rebase current branch onto this commit：把当前分支接到这个提交后面

Rebase 比较容易让新手迷糊。

它的意思是：

把当前分支上的提交拿起来，重新放到另一个提交后面。

大白话：

我想把我的开发记录挪到一个新的起点后面，让历史看起来像一条直线。

比如原来历史是这样：

master:  A --- B --- C
feature:      \
               D --- E

如果 master 后来又多了 C，而你的 feature 还停在 B 后面，你可以把 feature rebase 到 C 后面：

master:  A --- B --- C
feature:              D' --- E'

注意这里变成了 D'、E'，因为 Rebase 会重新生成提交。

所以 Rebase 的重点是：

它会改写提交历史。

适合场景：

你自己的功能分支还没合并，想同步主分支最新代码。
团队要求提交历史尽量保持直线。
你的分支还没有被别人基于开发。

不适合场景：

公共分支。
已经被很多人拉取的分支。
你不确定团队是否允许 rebase 的分支。

新手建议：

如果这个分支已经推送到远程并且别人也在用，不要随便 Rebase。

十四、Revert、Reset、Checkout、Cherry pick 的区别

这几个词很容易混。

可以这样记：

Checkout：我只是想去某个提交看看。
Cherry pick：我只想拿某一次提交的改动。
Revert：我想安全撤销某一次已经提交的改动。
Reset Soft：我想撤回提交，但代码还留着。
Reset Hard：我想强行回到某个版本，后面的本地改动不要了。
Merge：我想把另一条分支路线合进来。
Rebase：我想把当前分支的提交重新接到另一个提交后面，让历史更直。

简单表格：

操作 会不会改代码 会不会改历史 适合新手吗 常见用途
Checkout commit 会切换工作区代码 不改历史 可以，但别直接开发 查看旧版本
Cherry pick 会把某次提交改动拿过来 会新增提交 可以，先确认当前分支 单独拿一个修复
Revert 会生成反向改动 不重写历史 推荐 撤销已推送的提交
Reset Soft 会移动分支指针，保留改动 会改本地历史 谨慎 撤回提交但保留代码
Reset Hard 会丢弃部分改动 会改本地历史 不推荐随便点 强行回到旧版本
Merge 会合并代码 不重写已有提交 常用 合并分支
Rebase 会重放提交 会改写提交 谨慎 整理分支历史

十五、一个前端开发最常用的日常流程

假设你要修一个课表显示人数的 bug，推荐这样做：

第一步：先拉最新代码

在 VS Code 源代码管理里点同步，或者在终端执行：

git pull

目的：

先保证你本地代码是最新的，减少冲突概率。

第二步：创建自己的分支

比如：

git checkout -b fix/course-queue-count

大白话：

我从当前代码拉一条自己的修复分支出来。

第三步：写代码并查看改动

写完以后打开 VS Code 左侧源代码管理，点每个文件看 diff。

确认没问题后，把需要提交的文件加入暂存区。

第四步：提交

提交信息建议写清楚：

fix: 修复课表显示排队人数

不要写太模糊的：

修改
bug
1
update

第五步：推送到远程

git push origin fix/course-queue-count

然后去 GitLab / GitHub 提交合并请求，也就是 Merge Request / Pull Request。

十六、怎么看自己当前在哪个分支

VS Code 左下角通常会显示当前分支名。

你截图底部左侧能看到一个分支名称。这个非常重要，因为很多操作都写着：

into current branch
onto this commit

也就是说：

当前分支是谁，操作就会影响谁。

比如你在 master 上点了 Cherry pick，它就会把提交拿到 master。

你在 feature/table 上点了 Cherry pick，它就会把提交拿到 feature/table。

所以点任何 Git History 的操作前，先看左下角当前分支。

十七、如何判断本地和远程是否同步

看标签位置：

本地分支名：master、dev、feature/xxx
远程分支记录：origin/master、origin/dev、origin/feature/xxx

如果本地分支和对应的 origin/xxx 在同一个提交上：

本地和远程同步。

如果本地分支在前面：

你有本地提交还没推送。

如果 origin/xxx 在前面：

远程有新提交，你需要拉取。

如果两边分叉：

本地和远程都有各自的新提交，需要合并或变基。

十八、遇到冲突怎么办

冲突通常发生在：

你和别人改了同一个文件的同一块地方。

VS Code 会在文件里显示类似：

<<<<<<< HEAD
你的代码
=======
别人的代码
>>>>>>> 分支名

这不是乱码，是 Git 在告诉你：

这里两边都改了，我不知道该保留谁，你来决定。

处理方式：

  1. 打开冲突文件。
  2. 看清楚两边代码。
  3. 选择保留当前、更改传入，或者手动合并。
  4. 删除冲突标记。
  5. 保存文件。
  6. 重新暂存。
  7. 继续提交、合并、rebase 或 cherry-pick。

新手处理冲突时，最重要的是：

不要乱删。
不要只看按钮，要看业务逻辑。
不确定就问改过这块代码的人。

十九、哪些按钮新手不要随便点

截图里的这些操作，建议谨慎：

Hard
Rebase
Checkout 到旧 commit 后继续开发
删除远程分支
Force Push

原因很简单：

它们可能改变历史，或者让本地代码回到旧状态，甚至影响团队其他人。

更安全的选择通常是：

想撤销已推送的提交：优先 Revert
想从旧版本改代码：优先 +Branch
想单独拿一个修复：用 Cherry pick，但先确认依赖
想合并完整分支：用 Merge

二十、看图速记：你截图里最重要的地方

截图一重点

左侧源代码管理图标：
用来看当前改了哪些文件、提交代码、推送拉取。

中间 Git History：
用来看历史提交、分支走向、谁合并了谁。

彩色线条：
不同分支的提交路线。

圆点：
一次 commit。

右侧 origin/HEAD、origin/master、master：
这些是分支或远程指针标签。贴在同一个提交上，说明它们当前指向同一个版本。

Soft / Hard / +Tag / +Branch / More：
这是对某个提交可以执行的操作，其中 Hard 和 Rebase 要非常谨慎。

截图二重点

Cherry pick：
只拿这个提交的改动到当前分支。

Checkout：
切到这个提交当时的代码状态，适合查看旧版本。

Select for compare：
选中这个提交用来和别的提交对比。

Revert：
新增一个提交来撤销这个提交，适合撤销已经推送的改动。

Merge：
把这个提交所在路线合并到当前分支。

Rebase：
把当前分支重新接到这个提交后面，历史更直，但会改写提交历史。

二十一、最推荐新手记住的 5 句话

  1. 提交前先看 diff，确认自己到底改了什么。
  2. 点 Git History 的操作前，先看左下角当前分支。
  3. 已经推送到远程的提交，想撤销时优先用 Revert。
  4. 不确定时不要点 Hard，也不要随便 Rebase 公共分支。
  5. 如果只是想基于旧提交改代码，优先从旧提交创建新分支。

二十二、最后用一句话总结

VS Code 的源代码管理面板负责“我现在改了什么、要不要提交”，Git History 负责“过去发生了什么、分支走到了哪里、我要不要对某次提交做操作”。

你截图里最容易误解的是 origin/HEAD、origin/master、master 这些标签。它们不是三份代码，而是三个指针。它们贴在同一个提交上，说明大家现在指向同一个版本；它们分开了，就说明本地和远程、或者不同分支之间开始有差异了。

真正操作时记住一句话：

先确认当前分支，再确认目标提交，最后再点操作按钮。
posted @ 2026-06-18 16:11  jialiangzai  阅读(19)  评论(0)    收藏  举报