企业官网建设流程全解析

写代码这件事，装好编辑器只是入门第一步，真正让你从“随便写写”变成“正经开发”的，是版本控制。而 VSCode + Git 这套组合，就是当下最主流、也最友好的搭档：VSCode 负责写、看、改、调试，Git 负责记录每一次改动、让你随时回到过去，还支持多人同时在一个项目上干活而不互相踩踏。最让我想推荐的是，在 VSCode 里操作 Git，绝大多数场景根本不用背命令，鼠标点几下就能完成提交、推送、拉取、分支合并，这正是“可视化”三个字最值钱的地方。

这篇保姆级指南，我会把从零开始装 VSCode、装 Git、做基础配置、写第一行 Git 命令、日常提交推送、分支合并可视化操作、git commit --amend、SSH 免密，到新手最容易卡住的报错排查，全部按实操顺序过一遍。适合三类人：刚接触编程、被命令行吓住的同学；从其他 IDE 转过来、想快速上手 VSCode 的开发者；以及想给团队写新人手册的老手。内容全部来自我实际装机、写代码、带新人过程中验证过的方式，我会把每一步的点在哪里、为什么这么选、有哪些坑，全部说清楚，你照着点就行。

1. 准备工作：先把 VSCode 和 Git 装好

1.1 VSCode 下载安装：别小看这几个勾选项

先去官网 code.visualstudio.com，首页那个蓝色 Download 按钮就是当前主版本，页面会自动识别你的系统。Windows 用户会看到两个版本：User Installer（用户版）和 System Installer（系统版）。

这两个怎么选？我的建议是：自己电脑上装，选 System Installer；公司电脑、公用电脑、没有管理员权限的机器，选 User Installer。原因很简单，System 版装到 Program Files，启动更快、右键菜单处理得更干净，但需要管理员权限；User 版装在当前用户目录，不弹 UAC 授权框，适合受限环境。如果你只是临时用一下，两个版本功能没有任何区别，不用纠结太久。

真正值得留意的是安装向导里几个勾选项，我强烈建议全勾：

• 添加到 PATH：装完之后，你可以在任意终端敲code .，直接用 VSCode 打开当前目录。这个习惯一旦养成，打开项目的速度会快非常多。
• 将“通过 Code 打开”添加到文件和目录上下文菜单：也就是右键文件夹时出现“用 VSCode 打开”，配合上一个选项，日常开项目基本不用先启动 VSCode 再找文件夹。
• 注册为 .git 文件的默认编辑器：如果你装了 Git，它会接管 Git 配置文件（比如 .gitconfig）的打开方式，以后双击就能看，省事。

装完打开 VSCode，全是英文界面看不懂很正常。按Ctrl+Shift+X打开扩展面板，搜“Chinese”，装“中文（简体）语言包”，右下角会弹“更改语言并重启”；或者按Ctrl+Shift+P输入configure display language，选择中文然后重启。

再多说一句插件的事情。底层逻辑是：VSCode 本身只是“编辑器 + 文件管理器”，语言支持、格式化、调试这些功能全靠扩展来补。以下几类插件属于“装了就回不去”的类型：

• GitLens：把每一行代码的作者、提交时间、提交说明直接显示在代码里，还能可视化地看提交历史、对比任意两个版本。Git 可视化体验直接上一个台阶。
• Git History：专门看单个文件的修改历史，哪个版本改了哪几行，一目了然。
• Prettier：代码格式化神器，保存时自动整理格式，解决“代码风格不统一”的争吵。
• 语言类插件：写 Python 装“Python”（微软官方），写 C/C++ 装“C/C++”（微软官方），写前端装“ES7+ React/React-Router/Redux snippets”，调试浏览器页面装“Live Server”。

最近很火的还有 Codex、Claude Code 这类 AI 编程助手插件，装上之后能在编辑器里直接对话、生成代码。我的态度是：可以装，但别过度依赖，先把基础命令和流程弄清楚。AI 是放大器，不是替代品。

如果官网下载实在慢，可以搜一些开源软件镜像站下载，版本可能滞后一点，新手建议还是以官网优先。

1.2 Git 安装与环境配置：两个全局配置躲不掉

Git 的下载一样是官网优先：git-scm.com，点 Downloads 会自动识别 Windows，跳转到 Git for Windows 的安装包。Git 安装向导里选项不少，新手容易晕。实际只需要在三个地方认真选一下，其余保持默认：

• 默认分支名：建议选 main。现在的 GitHub、Gitee 新仓库默认分支都是 main，如果本地是 master，远程是 main，推送时会出现“本地领先远程好几个提交却推不上去”的诡异情况，时长够你怀疑人生。
• 调整 PATH 环境：选第二项“Git from the command line and also from 3rd-party software”。这样 Git 装完，你在 Windows 的命令行、PowerShell、VSCode 内置终端里都能直接用git命令，不用额外折腾。
• 换行符处理：选第一项“Checkout Windows-style, commit Unix-style line endings”。这个问题藏在几乎每个项目里，简单说就是 Windows 换行是 \r\n，Linux/Mac 是 \n，Git 通过自动转换让仓库内部的换行格式统一。默认选项对新手最省事，团队协作后期再统一用 .gitattributes 约束。

装完打开任意终端（推荐直接用 VSCode 内置终端，快捷键Ctrl+~），跑一下：

git --version

能显示版本号就说明安装成功。这一步很多人卡住，原因基本是 PATH 那一步选错了，系统没把 git 命令认出来。解决办法是把 Git 安装目录下的cmd手动加到系统环境变量：默认路径是C:\Program Files\Git\cmd，在“系统属性 → 环境变量 → Path”里新增这条路径，重新打开终端就生效。

Git 装好后，还有两个全局配置必须做：

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

为什么是这两个？因为 Git 的每一次提交都会记录“谁在什么时候改了什么”，没有作者信息，Git 会直接拒绝提交，并弹出一段提示要求设置姓名和邮箱。这一步是后续一切操作的地基。另外注意，这两个值最好和你的代码托管平台账号保持一致，这样提交记录能对应到你的账号，不然平台会显示一个“未知作者”，团队协作时非常尴尬。

设置完可以用下面的命令检查：

git config --list

看到 user.name 和 user.email 出现在列表里就说明 OK。这条命令能看到全局配置明细，以后排查问题经常用到。

2. VSCode 里的 Git 可视化操作

2.1 初始化仓库与 .gitignore：让 Git 开始管你的项目

有了编辑器和 Git，下一步是让代码进入 Git 的管理范围。Git 管代码的单位叫“仓库”（Repository），一个项目文件夹就是一个仓库。

场景一：你已经有一个写了一半的项目，想从今天开始用 Git 管理。先在 VSCode 里用“文件 → 打开文件夹”打开项目根目录，然后按Ctrl+Shift+G（或者点击左侧的“源代码管理”图标）进入管理面板。这里会显示“文件夹当前未跟踪”，按钮是“初始化存储库”，点它，底层执行的就是git init。

初始化完成后，管理面板会列出项目里所有未被跟踪的文件，每个文件前面带字母 U（Untracked，未跟踪）。这个 U 的含义很重要：Git 看到这些文件了，但还没开始监控它们。

这个时候，我建议立刻做一件事：在项目根目录新建一个.gitignore文件。它的作用是告诉 Git：“以下文件不用管”。比如前端项目必须忽略node_modules，Python 项目要忽略.venv、__pycache__，编译产物要忽略build、dist。如果不建这个文件，Git 会把 node_modules 里成千上万的文件全部列出来，提交时又慢又乱，别人 clone 下来还会被迫下载一堆根本不需要的东西。

一个最简单能用的 .gitignore 示例：

node_modules/ dist/ build/ .venv/ __pycache__/ *.log .vscode/

node_modules这类依赖目录基本都是锁文件的，提交进仓库百害无一利；.vscode里通常是个人调试配置，团队要共享的例外。写完保存，源代码管理面板里这些文件就消失了，剩下的才是真正需要管的东西。VSCode 和 Git 的可视化配合，从这里就开始了。

2.2 第一次提交：暂存、提交、推送，三个动作串起来

现在文件状态还是 U，下一步是“暂存”（Staging），对应命令是git add。在源代码管理面板里，鼠标悬停在某个文件上会出现“+”号，点击就暂存了；想把所有改动一次性放进去，点“更改”右侧的“+”号。暂存后文件会移到上方的“暂存的更改”区域，状态变成 A（Added，新增）。

暂存和提交是两个步骤，可以这样理解：暂存是“把要打包的文件放进袋子里”，提交是“把袋子封口并贴一张便签”。便签上的内容，就是提交信息（commit message）。在“暂存的更改”上方有一个输入框，写清楚这次改了什么，然后点“提交”按钮（对勾图标），完成第一次本地提交，对应命令是git commit -m "xxx"。

提交信息怎么写？我个人的习惯是一句话讲清“解决了什么”，比如“修复登录页刷新白屏”“新增商品列表导出功能”。不要写“update”“fix”这种没人看得懂的废话，三个月之后你自己也看不懂。

提交完成后，改动还在本地。如果项目还没关联远程仓库，可以点源代码管理面板里的“发布分支”，或者打开终端手动操作。手动填远程地址的过程是：

git remote add origin https://github.com/你的用户名/仓库名.git git push -u origin main

第一条命令给本地仓库设置一个名为 origin 的远程地址。这个名字是约定俗成，几乎所有人都叫 origin，你叫别的也行，但没必要。第二条命令把本地 main 分支推送到远程，-u的意思是记住这条对应关系，以后直接git push就行。执行完去网页上看你的仓库，代码已经躺在那了。

2.3 日常开发循环：拉取、修改、提交、推送

日常开发其实就是四个动作的无限循环：

• 拉取：开工前先点源代码管理面板顶部的“拉取”按钮，或者命令面板里搜索Git: Pull，作用是把远程仓库最新提交合并到本地。
• 修改：正常写代码，VSCode 会在改过的文件前标 M（Modified，已修改）。
• 提交：写清楚提交信息，点提交，在本地留下记录。
• 推送：点“推送”按钮，把本地提交发到远程。

这个顺序里最容易出问题的是“改完了再拉取”。如果别人在这段时间也改了同一个文件，Git 合并时会提示冲突，你被迫停下来处理。所以我的习惯是：任何一次长时间写代码之前，先拉取一次，把同步成本降到最低。打个比方，出门旅行前先把行李箱整理好，路上再往里塞东西，总会手忙脚乱。

VSCode 里还有一个“同步更改”按钮，点一下相当于先拉取再推送，听起来很省事。但我对新手有个建议：初期尽量分开按。因为“同步”隐含了自动合并，万一有冲突，你没有感知，容易被复杂的合并结果吓到。先单独拉取、再单独推送，冲突出现时你能看清楚发生了什么。

2.4 分支、合并与冲突处理：可视化操作最甜的部分

分支可以理解成“平行的时间线”。在 main 主干上拉出属于自己的一条线，改动不影响主干，开发完再合并回去。多人协作时，每个人在各自分支上干活，互不干扰。

VSCode 的分支操作非常顺手。看编辑器左下角，会显示当前分支名，比如 main。点它会弹出分支菜单：

• 创建分支：选“创建分支”，输入名字回车，并自动切换过去。
• 切换分支：点开左下角分支名，列表里选任意分支点击即可。
• 合并分支：先在左下角切换到目标分支（比如 main），再点分支按钮 → “合并分支...”，在弹出的列表里选择想要合并进来的分支（比如 dev），回车确认。

如果合并过程没有冲突，VSCode 会直接完成，代码静默更新。有冲突时，源代码管理面板里冲突文件会多一个 C（Conflict）标记，打开文件会出现一个颜色分明的冲突编辑界面：上方是当前更改，下方是传入的更改，顶部一排按钮分别是“接受当前更改”“接受传入更改”“接受两者更改”“比较更改”。

• 当前更改：你当前所在分支（合并接收方）的代码。
• 传入的更改：被合并进来的分支的代码。

冲突的本质是两边都改了同一行，Git 不敢替你选，只能让人类来定。我的建议是这时候不要急着点按钮，先认真看看两边各自改了什么，再决定保留哪边、删掉哪边，或者两边都要，手动编辑后保存。冲突解决后，文件会从冲突状态进入暂存区，此时再做一个普通提交，合并就完成了。

3. 进阶操作：提交“后悔药”、历史回看与免密登录

3.1 git commit --amend：修改最后一次提交的两种场景

这个命令几乎所有团队都会用到。它的作用直白地说就是：把上一次提交“拆开”，重新组装。

场景一：提交信息写错了。比如想写“修复 bug”，手滑打成“修复 buh”，直接跑：

git commit --amend -m "修复 bug"

场景二：提交完之后发现漏了一个文件。先把漏掉的文件git add，再执行：

git commit --amend

这次可以不加-m，Git 会打开一个文本编辑器让你修改提交信息，你也可以不动直接保存关闭。这样漏掉的文件被并进上一次提交，历史记录里你是“一次性完成了一个完整提交”，整体干干净净。

为什么用 amend 而不是再补一个提交？因为历史干净是一方面，更关键的是：如果你的改动还没有推送，再补一个提交会污染本地日志；如果已经推送了再补，远程就会多出一个“补丁”性质的提交，不好看。amend 的意义是在尚未推送前，把最后一步做到位。

但这里有一条红线：amend 会生成一个新的提交对象，旧的提交会被替换掉。如果上一次提交已经推送到远程、可能被同事拉取过，就不要再用 amend。否则下一次 push 会因为历史分叉被拒绝，这时应该改用git revert，更安全。

顺带说一句，很多初学者在 VSCode 里找半天找不到 amend 按钮。我的建议是直接打开 VSCode 内置终端跑命令，这本来就是 Git 的活，鼠标点反而不如命令行直观。

3.2 撤销操作的三板斧：restore、reset、revert

“后悔”是高频需求，但你得分清楚自己想要哪一种后悔，用错命令会很伤：

• 只想放弃某个文件的改动：git restore 文件名，或者在源代码管理面板点文件旁的“放弃更改”。改动会丢失，慎用。
• 只想把暂存区的文件放回工作区：git restore --staged 文件名，文件从“暂存”回到“未暂存”，内容不动。这相当于“把这个文件从袋子里拿出来，但保留在桌面”。
• 想把所有改动一次性退回上次提交：git reset --hard HEAD。这是毁灭性的，所有未提交改动直接消失。我强烈建议，新手阶段能不碰--hard就不碰，操作前先git stash把当前工作暂存起来，给后悔留条后路。
• 想撤销一个已经推送的提交：git revert <commit的hash>。Git 会新建一条反向提交，把那次改动抵消掉。这是对公共历史最安全的撤销方式，因为它不改写历史，只追加新记录。

怎么拿到 commit 的 hash？在源代码管理面板顶部能看到提交列表，点击某条提交能看到完整信息；或者在终端跑git log --oneline，一行一条，清爽直观。

3.3 SSH 免密配置：配一次，从此告别输密码

用 HTTPS 地址 clone 和 push，每次都要输用户名和密码，现在 GitHub 甚至要求用 token，麻烦还容易输错。配置 SSH 密钥后，一劳永逸。

步骤很简单，打开终端：

ssh-keygen -t ed25519 -C "你的邮箱@example.com"

一路回车，默认会在用户主目录生成~/.ssh/id_ed25519（私钥）和~/.ssh/id_ed25519.pub（公钥）。私钥自己留在电脑里，公钥要放到代码托管平台。打开id_ed25519.pub，复制里面全部内容，去 GitHub 的 Settings → SSH and GPG keys → New SSH key，或者 Gitee 的“设置 → SSH 公钥”粘贴保存。

测试是否配置成功：

ssh -T git@github.com

看到successfully authenticated之类的提示就说明通了。之后 clone 仓库时，把 HTTPS 地址换成 SSH 格式：git@github.com:用户名/仓库名.git。

如果你以前已经用 HTTPS clone 过一个仓库，不想重新 clone，可以改远程地址：

git remote set-url origin git@github.com:用户名/仓库名.git

配置过程中最常见的报错是Permission denied (publickey)。按顺序排查：公钥是否完整复制，一定要复制.pub文件而不是私钥；是否粘贴到了正确的平台；测试地址是否和平台一致，GitHub 是git@github.com，Gitee 是git@gitee.com；Windows 下 Git 是否使用了正确的私钥。多数情况是公钥没复制全，少数情况是自定义了密钥文件名导致 Git 找不到，所以建议第一次配置时保持默认文件名。

顺便提一句，如果你实在不想碰 SSH，Windows 的 Git 也自带凭据管理器，第一次用 HTTPS 输入账号密码后会自动记住，后续同样免密。只是团队新同事配电脑时，SSH 依然是更通用的方案。

3.4 历史记录查看与版本对比：GitLens 让一切都可见

这一部分不用多讲命令，讲体验。VSCode 自带的源代码管理面板里就有一份提交列表，能看每次提交的信息和作者。但想看“某一行代码是谁在哪个提交里写的”，就要靠 GitLens。

GitLens 装上之后，每一行代码旁边都会显示最近一次修改它的提交信息、作者和日期。刚开始可能觉得信息有点密，可以在设置里改成鼠标悬停时显示。它还提供一个独立的“历史”面板，按分支、作者、日期分门别类地展示提交，想回退到某个版本看看当时的代码长什么样，点开提交直接浏览就行，不用辛辛苦苦切换分支。

对于代码评审和 bug 追溯，我最常用的动作是：在提交列表选中一条提交，右键 → “查看更改”，就能看到这个提交改了哪些文件、哪些行。两个提交之间想对比，按住 Ctrl 选中两条提交，右键比较即可。这套操作在命令行里要敲好几行，在 VSCode 里全是鼠标点选，可视化党的福音。

4. 踩坑实录：新手最容易报错的六个场景

4.1 fatal: not a git repository (or any of the parent directories): .git

这个报错翻译成大白话就是：你当前所在目录不是 Git 仓库。Git 向上找了半天，连父目录里都没有 .git 文件夹，直接罢工。

出现原因通常是：项目文件夹还没初始化过 Git；或者你在仓库的子目录里执行了某些操作，而 Git 找不到根目录；还有一种情况是文件夹路径里有特殊字符导致识别失败。

解决方式很简单：

git init

在你要管理的目录里执行初始化。如果这个目录本来应该是仓库，先确认是否打开了正确的文件夹。VSCode 里最简单的办法：文件 → 打开文件夹，重新选仓库根目录，而不是某个子目录。

4.2 git push 被拒绝：non-fast-forward

报错大意为“远程有本地没有的提交”，Git 拒绝你用旧历史覆盖新历史。

原因：其他人已经推送了新提交，或者你在别的机器上提交过忘记同步。解决方式：先git pull，把远程的提交合并到本地，处理可能的冲突，再重新git push。如果你非常确定要覆盖远程，比如这是你的个人临时分支，可以git push -f，但公共分支绝对不要这么干，否则会把同事的提交冲掉。

4.3 SSH 认证失败：Permission denied (publickey)

这个报错前面提过，这里给一个完整排查清单：

• 执行ssh-add -l，确认本地能识别密钥。
• 打开id_ed25519.pub，确认公钥完整复制到了平台。
• 确认测试地址和平台匹配，GitHub 用git@github.com，Gitee 用git@gitee.com，很多人拿 A 平台的流程去测 B 平台，自然失败。
• 确认当前仓库的 remote 地址是 SSH 格式而不是 HTTPS，用git remote -v查看。
• 如果电脑上有多个密钥，需要在用户主目录的~/.ssh/config里给不同域名指定不同的 IdentityFile。

4.4 合并冲突“怎么选都不对”

很多新手在冲突界面会不停试“接受当前”“接受传入”，结果发现要么自己的代码丢了，要么别人的逻辑没保留。

我的经验是：先读，再选。打开冲突文件，看上下两段各自来自哪边，理解两边做了什么修改。如果两边改的是不同区域，Git 根本不会报冲突；报冲突说明改动区域重叠，这时要结合业务逻辑判断。在你没看懂代码之前，不要点任何“接受”。改完之后，跑一遍测试或编译，确认没有语法和逻辑问题，再做提交。VSCode 解决的只是“文本合并”，不等于“逻辑正确”，这点一定记住。

实用小技巧：在冲突编辑器里按住 Alt+Shift，再点对应代码块，可以把某一方的整段内容带入，适合“这一整块都听我的”的场景。

4.5 VSCode 写 C 语言没有代码提示

这不是 Git 的问题，但新手也常问。没提示的常见原因，一是没装 C/C++ 扩展，二是没配置 includePath。

装完微软官方的“C/C++”扩展后，按Ctrl+Shift+P输入C/C++: Edit Configurations (UI)，在 includePath 里添加你的头文件目录。Windows 用户需要确认 MinGW 的路径在环境变量里，比如C:\mingw64\bin，否则连编译都过不去。

同理，Python 没提示通常是解释器没选对：按Ctrl+Shift+P输入Python: Select Interpreter，选你项目所在的虚拟环境，而不是系统全局 Python。这个坑我在配置无数台机器后确认，90% 的“没提示”都是解释器选错造成的。

4.6 整个文件都显示已修改，但 diff 内容一模一样

表现为git status里一堆 M，打开 diff 看内容完全相同。八成是换行符问题，有人用了 \r\n，有人用了 \n，Git 认为内容变了。

解决方案：Windows 上执行git config --global core.autocrlf true，统一本地配置；已经出过问题的项目，在根目录加.gitattributes，声明* text=auto，然后重新提交一次换行符规范。

写到这里，正文该讲的都讲完了。最后说两句这些年带新人的体会：最容易把 Git 用起来的路径，是先让鼠标把这些按钮点熟，再去学命令。VSCode 的可视化把 80% 的高频操作拆成了按钮，先会点，再理解，最后你会发现敲命令也没那么可怕。另一个习惯上的建议是：每天结束时做一次提交和推送。代码放在本地硬盘不算安全，放在远程仓库才算。最后送一个小技巧：提交信息尽量写成“动词 + 改动对象 + 结果”，比如“修复登录页在 Safari 下白屏的样式问题”。三个月后再翻历史，你一定会感谢当时把信息写清楚的自己。