【Git 快速实战】VSCode + Git 环境搭建与全流程指令速通指南

前言：在上一篇【Git 快速入门】团队协作开发核心工作流：从分支管理到代码提交的标准化实践-ZEEKLOG博客中，我们已经打通了“工作区、暂存区、本地仓库、远程仓库”这四个核心空间的任督二脉。如果说上一篇是“心法”，那么这一篇就是实打实的“剑招”。

很多开发者在理论上是个巨人，一到环境搭建就卡壳。这里有一个非常精准的比喻：Git 就像电脑的网卡驱动，而 VSCode 就像浏览器。 就算你装了最新最炫的浏览器（VSCode），如果没装底层驱动（Git），你也连不上代码托管的“网”——即无法进行版本控制。

本文将跳过繁琐的原理，直接通过 VSCode 终端，手把手带你完成从环境复原到模拟企业级开发的完整闭环。

第一阶段：环境复原（驱动安装与配置）

工欲善其事，必先利其器。Leader 交代的任务能否顺利开始，取决于我们的环境是否“干净”且“正确”。

1. 核心驱动安装

前往 Git 官网（git-scm.com）点击 "Download for Windows" 下载安装包。

双击运行 .exe 文件后，大部分步骤可以“无脑下一步”：

简单解释一下这里面哪几个最重要（也就是为什么不要乱取消）：

1. Windows Explorer integration (最实用)
   • 作用：它会在你的鼠标右键菜单里增加 Open Git Bash here。
   • 场景：以后你在任何文件夹空白处右键，点这个选项，就能弹出一个黑框框，路径直接就是当前文件夹。这比你打开终端然后 cd 来 cd 去要快一万倍。
2. Git LFS (Large File Support)
   • 作用：大文件支持。
   • 场景：如果你做科研，项目里可能会有一些图片、数据文件。如果不勾这个，Git 处理大文件会很慢甚至报错。勾上它，Git 就懂得如何优化大文件的传输。
3. Associate .sh files to be run with Bash
   • 作用：让 Windows 识别 .sh 脚本文件。
   • 场景：虽然你现在可能不用写脚本，但以后如果在 Github 上拉取别人的科研代码，很多配置脚本都是 .sh 结尾的，勾上这个能避免很多运行报错。

一路默认 Next 后，唯独下面这一步必须核对，它决定了你后续能否在 VSCode 里愉快地敲命令。

关键配置预警： 在安装向导运行到 "Adjusting your PATH environment" 这一页时，请务必确认勾选中间选项： "Git from the command line and also from 3rd-party software"（注：通常这是默认选项。它的作用是打通系统的“经脉”，让 VSCode 能直接调用 Git 核心。）

2. 验证安装与身份注册

安装完成后，无需寻找桌面图标，我们直接打开 VSCode。通过快捷键 Ctrl + ~（波浪号键）唤起底部的终端窗口。这是最主流、最顺滑的工作流入口。

步骤一：引擎自检 在终端输入以下指令并回车：

git --version 

如果界面返回了类似 git version 2.xx.x.windows.x 的版本号，恭喜你，底层驱动已就绪。

【如果报错，提示：git : 无法将“git”项识别为 cmdlet、函数、脚本文件或可运行程序的名称。请检查名称的拼写，如果包括路径，请确保路径正确，然后再试一次。】重启试之！

步骤二：报家门（配置身份） Git 是一个严谨的记录系统，它必须知道“是谁”在修改代码，否则会拒绝提交。请依次执行以下两行指令（建议填写真实拼音和邮箱，这是职业素养的第一步）：

git config --global user.name "YourName" git config --global user.email "[email protected]" 

注：输入完毕后如果终端没有任何报错提示，即代表配置成功。

第二阶段：实战拉取

通常，Leader 给你的第一个任务通常是：“把仓库拉下来”。我们将使用 GitHub 官方提供的练手仓库 Spoon-Knife 进行实战。

首先，在你的硬盘中创建一个干净的文件夹（例如 D:\Project_Test），并在 VSCode 中通过 File -> Open Folder 打开它。确保你的终端路径已经定位到了这个文件夹下。

执行拉取指令：

git clone https://github.com/octocat/Spoon-Knife.git 

执行反馈： 你会看到终端中跑出一串百分比进度条。待进度条跑完，查看 VSCode 左侧的文件资源管理器，你会发现多出了一个名为 Spoon-Knife 的文件夹。至此，你已成功将远程仓库的“货”搬运到了本地。

第三阶段：开发与提交

这是日常开发中最高频的操作循环。Leader 如果问你“会不会提交到分支”，考察的就是下面这套标准动作。

1. 进入项目文件夹

初学者最容易犯的错误是在项目外层敲命令。请务必先进入项目文件夹：

cd Spoon-Knife 

观察点：此时终端路径后缀通常会出现蓝色的 (main) 或 (master) 字样，这标志着你已正式进入 Git 托管的代码领域。

2. 创建独立开发空间（切分支）

为了保护主分支的稳定性，我们需创建一个名为 my-test-feature 的新分支进行作业：

git checkout -b my-test-feature 

此时，终端的提示符应变为 (my-test-feature)。

3. 模拟代码修改

在 VSCode 左侧打开 README.md 文件，随意输入一行文字（如 "Hello, trying git workflow"），并按 Ctrl + S 保存。此时左侧“源代码管理”图标上会出现蓝色的数字标记，提示有文件发生了变动。

4. 提交三部曲（SOP）

请严格按照“装箱 -> 封箱 -> 发货”的顺序执行：

Step A: 装箱 (Add) 将修改加入暂存区：

git add . 

Step B: 封箱 (Commit) 生成版本记录，请养成写好备注的习惯：

git commit -m "update: 模拟适配修改，更新README文件" 

Step C: 发货 (Push) 这是最关键的一步。因为 my-test-feature 是刚在本地建的“私有分支”，远程仓库（GitHub）里现在并没有这个分支。 所以，第一次推送时，我们不能只说“推代码”，还得告诉 Git 建立联系（即 Upstream 追踪关系）：

git push --set-upstream origin my-test-feature 

老手技巧： 那个 --set-upstream 太长了？其实 Git 贴心地准备了缩写 -u。 所以以后在公司里，更“帅气”的写法是： git push -u origin my-test-feature

【如果是第一次连接的话，上图的git push操作需要加入-u哦~】

特别说明： 当你执行这一步时，终端会报错提示 Permission denied（权限被拒绝）。 请不要惊慌，这是预期的正确结果！ 原因：Spoon-Knife 是别人的公开仓库，你只有读取权，没有写入权。但在公司真实的开发场景中，Leader 会将你加入项目成员列表，届时同样的命令将会显示 Success。