企业官网建设流程全解析

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命令启动编辑器。很多教程没强调这个，导致后面配环境时一脸懵。

安装完成后首次打开，界面默认是英文的。按Ctrl+Shift+X打开扩展面板，搜索“Chinese (Simplified)”，安装微软官方的简体中文语言包，重启后就是中文界面了。顺手把Prettier - Code formatter、ESLint这类常用扩展也装上，不过初期不装也不影响 Git 学习。

注意：如果你是 Win7 系统，需要下载旧版 VS Code（1.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文件夹，这就是本地仓库的数据库。此时你的文件还处于“未跟踪”状态，左侧面板会列出所有文件，每个文件名后面都有一个字母U（Untracked，未跟踪）。

这个阶段我可以直接告诉你一个实操心得：别急着点“提交”，先理解你看到了什么。左侧面板其实就是 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 git@gitee.com

看到 “Hi xxx! You've 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 git@gitee.com:你的用户名/my-first-project.git

origin是远程仓库的默认别名，你可以理解成“远端地址的快捷方式”。以后git push origin master就等于把本地代码推送到这个远程仓库。

首次推送：

git push -u origin master

-u参数的作用是建立本地分支与远程分支的跟踪关系，以后直接输入git push就能推送，不用每次都写完整的origin master。推送成功后，打开 Gitee 仓库页面，你会看到所有文件已经同步上去了。

如果你换了台电脑，想把这套代码拿下来，就在新机器上执行：

git clone git@gitee.com:你的用户名/my-first-project.git

clone会把远程仓库的完整历史、所有分支都拉到本地，并且自动关联好origin。这一步做完，远程同步链路就完整了，剩下的就是日常的推（push）和拉（pull）。

3.3 解决 vs code 中 git 每次都要输入账号密码的问题

这是搜索热度非常高的一个问题，也是在 HTTPS 方式下最常见的问题。核心原因就是第一小节里说的：HTTPS 每次操作都要求身份认证。解法有两条路：

方法一：切换为 SSH 克隆地址。把远程地址改掉：

git remote set-url origin git@gitee.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 最常用命令清单：看图施工不如直接背下来

与其每次都要去翻教程，不如记住下面这份高频命令清单。它是按照日常操作的时间顺序排列的：

这些命令不需要一次全记住，用到的时候查表，多敲几次自然就形成肌肉记忆了。

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 Bash

VS Code 默认的集成终端在 Windows 上是 PowerShell，虽然也能敲git命令，但 Git Bash 支持更多的 Unix 命令，比如ls、grep、cat，很多路径写法也更顺手。设置方法：按Ctrl+Shift+P打开命令面板，输入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这几个命令形成肌肉记忆，图形界面作为一种辅助和检视工具来配合使用，效率和理解深度都会上一个台阶。工具永远是为了保护你的劳动成果和让协作更顺畅，搞懂原理之后，你会发现自己对代码的掌控感完全不一样。