企业官网建设流程全解析

开了可能你会觉得奇怪，VS Code 里那个长得像分叉树枝的图标，到底能干什么？为什么每一个教程都在说 Git？作为一个已经带过不少新人入门的老开发者，我特别理解这种状态：VS Code 装好了，代码也能写了，但一打开“源代码管理”面板，满屏英文、一堆按钮，根本不敢点。这篇就是专门写给完全不懂 Git 的人，从安装开始，一步步带着你把版本控制用起来。

这篇教程全程围绕一个目标：在 VS Code 里把 Git 变成日常写代码的一部分，而不是背一串命令。我会把这套组合拳拆成几个阶段：先装好环境，再完成人生第一次提交，接着搞定每天都要用的拉取、推送、分支操作，最后解决那些折磨人的高频报错。不管你以前有没有接触过命令行，跟着这篇走完，至少能应付绝大多数写代码场景。

1. 先把环境备齐：VS Code 和 Git 怎么装、怎么确认装好了

1.1 这个组合到底能帮你解决哪些烦恼

先说点实在的。很多人刚写代码的时候，项目文件夹里经常出现“最终版-改1.py”“最终版-改2.py”“最终版-打死不改.py”这种文件名。Git 存在的最直接意义，就是帮你终结这种混乱：每一次修改都可以留痕迹，改坏了能回退，想对比哪里变了也能一眼看到。

换句话说，Git 是一个时间机器，也是一个多人协作的记录本。而 VS Code 做的事情，是把这些原本要用命令行敲的内容，变成可视化的按钮和面板。对新手来说，在 VS Code 里操作 Git，最大的好处是能随时看到文件状态——哪个文件改了、哪个还没提交、当前在哪个分支，全部一目了然，心里不会慌。

所以这套组合适合的人很明确：刚开始接触编程、想规范管理代码的学生，工作环境里已经用 Git 协作但一直靠“复制粘贴备份”的开发者，还有想搞懂原理但受不了纯命令行门槛的自学者。

1.2 安装 Git 的完整过程（Windows / macOS / Linux）

Git 本身是独立于 VS Code 的工具，VS Code 只是个图形界面外壳，所以第一步永远是先把 Git 装上。

Windows 用户，直接去 Git 官网下载安装包，注意认准 Windows 版本，不是 Windows portable 那种免安装版也行，但新手建议用正式安装包。安装过程基本一路 Next，但有三个细节要留意：

• 安装路径不要带中文，比如默认的C:\Program Files\Git就行；
• 在选择默认编辑器那一步，如果你已经装了 VS Code，直接选 “Use Visual Studio Code as Git's default editor”；
• 环境变量那一步，选 “Git from the command line and also from 3rd-party software”，这样 VS Code 才能正确调用 Git。

装完以后，打开 CMD 或 PowerShell，输入git --version，能输出版本号就说明内核装好了。

macOS 用户最简单的方式是安装 Xcode Command Line Tools，系统会自带 Git；也可以用 Homebrew 执行brew install git。Linux 用户则可以根据发行版使用sudo apt install git或sudo yum install git之类的命令。这三个平台的验证方式都一样，认准git --version这个命令。

1.3 安装 VS Code 和被忽略的“添加到 PATH”

VS Code 直接去官网下载安装包就行，Windows 安装到那一堆勾选项时，建议务必勾上“添加到 PATH”。这一步很多人会跳过，导致后面在终端里输入code .打不开编辑器，或者 Git 找不到 VS Code 作为默认编辑器。

安装完成后，我建议顺手装一个中文语言包插件。打开 VS Code 左侧的扩展面板，搜索“Chinese”，找到“中文（简体）语言包”安装，重启一下就变成中文界面了。别小看这一步，对刚上手的人来说，中文界面能少一半恐惧感。

1.4 在 VS Code 里确认 Git 已经生效

现在打开 VS Code，点击左侧“源代码管理”图标——就是那个像是分叉树一样的图标，英文叫 Source Control，快捷键是Ctrl + Shift + G。如果你的 VS Code 能够识别 Git，点击后应该没有任何报错提示，下方可以正常打开源代码管理面板。

这时候有个实用设置可以提前做：打开命令面板（Ctrl + Shift + P），输入“Terminal: Select Default Profile”，把默认终端改成 Git Bash。这样做的好处是，你在 VS Code 内打开的终端本身就是 Git 环境，命令都能直接用，不用在多个窗口之间来回切换。

注意：如果你打开了源代码管理面板，却提示“Git 未安装”或“无法找到 git”，不要急，大概率是安装 Git 时没有把环境变量配置好。最直接的解决办法是：找到 Git 安装目录下的cmd\git.exe，把路径加到系统环境变量 Path 里，然后重启 VS Code。

2. 从零到一：完成你在 VS Code 里的第一次 Git 提交

2.1 工作区、暂存区、本地仓库到底是什么

很多新手失败，是因为一上来就背概念，背完还是不知道每一步在干嘛。我用一个寄快递的流程来解释：

• 工作区：就是你电脑上正在编辑的文件夹，相当于你买东西的购物车；
• 暂存区：你把想提交的文件“加”进去的区域，相当于把商品装进快递盒但还没贴上运单；
• 本地仓库：正式记录这些修改的地方，相当于快递已经寄出、有了运单号；
• 远程仓库：放到服务器上的备份，相当于快递送到别人手里，大家都能看到。

理解了这四个层级，后面所有操作就顺了。在 VS Code 里，文件状态不同，显示颜色也不同：新增文件是绿色U，修改过的文件是黄色M，删除的文件会变成灰色D。这个状态提示非常直观，比命令行友好得多。

2.2 初始化仓库，并完成第一次提交

这一步之前先做个准备工作：在 VS Code 中打开一个空文件夹（或者放着你练习代码的文件夹），然后点击源代码管理面板的“初始化存储库”按钮。如果文件夹里没有.git目录，说明仓库还没建立成功。

初始化完成后，随便新建一个文件，比如hello.py，在里面写一行代码：

print("Hello Git")

保存后，你会看到源代码管理面板里这个文件出现在“更改”列表下，旁边带着字母U。这时候点文件右侧的“+”号（暂存更改），文件会进入“暂存的更改”区域。然后再点击菜单栏顶部的对勾按钮（提交），在弹出的输入框里写上提交信息，比如first commit，回车确认。

看到这里，你的第一次 Git 提交就完成了。想确认提交成功，可以打开 VS Code 内嵌终端，输入：

git log --oneline

能看到类似xxxxxxxx first commit的输出，就说明本地仓库已经记住了这个快照。以后每次改代码，都可以按这个流程：修改 -> 暂存 -> 提交。

2.3 提交信息怎么写才不算白写

新手最容易忽略的，是提交信息本身。很多人提交按钮一点，随手写个2、asdf、update，等过几天再回来看，完全不知道那次提交改了什么。这里我建议一个最简单有效的规则：用动词开头，说清楚“做了什么”，比如：

• feat: 新增登录页面
• fix: 修复结算金额计算错误
• docs: 更新README说明

如果一次提交里改的东西很多，宁可分几次提交，也别把十个不相关的改动揉成一个。之所以强调这一点，是因为 Git 最大的好处不是存代码，而是让代码的演变过程可追踪。提交信息写得清楚，后面定位问题会省很多时间。

提示：在 VS Code 的源代码管理面板里，还有一个“提交”按钮旁边的小箭头，点开可以选择“提交全部”，也就是把暂存区和未暂存的改动一起提交。新手阶段建议先养成“先暂存再提交”的习惯，避免把自己没想清楚的改动也一起交上去。

3. 每天都要用的操作：拉取、推送和分支管理

3.1 第一次对接远程仓库：把你的代码放上服务器

代码只在本地仓库，风险很大——电脑硬盘一坏，全没了。而且多人协作时，其他人也看不到你的代码。这时候就需要一个远程仓库，常见的选择是 GitHub、Gitee，或者公司搭的 GitLab。

以 Gitee 为例，先在网页上创建一个空仓库，拿到仓库地址，比如：

https://gitee.com/yourname/yourproject.git

在 VS Code 中打开终端，执行下面这条命令，把本地仓库和远程仓库绑定：

git remote add origin https://gitee.com/yourname/yourproject.git

然后推送本地代码：

git push -u origin master

这里-u的意义是设置默认上游，以后直接git push和git pull就能对应到这个分支，不用每次写完整参数。如果你是第一次从远程仓库开始干活，更简单的方式是直接克隆：

git clone https://gitee.com/yourname/yourproject.git

克隆下来的项目，VS Code 打开就能看到完整的 Git 状态，连初始化这步都省了。

3.2 推送和拉取：到底谁先谁后

推拉这两个动作，是使用频率最高的。在 VS Code 源代码管理面板底部，有一排小图标，鼠标放上去会显示提示：刷新、同步更改、拉取、推送。它们的关系用一句话说清楚：

• 拉取：把远程仓库的最新代码下载到本地；
• 推送：把本地提交上传到远程仓库；
• 同步：先拉取再推送，一次完成。

新手常见错误是只推不拉，结果别人先推了，自己推送时被 Git 拒绝。正确的日常姿势应该是：开始写代码前先拉取一次，写完提交后推送一次；如果看到推送被拒绝，第一时间先拉取，解决完冲突再推送。这块内容在第 4 部分会展开讲。

重要：推送之前，必须先在本地有提交记录。如果你改了代码却忘了提交，直接点“推送”，推送的其实只是之前提交过的旧代码，新改动并不会自动传上去。这个坑我见过太多次了，改完代码记得先看源代码管理面板里有没有未提交的更改。

3.3 分支操作：在 VS Code 里创建、切换、合并分支

分支是 Git 最强大但也最容易吓到新手的部分。形象点说，分支就像平行宇宙：你在一个宇宙里修 bug，别人在另一个宇宙里开发新功能，互不干扰，最后再合到一起。

在 VS Code 左下角，你会看到当前分支的名字，比如master或main。点击它，顶端会弹出一个分支列表，选择“创建分支”，输入一个新名字，比如feature-login，回车后 VS Code 会自动切换过去。在这个分支上做修改、提交，都不影响原来的主分支。

等新功能开发完毕，需要把代码并回主分支时，操作为：先切换回主分支，再点击左下角分支名，选择“合并分支”，选中刚才的feature-login分支，确认合并。

关于分支，新手只需要记住三个原则：主分支尽量保持可运行状态；新功能开新分支；合并前先拉取远程最新代码。至于更复杂的分支命名规范、多重合并策略，暂时不需要接触，等真的需要了再学不迟。

3.4 图形界面和命令行怎么配合效率才最高

很多人有个误区，觉得一定要背熟命令行才算会 Git。其实 VS Code 的图形界面已经覆盖了 90% 的日常操作。我自己实际工作中的习惯是：查看状态、暂存、提交、冲突解决用图形界面，因为这些操作可视化程度高、出错少；创建远程仓库、修改远程地址、复杂的回退操作用命令行，因为要精确控制。

下面这张表是我推荐给团队新人的操作方式对照：

4. 新手高频报错与排查：我踩过的那些坑

4.1 每次推送拉取都要输入账号密码，烦死了

这是新手问得最多的问题之一。用 HTTPS 方式远程仓库时，Git 默认会请求身份验证，如果系统没有保存凭据，每次 push、pull 都得输一遍。解决方式很简单：借助 Git 自带的凭据管理器。

在终端执行：

git config --global credential.helper manager

这是 Windows 上的凭据管理器，第一次输入账号密码后会保存到系统凭据库，之后就不用重复输入了。macOS 上可以使用：

git config --global credential.helper osxkeychain

如果想更彻底一些，也可以在克隆时直接使用 SSH 地址，并配置 SSH 密钥。GitHub 和 Gitee 的网页上都有生成密钥的官方说明，这里不再展开。需要提醒的是，千万不要把密码写死在命令里，也不要随便把.git/config这个文件提交到远程仓库，否则账号信息会泄露。

4.2 合并冲突：弹出来的红色内容不是世界末日

冲突的产生很简单：两个人同时改了同一个文件的同一行，Git 不知道听谁的，就把问题抛给人类解决。VS Code 的源码管理面板里，一旦检测到冲突，文件会带上C状态，点击该文件，会进入冲突编辑器。

VS Code 会把冲突区域分成几栏显示，顶部按钮分别是“接受当前更改”“接受传入更改”“接受两者更改”。这里的“当前”一般指你当前所在分支的内容，“传入”指正在合并进来的分支内容。你可以逐个点按，也可以手动编辑最终保留的内容。全部处理完后，记得先在冲突编辑器右上角点“标记为已解决”，把文件加入暂存区，然后照常提交一次，合并才算完成。

发生冲突不可怕，可怕的是乱改。我的建议是：遇到冲突别慌，先看清楚两边的代码，再想清楚到底要保留哪边；如果在协作场景下拿不准，直接喊上代码作者一起商量，比你自己瞎合并靠谱得多。

4.3 其他几个高频问题的速查

这里整理几个新手阶段几乎必遇到的坑，每条都是我实际见证过的：

• VS Code 里看不到任何 Git 图标：检查 Git 是否安装、环境变量是否配置、重启 VS Code；还没解决就打开终端输入git --version确认。
• git 命令显示“不是内部或外部命令”：根本原因是 Git 没有加入 PATH，重新安装并勾选“从命令行使用 Git”即可。
• 提醒“Your branch is ahead of 'origin/master' by 1 commit”：说明本地比远程多了提交，执行git push推上去。
• 推送被拒绝（failed to push some refs）：远程有别人更新的提交，先git pull再推；如果提示 rebase，可以先不管，直接用git pull --no-rebase。
• 打开了仓库却看不到别人的更新：先检查当前分支是否正确，再执行git fetch或直接点刷新图标。
• commit --amend 是什么东西：这是修改最近一次提交信息的命令。如果刚才提交后立刻发现提交信息写错了，用git commit --amend -m "新信息"可以改，但注意：已经推送到远程的提交不要随便 amend，否则会给协作的人添乱。
• worktree 是什么？新手先别碰：git worktree允许你同时在一个仓库上签出多个工作目录，属于高级操作。新手阶段容易把仓库搞乱，我建议先不管它，等对分支和目录结构非常熟悉了再来研究。
• 看到“小乌龟”相关教程要不要装：TortoiseGit 是 Windows 上把 Git 集成到右键菜单的客户端，老牌工具。但它和 VS Code 的图形界面定位重复，新手没必要同时学两套，选一套就够了，我推荐优先熟悉 VS Code 自带的面板。

我把这些问题整理成一个更直观的对照表：

4.4 一个值得早点养成的习惯：多做状态检查

很多新手遇到问题就慌，其实是不知道现在处在什么状态。在 VS Code 里，最简单的状态检查就是看源码管理面板，它会完整列出所有被修改、新增、删除的文件。配合终端里的git status，能更清楚地看到正在跟踪的分支、暂存区里的内容、还有哪些变更没有处理。

我的习惯是：每次准备提交前，先看一遍面板上的“更改”列表，确认没有把不该提交的文件（比如临时配置、秘钥文件）带进去。这一眼能避免很多尴尬，比如不小心把本地数据库连接串口推到了公共仓库。

5. 我的个人工作流，以及给新手的最后建议

5.1 一个够用且安全的日常 Git 流程

如果要我从头带一个新人，我会给他一套固定流程，前两周先照做，形成肌肉记忆之后再去理解更多命令：

每天开工先拉取最新代码，然后开始改需求或写功能。完成一小阶段后，就在 VS Code 里提交一次，提交信息写清楚。到一天结束时，再拉取一次远程代码（防止别人推了新东西），然后推送本地提交。如果中途推送被拒绝，就先拉取、解决问题、再推送，不硬推。

这套流程最大的好处是：长时间保持新鲜代码都在远程仓库，不会出现本地改了一周、最后推送时和队友冲突到崩溃的状况。小步提交、频繁推送，是 Git 协作的基石，也是我这么多年最想传递给新人的习惯。

5.2 值得关注的快捷键、插件与配置

VS Code 自带的 Git 功能其实已经够用，不需要装一堆花里胡哨的插件。但有两个我觉得值得推荐：

第一是 GitLens。它能在代码行尾显示这行代码的作者和最近一次修改时间，排查“这段代码谁写的、为什么要这么写”时非常好用，尤其是加入团队项目后；对单机学习场景，它的可视化历史也能帮你加深理解。

第二是 Git History。它提供一份图形化的完整提交时间线，比命令行里看 log 直观得多。不过如果装 GitLens，很多这类功能已经包含在里面了。

快捷键方面，最常用的是Ctrl + Shift + G（打开源码管理），Ctrl + Enter（在提交信息框内快速提交），以及Ctrl + Shift + P（命令面板）。命令面板里输入git能看到所有 Git 相关命令，哪怕按钮位置忘记，也能快速找到入口。

5.3 我踩过几次坑之后最想说的事

如果你让我用一句话总结 Git 的学习路径，那就是：先不要试图理解所有原理，把提交、推送、拉取、分支、合并这五件事练熟，日常干活就不慌了。

刚开始用的时候，几乎每个人都会犯同一个错：把提交当成一个“仪式”，改了半天只提交一次。其实 Git 的设计思路是鼓励你频繁提交的，每一次提交都是一个保存点。把代码写完再提交，等于把所有鸡蛋放在一个篮子里，一旦改崩，回退范围巨大。

还有一件事，我特别想强调：不要怕冲突。很多人一看到代码变成红色就手足无措，其实冲突就是一次需要你亲自做选择的信息提示，解决完冲突并提交，你对 Git 的理解会明显上一个台阶。

最后分享一个我自己一直在用的小习惯：每一次提交前，都花十秒钟扫一眼正在提交的文件列表。这个动作救过我很多次，比如误提交了包含敏感路径的配置文件，或者把临时写的测试代码也推进了主分支。养成这个习惯以后，你在 Git 上栽的跟头会少一大半。