1. 先把“锅碗瓢盆”备齐VS Code 与 Git 安装扫盲先说点实在的。VS Code 现在已经是绝大多数开发者默认的编辑器而 Git 是绕不开的版本管理工具。你把这两个东西装好、配好等于有了一个能干活、能后悔、能协作的开发环境。这篇教程面向真正的零基础用户我尽量把每一步都拆开讲清楚包括安装时哪些选项该勾、哪些不该勾以及为什么。1.1 vs code 下载与安装别一路狂点“下一步”VS Code 的官网地址是 code.visualstudio.com注意别进到第三方下载站。主页上有个很显眼的蓝色下载按钮系统会自动识别你的操作系统Windows 用户直接点“Windows User Installer 64-bit”即可。下载完双击安装包前几步都保持默认但到“选择附加任务”这一步千万停一下。这里有几个关键选项直接影响你后续用 Git 的体验“将‘通过 Code 打开’操作添加到 Windows 资源管理器目录上下文菜单”建议勾上右键文件夹直接用 VS Code 打开比先开编辑器再找路径高效太多。“将‘通过 Code 打开’操作添加到 Windows 资源管理器文件上下文菜单”同上处理单个文件时很方便。“添加到 PATH”必须勾选。这个决定了你能不能直接在终端里输入code命令启动编辑器。很多教程没强调这个导致后面配环境时一脸懵。安装完成后首次打开界面默认是英文的。按CtrlShiftX打开扩展面板搜索“Chinese (Simplified)”安装微软官方的简体中文语言包重启后就是中文界面了。顺手把Prettier - Code formatter、ESLint这类常用扩展也装上不过初期不装也不影响 Git 学习。注意如果你是 Win7 系统需要下载旧版 VS Code1.70 及以下。新版早已停止对 Win7 的支持装上去会提示无法启动。1.2 Git 安装配置三个必须手动处理的坑Git 的 Windows 版本叫 Git for Windows官网 git-scm.com下载速度慢的话可以找国内镜像。安装过程比 VS Code 曲折不少几个关键节点说清楚第一个坑PATH 环境变量。安装到“Adjusting your PATH environment”这一步默认选的是“Git from the command line and also from 3rd-party software”。这个选项意味着 Git 的命令可以在 CMD、PowerShell、Git Bash 里通用。别选“Use Git and optional Unix tools from the Command Prompt”那个会把 Git 自带的 Unix 工具覆盖进系统 PATH容易和系统原有命令冲突没必要冒这个险。第二个坑行尾转换Line Ending Conversions。这一步叫“Configuring the line ending conversions”默认是“Checkout Windows-style, commit Unix-style line endings”。也就是检出代码时转成 Windows 的 CRLF提交时统一转成 LF。这个选项对跨平台协作是最稳妥的别动它。等你以后和 Linux/macOS 同事协作时就会感谢这个默认设置它避免了一大批“明明代码没改却提示整个文件都变了”的尴尬情况。第三个坑终端模拟器。“Choosing the default terminal emulator”这一步默认“Use MinTTY”就好。MinTTY 的缩放、复制粘贴、滚动体验都比 Windows 自带的 Console 强。安装完成后打开任意终端输入git --version能输出版本号就说明成了。接着配置你的身份信息这是 Git 提交记录里显示的作者名称和邮箱务必和你的 Gitee/GitHub 账号保持一致git config --global user.name 你的名字 git config --global user.email 你的邮箱查看配置是否生效git config --global --list这一步做不好后面所有 commit 记录上显示的都不是你团队协作时找人背锅都找不对人。2. 第一次提交代码理解工作区、暂存区、本地仓库安装配置只是热身真正理解 Git 是干什么的得从第一次提交开始。很多新手被 Git 的各种概念劝退其实核心就三个区域工作区就是你文件夹里看到的那些文件、暂存区临时存放你要提交的改动、本地仓库Git 真正保存历史记录的地方。弄懂这三个概念后面所有操作都能串联起来。2.1 用 VS Code 初始化仓库不用敲命令也能行假设你现在手上有一个项目文件夹里面放着index.html、style.css等文件或者干脆是空的。用 VS Code 打开这个文件夹点击左侧边栏的“源代码管理”图标长得像分叉的树枝会看到一个“初始化仓库”按钮。点击之后VS Code 会在项目根目录生成一个.git文件夹这就是本地仓库的数据库。此时你的文件还处于“未跟踪”状态左侧面板会列出所有文件每个文件名后面都有一个字母UUntracked未跟踪。这个阶段我可以直接告诉你一个实操心得别急着点“提交”先理解你看到了什么。左侧面板其实就是 Git 的图形化状态中心它显示的是当前工作区相对于暂存区的差异。文件名的变化无非三种U表示新文件还没被 Git 管理M表示已跟踪文件被修改过D表示文件被删除了。看懂了这些字母你就看懂了 Git 一半的状态提示。2.2 git add 与 git commit 的底层逻辑为什么要有暂存区在 VS Code 中将鼠标悬停在某个文件上点击右侧的“”号文件就会从“未跟踪”变成“已暂存”左侧面板会出现一个“暂存的更改”分组。这个“”号操作对应命令行里的git add。为什么要有暂存区直接讲一个真实场景你就明白了你在一个文件里改了功能 A 和功能 B 两处代码如果一次性全部提交未来查找历史时你很难快速定位到具体是哪一处改动引入了 bug。有了暂存区你可以只暂存功能 A 相关的代码行提交一次并写上注释“完成功能A”然后再暂存功能 B 的代码再提交一次。这样提交历史干净清晰将来排查问题时git log里每条记录都对应一个独立的功能点效率天差地别。暂存完所有文件后在顶部输入框里填上提交信息比如“初始化项目添加首页结构”然后点击“提交”按钮。这个操作对应git commit。提交成功后左侧面板会显示“没有暂定的更改”文件后面的字母消失了说明所有改动都进了本地仓库。这时你可以在终端里验证一下git log --oneline会看到类似a1b2c3d 初始化项目添加首页结构的输出这就是你项目历史上的第一个里程碑。每一次提交就像给当前的项目状态拍了一张照片随时可以回放、对比、还原。提示提交信息不是随便写的。建议遵循“动词 对象 目的”的格式比如“修复登录页面在移动端样式错位的问题”而不是“改了 bug”。一份清晰的提交历史是代码最好的文档。3. 连接远程仓库Gitee 的 SSH 指纹与推拉同步本地仓库解决的问题是“我自己后悔了能找回”但真正的工作场景是多人协作、多设备同步这时候就需要远程仓库。国内开发者用得最多的是 Gitee码云也有不少团队直接上 GitHub 或公司内部的 GitLab。每一步的流程大同小异我就以 Gitee 为例把从新建仓库到推拉的完整链路走一遍。3.1 生成 SSH Key为什么 HTTPS 方式总是要输密码很多人在第一次接触远程仓库时会直接选择 HTTPS 地址进行 clone然后发现每次 push 或 pull 都要输入账号密码烦不胜烦。根本原因在于HTTPS 协议每次操作都要向服务器验证你的身份。解决方式是改用 SSH 协议让 Git 识别你本机的专属身份标识也就是 SSH Key。打开 Git Bash或 VS Code 的终端输入ssh-keygen -t rsa -b 4096 -C 你的邮箱一路回车可以生成的密钥默认存放在C:\Users\你的用户名\.ssh\目录下其中id_rsa是私钥绝不能泄露id_rsa.pub是公钥需要上传到 Gitee。私钥只保存在你自己电脑上任何场景都不应该发给别人。查看公钥内容cat ~/.ssh/id_rsa.pub复制输出的整段内容登录 Gitee点击头像进入“设置”找到“SSH 公钥”把内容粘贴进去标题随意。这一步相当于告诉 Gitee“持有这把公钥对应私钥的机器是我本人请允许它访问我的仓库。”验证是否配置成功ssh -T gitgitee.com看到 “Hi xxx! Youve successfully authenticated” 之类的提示说明 SSH 链路已经通了。这个过程中我也踩过一次坑有的同事在 Windows 上生成密钥时会一不小心直接生成到系统管理员目录下导致 VS Code 里使用 Git 时找不到密钥。如果你配置完还是提示权限拒绝先检查~/.ssh路径里的文件是否真的存在再检查环境变量HOME是否被改过。3.2 在 Gitee 新建远程仓库并完成首次推送登录 Gitee 后点击右上角的“”号选择“新建仓库”。仓库名称自定比如my-first-project。这里有个细节是否勾选“初始化仓库”。如果你本地已经有代码了就不要勾选“使用 Readme 初始化这个仓库”避免本地和远程的历史互不相干第一次 push 时还得处理冲突。等仓库创建好页面上会给出两种远程地址选择 SSH 格式的那一条复制下来。回到 VS Code 终端本地仓库关联远程仓库git remote add origin gitgitee.com:你的用户名/my-first-project.gitorigin是远程仓库的默认别名你可以理解成“远端地址的快捷方式”。以后git push origin master就等于把本地代码推送到这个远程仓库。首次推送git push -u origin master-u参数的作用是建立本地分支与远程分支的跟踪关系以后直接输入git push就能推送不用每次都写完整的origin master。推送成功后打开 Gitee 仓库页面你会看到所有文件已经同步上去了。如果你换了台电脑想把这套代码拿下来就在新机器上执行git clone gitgitee.com:你的用户名/my-first-project.gitclone会把远程仓库的完整历史、所有分支都拉到本地并且自动关联好origin。这一步做完远程同步链路就完整了剩下的就是日常的推push和拉pull。3.3 解决 vs code 中 git 每次都要输入账号密码的问题这是搜索热度非常高的一个问题也是在 HTTPS 方式下最常见的问题。核心原因就是第一小节里说的HTTPS 每次操作都要求身份认证。解法有两条路方法一切换为 SSH 克隆地址。把远程地址改掉git remote set-url origin gitgitee.com:你的用户名/my-first-project.git之后所有操作走 SSH不再要求输入密码。方法二启用 Git 凭据管理器。依次点击开始菜单里的“Git”文件夹下的“Git Credential Manager”或者安装 Git for Windows 时自带这个组件。在 Windows 凭据管理器控制面板 - 用户账户 - 凭据管理器里把 Gitee 的账号密码存进去下次操作时 Git 会自动读取不用手动输入。我实测下来这个方式和 VS Code 结合的体验也不差但如果你经常在命令行操作还是建议直接走 SSH少一层中间环节。4. 分支、合并与冲突团队协作绕不开的坎单个分支只能满足单机自嗨真正的项目开发一定涉及多人并行开发。Git 的分支模型是它最强大的设计也是初学者最容易卡壳的地方。这一章讲透分支的创建、切换、合并以及最让人头疼的冲突解决。4.1 分支的本质一个指向提交记录的“可移动指针”先破除一个误解分支并不是复制了一套代码。在 Git 内部分支其实只是一个指向某一次提交的指针。当你新建一个分支Git 只是创建了一个指向当前提交的新指针成本极低所以你随便开分支不用担心仓库体积膨胀。在 VS Code 中点击左下角的分支名默认是master或者main会弹出分支操作面板选择“创建新分支”输入如feature-login回车确认。此时你就已经切换到了新分支在这个分支上做的所有提交都不会影响master分支。团队协作的标准流程是这样的每个人从master拉出一个自己的功能分支比如feature-login、feature-pay各干各的互不干扰。等某个功能完成并经过测试后再把分支合并回主干。这个模式的妙处在于“降低并发干扰”你在feature-login里改文件同事在feature-pay里改文件两人操作互相隔离。即使某人的改动把代码搞崩了也不会影响主分支其他同事的功能依然能正常合并上线。4.2 合并分支与解决冲突的实操案例功能开发完成要把feature-login合并到master。先切换到目标分支也就是你想把改动合并到哪个分支就先切到哪个分支git checkout master然后执行合并git merge feature-login多数情况下如果两个分支各自改动的文件互不重叠Git 能自动完成合并。但总会有意外你和同事同时修改了同一个文件的同一个区域Git 无法判断哪份改动才是最终想要的就会提示“冲突CONFLICT”。VS Code 对冲突的处理非常直观它会把冲突文件用颜色块和文字标记清晰地展示出来。冲突区域通常长这样 HEAD 你当前分支master的代码 让你想合并进来的分支feature-login的代码 feature-login你需要人工判断保留哪一份或者把两边内容都整合成一份。在 VS Code 的“源代码管理”面板里冲突文件会显示一个C标记。点击文件进入编辑器VS Code 上方会提供四个操作选项“接受当前更改”“接受传入更改”“接受两者更改”“比较更改”。常规操作是点击“接受两者更改”然后手动调整细节。注意解决完冲突后一定要再次点击“”号暂存该文件然后重新提交一次。这个提交相当于“缝合”两个分支的差异是冲突解决的收尾动作。忘了暂存就提交会提示“有未合并的文件无法提交”。4.3 git worktree同一项目多分支并行开发的进阶姿势经常面临这种场景线上出了紧急 bug但你手头正在一个尚未完成的功能分支里还不想提交半成品。如果切回主分支就得 stash 暂存当前改动或者强行提交如果直接切换分支Git 会因为工作区不干净而禁止你切换。这时候用git worktree就舒服得多。git worktree add ../my-project-hotfix master这个命令会在项目相邻目录../my-project-hotfix里新建一个工作区并检出master分支。你可以在这个新目录里开 VS Code、改代码、提交、推送完全不碰你主目录里正在开发的分支。都处理完后再回到原来的目录继续干活。用完之后清理git worktree remove ../my-project-hotfix这个功能最大的价值是让我们“物理隔离”不同分支的上下文。我见过太多同事为了切分支把半成品代码 stash 来 stash 去最后搞混了导致功能改到一半的代码被合并到线上。有了 worktree这种低级失误可以从物理层面避免。5. 高频命令速查与疑难杂症翻车实录到这一步基本功已经扎实了剩下的是在真实场景里遇到问题时如何排查和解决。这一章我把自己实战中碰到的高频问题和对应解法整理成一份“翻车速查表”也有不少是从同事和论坛里收集到的典型病例按需查表即可。5.1 最常用命令清单看图施工不如直接背下来与其每次都要去翻教程不如记住下面这份高频命令清单。它是按照日常操作的时间顺序排列的场景命令说明查看状态git status显示工作区和暂存区的差异是所有操作的起点暂存文件git add 文件名或git add ..代表所有改动但用之前先确认git status里没有无关文件提交git commit -m 提交信息-m后面跟提交说明查看历史git log --oneline一行展示一条提交记录简洁高效查看某次提交改了什么git show 提交ID提交ID 可以从git log中复制推送git push推送到远程仓库当前分支的跟踪分支拉取git pull等同于git fetch加git merge从远程拉取并合并到当前分支撤销暂存git reset HEAD 文件名把已暂存的文件退回到工作区丢弃工作区改动git checkout -- 文件名危险操作会让文件回到最近一次提交的状态改动全部丢失暂存当前改动git stash把当前工作区改动临时保存起来让工作区干净恢复暂存git stash pop恢复最近一次 stash 的改动这些命令不需要一次全记住用到的时候查表多敲几次自然就形成肌肉记忆了。5.2 改错提交信息怎么办git commit --amend 使用指南手滑把提交信息写错了或者发现上一次提交漏了一个文件别慌。只要还没推送到远程就可以用git commit --amend补救。最简单的用法git commit --amend -m 正确的新提交信息这个命令的作用是把上一次提交替换成一次新的提交因此可以同时修改提交说明和合计文件。如果你还需要补充文件进去先git add漏掉的文件再执行git commit --amend编辑器会打开让你修改提交说明保存退出即可。需要特别注意的是amend会改变提交记录的哈希值。所以永远不要对已经推送到远程的提交使用amend否则你本地历史就和远程历史对不上了下次 push 会被拒绝。如果你实在搞不定可以参考“强行推送”的解法但团队协作环境下一定要先和同事沟通因为这会覆盖远程分支历史影响所有人。5.3 高频报错与排查思路从提示语反推问题根源这里整理几个你在实际操作过程中大概率会遇到的问题“failed to fetch”或拉取失败。这类报错最常出现在网络不稳定的环境或者代理配置异常的情况下。排查思路先看是否走的是 HTTPS 地址如果是检查系统的代理设置再确认远程地址是否正确用git remote -v查看。如果换了网络环境清除 Git 的本地缓存重新拉取也有可能解决问题。还有一种情况是远程分支被删除了本地还留着跟踪记录执行git remote prune origin清理即可。“login failed. check api token or gitlab version.”这类提示通常出现在 GitLab 类的远程仓库上说明凭据失效或版本不兼容。优先检查是否配置了 Personal Access Token并且 token 是否有对应仓库的权限。如果你的 GitLab 版本比较老而本地 Git 版本太新也可能会出现鉴权协议不兼容的情况这时更新 GitLab 或改用 SSH 方式就能绕开。“detached HEAD”游离状态。如果你通过git checkout 提交ID直接检出到某个历史提交Git 会提示你处于 dettached HEAD 状态这时你看到的代码是“历史快照”在这个状态下修改代码会有风险一旦切走改动容易丢失。解决方法是立即创建一个新分支来承接修改git switch -c 新分支名。“git目录泄露”相关的话题。这通常不是开发场景里的报错而是安全审计时发现的问题。.git目录如果被错误地暴露在 Web 服务根目录下攻击者可以通过特殊路径读取里面的配置文件甚至下载整个仓库历史。这是一个安全警告如果你的项目是网站应用务必确认.git目录不能被外部直接访问。6. 配置细节优化让 VS Code Git 的组合更好用基础功能都跑通了再分享几个能明显提升日常使用体验的配置细节。这些属于锦上添花但一旦配上你会发现自己回不到原来的工作流。6.1 让 VS Code 默认集成终端使用 Git BashVS Code 默认的集成终端在 Windows 上是 PowerShell虽然也能敲git命令但 Git Bash 支持更多的 Unix 命令比如ls、grep、cat很多路径写法也更顺手。设置方法按CtrlShiftP打开命令面板输入Terminal: Select Default Profile选择 “Git Bash”。此后按Ctrl打开终端时进来就是 Git Bash。这个细节的额外好处是Git Bash 自带路径补全和命令历史配合 VS Code 的多终端布局我一般是左边跑git status和git log右边开着编辑器实时查看代码效率比单纯依赖图形面板高不少。6.2 diff 对比与可视化提交历史VS Code 内置的文件比较功能非常能打。在源代码管理面板里点击某个发生改动的文件编辑器会以左右两栏的方式展示差异红色区域是删除的内容绿色区域是新增的内容右侧还有一个“还原”按钮可以把某个文件的改动整体撤销。在 code review 场景下这个视图比在终端里敲git diff直观得多。想看整个项目的提交历史树可以装上Git Graph扩展。它会用图形化方式展示所有分支、提交节点和合并关系你可以直接点击任意节点查看那次提交改了哪些文件。这个扩展用它看复杂的合并历史比任何终端命令都清晰。6.3 免去日常输入提交时自动暂存所有改动如果你习惯小步快跑式的提交每次都要手动点“”号暂存文件其实挺烦的。VS Code 的源代码管理面板右上角有个“...”菜单里面有个选项叫“提交已暂存的更改”和“全部提交”后者会一次性把所有改动都暂存并提交。如果确认工作区里没有不该提交的无关文件直接用“全部提交”速度飞快。但这里我也要提个醒“全部提交”是把双刃剑。如果你在git status里看到了一些不该提交的临时文件比如.env配置文件、node_modules一定要先排除。通常的做法是在项目根目录创建一个.gitignore文件把不需要追踪的文件名列进去例如node_modules/ dist/ .env *.log.gitignore提交一次以后这些文件就永远不出现在改动列表里了。很多新手一开始没在意这个结果把本地配置和依赖目录推到远程轻则仓库臃肿重则泄露数据库密码属于开发里最基本的“卫生习惯”。7. 从一次真实任务看完整流程为了让整套流程有一个完整落地感最后我用一个真实的小任务把前面所有知识点串起来。假设今天有个需求给项目加一个“关于我们”页面。先在master分支上拉一个功能分支feature-about-page在分支上创建about.html写几行内容。用 VS Code 的源代码管理面板把文件暂存并提交提交信息写“新增关于我们页面”。页面做完了切回master分支执行合并git checkout master git merge feature-about-page如果你的同事也在这段时间往master上推了代码合并时有可能冲突。按前面讲的方法在 VS Code 里把冲突标识清理干净重新暂存并提交然后推送git push推完之后把已经合并过的功能分支删掉保持仓库干净git branch -d feature-about-page如果你还想把这次改动同步到线上服务器可以在服务器上执行git pull代码就自动更新了。这套流程跑熟之后你会发现 Git 并不可怕它本质上就是一套“保存游戏存档、可以读档、支持多人同时玩”的机制。刚开始确实要适应它“多一步暂存再提交”的节奏但一旦养成习惯它对代码安全的保障是实打实的——我再也没有因为误删文件或者改错了代码而欲哭无泪过。我个人在实际使用中的体会是不要急着把图形界面能做的操作都学会先把git status、git add、git commit、git push、git pull这几个命令形成肌肉记忆图形界面作为一种辅助和检视工具来配合使用效率和理解深度都会上一个台阶。工具永远是为了保护你的劳动成果和让协作更顺畅搞懂原理之后你会发现自己对代码的掌控感完全不一样。
VS Code与Git实战指南：从安装配置到分支合并与冲突解决
1. 先把“锅碗瓢盆”备齐VS Code 与 Git 安装扫盲先说点实在的。VS Code 现在已经是绝大多数开发者默认的编辑器而 Git 是绕不开的版本管理工具。你把这两个东西装好、配好等于有了一个能干活、能后悔、能协作的开发环境。这篇教程面向真正的零基础用户我尽量把每一步都拆开讲清楚包括安装时哪些选项该勾、哪些不该勾以及为什么。1.1 vs code 下载与安装别一路狂点“下一步”VS Code 的官网地址是 code.visualstudio.com注意别进到第三方下载站。主页上有个很显眼的蓝色下载按钮系统会自动识别你的操作系统Windows 用户直接点“Windows User Installer 64-bit”即可。下载完双击安装包前几步都保持默认但到“选择附加任务”这一步千万停一下。这里有几个关键选项直接影响你后续用 Git 的体验“将‘通过 Code 打开’操作添加到 Windows 资源管理器目录上下文菜单”建议勾上右键文件夹直接用 VS Code 打开比先开编辑器再找路径高效太多。“将‘通过 Code 打开’操作添加到 Windows 资源管理器文件上下文菜单”同上处理单个文件时很方便。“添加到 PATH”必须勾选。这个决定了你能不能直接在终端里输入code命令启动编辑器。很多教程没强调这个导致后面配环境时一脸懵。安装完成后首次打开界面默认是英文的。按CtrlShiftX打开扩展面板搜索“Chinese (Simplified)”安装微软官方的简体中文语言包重启后就是中文界面了。顺手把Prettier - Code formatter、ESLint这类常用扩展也装上不过初期不装也不影响 Git 学习。注意如果你是 Win7 系统需要下载旧版 VS Code1.70 及以下。新版早已停止对 Win7 的支持装上去会提示无法启动。1.2 Git 安装配置三个必须手动处理的坑Git 的 Windows 版本叫 Git for Windows官网 git-scm.com下载速度慢的话可以找国内镜像。安装过程比 VS Code 曲折不少几个关键节点说清楚第一个坑PATH 环境变量。安装到“Adjusting your PATH environment”这一步默认选的是“Git from the command line and also from 3rd-party software”。这个选项意味着 Git 的命令可以在 CMD、PowerShell、Git Bash 里通用。别选“Use Git and optional Unix tools from the Command Prompt”那个会把 Git 自带的 Unix 工具覆盖进系统 PATH容易和系统原有命令冲突没必要冒这个险。第二个坑行尾转换Line Ending Conversions。这一步叫“Configuring the line ending conversions”默认是“Checkout Windows-style, commit Unix-style line endings”。也就是检出代码时转成 Windows 的 CRLF提交时统一转成 LF。这个选项对跨平台协作是最稳妥的别动它。等你以后和 Linux/macOS 同事协作时就会感谢这个默认设置它避免了一大批“明明代码没改却提示整个文件都变了”的尴尬情况。第三个坑终端模拟器。“Choosing the default terminal emulator”这一步默认“Use MinTTY”就好。MinTTY 的缩放、复制粘贴、滚动体验都比 Windows 自带的 Console 强。安装完成后打开任意终端输入git --version能输出版本号就说明成了。接着配置你的身份信息这是 Git 提交记录里显示的作者名称和邮箱务必和你的 Gitee/GitHub 账号保持一致git config --global user.name 你的名字 git config --global user.email 你的邮箱查看配置是否生效git config --global --list这一步做不好后面所有 commit 记录上显示的都不是你团队协作时找人背锅都找不对人。2. 第一次提交代码理解工作区、暂存区、本地仓库安装配置只是热身真正理解 Git 是干什么的得从第一次提交开始。很多新手被 Git 的各种概念劝退其实核心就三个区域工作区就是你文件夹里看到的那些文件、暂存区临时存放你要提交的改动、本地仓库Git 真正保存历史记录的地方。弄懂这三个概念后面所有操作都能串联起来。2.1 用 VS Code 初始化仓库不用敲命令也能行假设你现在手上有一个项目文件夹里面放着index.html、style.css等文件或者干脆是空的。用 VS Code 打开这个文件夹点击左侧边栏的“源代码管理”图标长得像分叉的树枝会看到一个“初始化仓库”按钮。点击之后VS Code 会在项目根目录生成一个.git文件夹这就是本地仓库的数据库。此时你的文件还处于“未跟踪”状态左侧面板会列出所有文件每个文件名后面都有一个字母UUntracked未跟踪。这个阶段我可以直接告诉你一个实操心得别急着点“提交”先理解你看到了什么。左侧面板其实就是 Git 的图形化状态中心它显示的是当前工作区相对于暂存区的差异。文件名的变化无非三种U表示新文件还没被 Git 管理M表示已跟踪文件被修改过D表示文件被删除了。看懂了这些字母你就看懂了 Git 一半的状态提示。2.2 git add 与 git commit 的底层逻辑为什么要有暂存区在 VS Code 中将鼠标悬停在某个文件上点击右侧的“”号文件就会从“未跟踪”变成“已暂存”左侧面板会出现一个“暂存的更改”分组。这个“”号操作对应命令行里的git add。为什么要有暂存区直接讲一个真实场景你就明白了你在一个文件里改了功能 A 和功能 B 两处代码如果一次性全部提交未来查找历史时你很难快速定位到具体是哪一处改动引入了 bug。有了暂存区你可以只暂存功能 A 相关的代码行提交一次并写上注释“完成功能A”然后再暂存功能 B 的代码再提交一次。这样提交历史干净清晰将来排查问题时git log里每条记录都对应一个独立的功能点效率天差地别。暂存完所有文件后在顶部输入框里填上提交信息比如“初始化项目添加首页结构”然后点击“提交”按钮。这个操作对应git commit。提交成功后左侧面板会显示“没有暂定的更改”文件后面的字母消失了说明所有改动都进了本地仓库。这时你可以在终端里验证一下git log --oneline会看到类似a1b2c3d 初始化项目添加首页结构的输出这就是你项目历史上的第一个里程碑。每一次提交就像给当前的项目状态拍了一张照片随时可以回放、对比、还原。提示提交信息不是随便写的。建议遵循“动词 对象 目的”的格式比如“修复登录页面在移动端样式错位的问题”而不是“改了 bug”。一份清晰的提交历史是代码最好的文档。3. 连接远程仓库Gitee 的 SSH 指纹与推拉同步本地仓库解决的问题是“我自己后悔了能找回”但真正的工作场景是多人协作、多设备同步这时候就需要远程仓库。国内开发者用得最多的是 Gitee码云也有不少团队直接上 GitHub 或公司内部的 GitLab。每一步的流程大同小异我就以 Gitee 为例把从新建仓库到推拉的完整链路走一遍。3.1 生成 SSH Key为什么 HTTPS 方式总是要输密码很多人在第一次接触远程仓库时会直接选择 HTTPS 地址进行 clone然后发现每次 push 或 pull 都要输入账号密码烦不胜烦。根本原因在于HTTPS 协议每次操作都要向服务器验证你的身份。解决方式是改用 SSH 协议让 Git 识别你本机的专属身份标识也就是 SSH Key。打开 Git Bash或 VS Code 的终端输入ssh-keygen -t rsa -b 4096 -C 你的邮箱一路回车可以生成的密钥默认存放在C:\Users\你的用户名\.ssh\目录下其中id_rsa是私钥绝不能泄露id_rsa.pub是公钥需要上传到 Gitee。私钥只保存在你自己电脑上任何场景都不应该发给别人。查看公钥内容cat ~/.ssh/id_rsa.pub复制输出的整段内容登录 Gitee点击头像进入“设置”找到“SSH 公钥”把内容粘贴进去标题随意。这一步相当于告诉 Gitee“持有这把公钥对应私钥的机器是我本人请允许它访问我的仓库。”验证是否配置成功ssh -T gitgitee.com看到 “Hi xxx! Youve successfully authenticated” 之类的提示说明 SSH 链路已经通了。这个过程中我也踩过一次坑有的同事在 Windows 上生成密钥时会一不小心直接生成到系统管理员目录下导致 VS Code 里使用 Git 时找不到密钥。如果你配置完还是提示权限拒绝先检查~/.ssh路径里的文件是否真的存在再检查环境变量HOME是否被改过。3.2 在 Gitee 新建远程仓库并完成首次推送登录 Gitee 后点击右上角的“”号选择“新建仓库”。仓库名称自定比如my-first-project。这里有个细节是否勾选“初始化仓库”。如果你本地已经有代码了就不要勾选“使用 Readme 初始化这个仓库”避免本地和远程的历史互不相干第一次 push 时还得处理冲突。等仓库创建好页面上会给出两种远程地址选择 SSH 格式的那一条复制下来。回到 VS Code 终端本地仓库关联远程仓库git remote add origin gitgitee.com:你的用户名/my-first-project.gitorigin是远程仓库的默认别名你可以理解成“远端地址的快捷方式”。以后git push origin master就等于把本地代码推送到这个远程仓库。首次推送git push -u origin master-u参数的作用是建立本地分支与远程分支的跟踪关系以后直接输入git push就能推送不用每次都写完整的origin master。推送成功后打开 Gitee 仓库页面你会看到所有文件已经同步上去了。如果你换了台电脑想把这套代码拿下来就在新机器上执行git clone gitgitee.com:你的用户名/my-first-project.gitclone会把远程仓库的完整历史、所有分支都拉到本地并且自动关联好origin。这一步做完远程同步链路就完整了剩下的就是日常的推push和拉pull。3.3 解决 vs code 中 git 每次都要输入账号密码的问题这是搜索热度非常高的一个问题也是在 HTTPS 方式下最常见的问题。核心原因就是第一小节里说的HTTPS 每次操作都要求身份认证。解法有两条路方法一切换为 SSH 克隆地址。把远程地址改掉git remote set-url origin gitgitee.com:你的用户名/my-first-project.git之后所有操作走 SSH不再要求输入密码。方法二启用 Git 凭据管理器。依次点击开始菜单里的“Git”文件夹下的“Git Credential Manager”或者安装 Git for Windows 时自带这个组件。在 Windows 凭据管理器控制面板 - 用户账户 - 凭据管理器里把 Gitee 的账号密码存进去下次操作时 Git 会自动读取不用手动输入。我实测下来这个方式和 VS Code 结合的体验也不差但如果你经常在命令行操作还是建议直接走 SSH少一层中间环节。4. 分支、合并与冲突团队协作绕不开的坎单个分支只能满足单机自嗨真正的项目开发一定涉及多人并行开发。Git 的分支模型是它最强大的设计也是初学者最容易卡壳的地方。这一章讲透分支的创建、切换、合并以及最让人头疼的冲突解决。4.1 分支的本质一个指向提交记录的“可移动指针”先破除一个误解分支并不是复制了一套代码。在 Git 内部分支其实只是一个指向某一次提交的指针。当你新建一个分支Git 只是创建了一个指向当前提交的新指针成本极低所以你随便开分支不用担心仓库体积膨胀。在 VS Code 中点击左下角的分支名默认是master或者main会弹出分支操作面板选择“创建新分支”输入如feature-login回车确认。此时你就已经切换到了新分支在这个分支上做的所有提交都不会影响master分支。团队协作的标准流程是这样的每个人从master拉出一个自己的功能分支比如feature-login、feature-pay各干各的互不干扰。等某个功能完成并经过测试后再把分支合并回主干。这个模式的妙处在于“降低并发干扰”你在feature-login里改文件同事在feature-pay里改文件两人操作互相隔离。即使某人的改动把代码搞崩了也不会影响主分支其他同事的功能依然能正常合并上线。4.2 合并分支与解决冲突的实操案例功能开发完成要把feature-login合并到master。先切换到目标分支也就是你想把改动合并到哪个分支就先切到哪个分支git checkout master然后执行合并git merge feature-login多数情况下如果两个分支各自改动的文件互不重叠Git 能自动完成合并。但总会有意外你和同事同时修改了同一个文件的同一个区域Git 无法判断哪份改动才是最终想要的就会提示“冲突CONFLICT”。VS Code 对冲突的处理非常直观它会把冲突文件用颜色块和文字标记清晰地展示出来。冲突区域通常长这样 HEAD 你当前分支master的代码 让你想合并进来的分支feature-login的代码 feature-login你需要人工判断保留哪一份或者把两边内容都整合成一份。在 VS Code 的“源代码管理”面板里冲突文件会显示一个C标记。点击文件进入编辑器VS Code 上方会提供四个操作选项“接受当前更改”“接受传入更改”“接受两者更改”“比较更改”。常规操作是点击“接受两者更改”然后手动调整细节。注意解决完冲突后一定要再次点击“”号暂存该文件然后重新提交一次。这个提交相当于“缝合”两个分支的差异是冲突解决的收尾动作。忘了暂存就提交会提示“有未合并的文件无法提交”。4.3 git worktree同一项目多分支并行开发的进阶姿势经常面临这种场景线上出了紧急 bug但你手头正在一个尚未完成的功能分支里还不想提交半成品。如果切回主分支就得 stash 暂存当前改动或者强行提交如果直接切换分支Git 会因为工作区不干净而禁止你切换。这时候用git worktree就舒服得多。git worktree add ../my-project-hotfix master这个命令会在项目相邻目录../my-project-hotfix里新建一个工作区并检出master分支。你可以在这个新目录里开 VS Code、改代码、提交、推送完全不碰你主目录里正在开发的分支。都处理完后再回到原来的目录继续干活。用完之后清理git worktree remove ../my-project-hotfix这个功能最大的价值是让我们“物理隔离”不同分支的上下文。我见过太多同事为了切分支把半成品代码 stash 来 stash 去最后搞混了导致功能改到一半的代码被合并到线上。有了 worktree这种低级失误可以从物理层面避免。5. 高频命令速查与疑难杂症翻车实录到这一步基本功已经扎实了剩下的是在真实场景里遇到问题时如何排查和解决。这一章我把自己实战中碰到的高频问题和对应解法整理成一份“翻车速查表”也有不少是从同事和论坛里收集到的典型病例按需查表即可。5.1 最常用命令清单看图施工不如直接背下来与其每次都要去翻教程不如记住下面这份高频命令清单。它是按照日常操作的时间顺序排列的场景命令说明查看状态git status显示工作区和暂存区的差异是所有操作的起点暂存文件git add 文件名或git add ..代表所有改动但用之前先确认git status里没有无关文件提交git commit -m 提交信息-m后面跟提交说明查看历史git log --oneline一行展示一条提交记录简洁高效查看某次提交改了什么git show 提交ID提交ID 可以从git log中复制推送git push推送到远程仓库当前分支的跟踪分支拉取git pull等同于git fetch加git merge从远程拉取并合并到当前分支撤销暂存git reset HEAD 文件名把已暂存的文件退回到工作区丢弃工作区改动git checkout -- 文件名危险操作会让文件回到最近一次提交的状态改动全部丢失暂存当前改动git stash把当前工作区改动临时保存起来让工作区干净恢复暂存git stash pop恢复最近一次 stash 的改动这些命令不需要一次全记住用到的时候查表多敲几次自然就形成肌肉记忆了。5.2 改错提交信息怎么办git commit --amend 使用指南手滑把提交信息写错了或者发现上一次提交漏了一个文件别慌。只要还没推送到远程就可以用git commit --amend补救。最简单的用法git commit --amend -m 正确的新提交信息这个命令的作用是把上一次提交替换成一次新的提交因此可以同时修改提交说明和合计文件。如果你还需要补充文件进去先git add漏掉的文件再执行git commit --amend编辑器会打开让你修改提交说明保存退出即可。需要特别注意的是amend会改变提交记录的哈希值。所以永远不要对已经推送到远程的提交使用amend否则你本地历史就和远程历史对不上了下次 push 会被拒绝。如果你实在搞不定可以参考“强行推送”的解法但团队协作环境下一定要先和同事沟通因为这会覆盖远程分支历史影响所有人。5.3 高频报错与排查思路从提示语反推问题根源这里整理几个你在实际操作过程中大概率会遇到的问题“failed to fetch”或拉取失败。这类报错最常出现在网络不稳定的环境或者代理配置异常的情况下。排查思路先看是否走的是 HTTPS 地址如果是检查系统的代理设置再确认远程地址是否正确用git remote -v查看。如果换了网络环境清除 Git 的本地缓存重新拉取也有可能解决问题。还有一种情况是远程分支被删除了本地还留着跟踪记录执行git remote prune origin清理即可。“login failed. check api token or gitlab version.”这类提示通常出现在 GitLab 类的远程仓库上说明凭据失效或版本不兼容。优先检查是否配置了 Personal Access Token并且 token 是否有对应仓库的权限。如果你的 GitLab 版本比较老而本地 Git 版本太新也可能会出现鉴权协议不兼容的情况这时更新 GitLab 或改用 SSH 方式就能绕开。“detached HEAD”游离状态。如果你通过git checkout 提交ID直接检出到某个历史提交Git 会提示你处于 dettached HEAD 状态这时你看到的代码是“历史快照”在这个状态下修改代码会有风险一旦切走改动容易丢失。解决方法是立即创建一个新分支来承接修改git switch -c 新分支名。“git目录泄露”相关的话题。这通常不是开发场景里的报错而是安全审计时发现的问题。.git目录如果被错误地暴露在 Web 服务根目录下攻击者可以通过特殊路径读取里面的配置文件甚至下载整个仓库历史。这是一个安全警告如果你的项目是网站应用务必确认.git目录不能被外部直接访问。6. 配置细节优化让 VS Code Git 的组合更好用基础功能都跑通了再分享几个能明显提升日常使用体验的配置细节。这些属于锦上添花但一旦配上你会发现自己回不到原来的工作流。6.1 让 VS Code 默认集成终端使用 Git BashVS Code 默认的集成终端在 Windows 上是 PowerShell虽然也能敲git命令但 Git Bash 支持更多的 Unix 命令比如ls、grep、cat很多路径写法也更顺手。设置方法按CtrlShiftP打开命令面板输入Terminal: Select Default Profile选择 “Git Bash”。此后按Ctrl打开终端时进来就是 Git Bash。这个细节的额外好处是Git Bash 自带路径补全和命令历史配合 VS Code 的多终端布局我一般是左边跑git status和git log右边开着编辑器实时查看代码效率比单纯依赖图形面板高不少。6.2 diff 对比与可视化提交历史VS Code 内置的文件比较功能非常能打。在源代码管理面板里点击某个发生改动的文件编辑器会以左右两栏的方式展示差异红色区域是删除的内容绿色区域是新增的内容右侧还有一个“还原”按钮可以把某个文件的改动整体撤销。在 code review 场景下这个视图比在终端里敲git diff直观得多。想看整个项目的提交历史树可以装上Git Graph扩展。它会用图形化方式展示所有分支、提交节点和合并关系你可以直接点击任意节点查看那次提交改了哪些文件。这个扩展用它看复杂的合并历史比任何终端命令都清晰。6.3 免去日常输入提交时自动暂存所有改动如果你习惯小步快跑式的提交每次都要手动点“”号暂存文件其实挺烦的。VS Code 的源代码管理面板右上角有个“...”菜单里面有个选项叫“提交已暂存的更改”和“全部提交”后者会一次性把所有改动都暂存并提交。如果确认工作区里没有不该提交的无关文件直接用“全部提交”速度飞快。但这里我也要提个醒“全部提交”是把双刃剑。如果你在git status里看到了一些不该提交的临时文件比如.env配置文件、node_modules一定要先排除。通常的做法是在项目根目录创建一个.gitignore文件把不需要追踪的文件名列进去例如node_modules/ dist/ .env *.log.gitignore提交一次以后这些文件就永远不出现在改动列表里了。很多新手一开始没在意这个结果把本地配置和依赖目录推到远程轻则仓库臃肿重则泄露数据库密码属于开发里最基本的“卫生习惯”。7. 从一次真实任务看完整流程为了让整套流程有一个完整落地感最后我用一个真实的小任务把前面所有知识点串起来。假设今天有个需求给项目加一个“关于我们”页面。先在master分支上拉一个功能分支feature-about-page在分支上创建about.html写几行内容。用 VS Code 的源代码管理面板把文件暂存并提交提交信息写“新增关于我们页面”。页面做完了切回master分支执行合并git checkout master git merge feature-about-page如果你的同事也在这段时间往master上推了代码合并时有可能冲突。按前面讲的方法在 VS Code 里把冲突标识清理干净重新暂存并提交然后推送git push推完之后把已经合并过的功能分支删掉保持仓库干净git branch -d feature-about-page如果你还想把这次改动同步到线上服务器可以在服务器上执行git pull代码就自动更新了。这套流程跑熟之后你会发现 Git 并不可怕它本质上就是一套“保存游戏存档、可以读档、支持多人同时玩”的机制。刚开始确实要适应它“多一步暂存再提交”的节奏但一旦养成习惯它对代码安全的保障是实打实的——我再也没有因为误删文件或者改错了代码而欲哭无泪过。我个人在实际使用中的体会是不要急着把图形界面能做的操作都学会先把git status、git add、git commit、git push、git pull这几个命令形成肌肉记忆图形界面作为一种辅助和检视工具来配合使用效率和理解深度都会上一个台阶。工具永远是为了保护你的劳动成果和让协作更顺畅搞懂原理之后你会发现自己对代码的掌控感完全不一样。