企业官网建设流程全解析

写代码这件事，这几年最让我省心的组合就是 VSCode 加 Gitee。VSCode 负责本地编辑、调试、跑插件，Gitee 负责代码托管、版本回溯、团队协作，两个一接上，写项目从零到上线基本不用离开编辑器。这篇教程我按自己从踩坑到熟练的全过程来写，把 VSCode 安装、Gitee 仓库创建、SSH 密钥配置、代码克隆推送、常见报错处理全部串一遍，尽量少说废话，照着做就能跑通。不管你是刚学编程的学生，还是想把手头项目托管到 Gitee 的开发者，这套流程都适用。

1. 环境准备：先把 VSCode 和 Git 装利索

1.1 VSCode 下载安装与汉化

VSCode 全称 Visual Studio Code，是微软出的一款免费开源编辑器，轻量但扩展性极强，装完基础体积才几百兆，却几乎能胜任任何语言的开发。下载时直接去官方渠道拿安装包，认准 Stable 稳定版，别碰 Insider 预览版，除非你想当小白鼠。

安装过程基本一路下一步，但有几个选项值得留意：

• 勾选“添加到 PATH”：这个一定要勾上，否则后面在终端敲code命令打开编辑器可能没反应。
• 勾选“通过 Code 打开”操作菜单：勾选后右键文件夹就能直接用 VSCode 打开，日常操作方便很多。
• 关联文件类型可以全选，也可以不选，影响不大。

装完默认是英文界面，想换成中文很简单：打开左侧扩展面板（快捷键Ctrl+Shift+X），搜索“Chinese (Simplified)”，安装微软官方出的中文语言包，装完右下角会提示重启。重启后菜单栏就是中文了。这个中文语言包只改界面，不影响代码和终端输出，放心用。

1.2 Git 安装与基础验证

VSCode 本身只负责编辑，代码版本管理靠的是 Git。Gitee 是远程仓库，本地代码要推上去，必须借助 Git 来完成。先检查系统里有没有装过：

git --version

如果提示找不到命令，就去 Git 官网下载对应系统的安装包。在 Windows 上安装时，有几个容易误解的选项：

• 默认编辑器选择：可以选择用 VSCode，后面用 Git 的时候会自动唤起。
• 调整 PATH 环境：选“Git from the command line and also from 3rd-party software”，这条最稳，确保命令在任何终端都能用。
• 换行符转换：Windows 用户选第一个“Checkout Windows-style, commit Unix-style line endings”就好，这样团队里混用 Windows 和 Mac 时不容易出现换行符混乱的问题。

装完重新开一个终端，输入git --version能输出版本号就说明没问题。还有一句很关键的话：Git 第一次使用要交代身份，因为每次提交都会记录作者信息。设置命令如下：

git config --global user.name "你的Gitee用户名" git config --global user.email "你注册Gitee的邮箱"

别小看这两条，不设置的话，第一次 commit 会报错或者提交记录显示一堆乱码。

2. Gitee 端准备：仓库、许可证与 SSH 密钥

2.1 创建仓库时到底要怎么选参数

Gitee 是国内的代码托管平台，类似 GitHub 的国内版，访问速度快，支持私有仓库免费额度，适合个人项目和中小团队。注册账号这种基础操作就不展开说了，直接进重点：创建仓库时那些选项怎么选。

仓库名要一眼能看出用途，比如blog-system、my-portfolio，不要用test、aaa这种命名。路径名会直接出现在访问地址里，如果仓库用于静态托管或开源分享，建议全小写、用连字符分隔单词，这样 URL 更规整。

开源许可证的选择一直有人问到。简单说，选许可证是告诉别人“你可以怎么用我的代码”：

如果你只是把自己的学习代码放上去当备份，不打算给别人用，选个 MIT 就好，最省事。如果完全不知道选什么，又确定要公开，那就 MIT，理由是不限制别人使用，也不会给后来维护的人挖坑。

2.2 SSH 密钥配置：不用每次输密码的关键

往 Gitee 推送代码有两种常见协议：HTTPS 和 SSH。HTTPS 每次推送都要输入账号密码（除非用凭据管理器记住），SSH 配置好密钥之后一劳永逸，推荐直接上 SSH。

先检查本地有没有生成过密钥：

ls -al ~/.ssh

一般没有，则直接生成。注意把邮箱换成自己注册 Gitee 用的邮箱：

ssh-keygen -t ed25519 -C "你的Gitee邮箱"

一路回车即可，默认会保存到~/.ssh/id_ed25519。如果系统比较老不支持 ed25519，可以用ssh-keygen -t rsa -b 4096替代。

生成完成后，查看公钥内容：

cat ~/.ssh/id_ed25519.pub

复制整段输出，去 Gitee 的“设置 → 安全设置 → SSH 公钥”页面，粘贴并保存。然后验证是否配置成功：

ssh -T git@gitee.com

第一次连接会提示是否确认主机指纹，输入yes回车。如果看到欢迎语之类的内容，说明密钥配置成功。

这里有个经验之谈：配置密钥时一定确认是id_ed25519.pub这个公钥文件的内容，不是id_ed25519私钥。后者绝对不能泄露，一旦公开，你的代码仓库就任人摆布了。

3. 打通本地与远程：克隆、提交与推送全流程

3.1 用 HTTPS 还是 SSH？克隆项目怎么选

在 Gitee 仓库页面，能看到“克隆/下载”按钮，提供 HTTPS 和 SSH 两种地址。选哪个，取决于你的使用场景：

• SSH 地址：形如git@gitee.com:用户名/仓库名.git。配置好密钥后，推送和拉取全程免密。强烈推荐日常开发用它。
• HTTPS 地址：形如https://gitee.com/用户名/仓库名.git。首次操作要输账号密码，适合偶尔用一下的临时机器。

在 VSCode 里克隆项目有两三种方式，最简单的是先打开命令面板（Ctrl+Shift+P），输入Git: Clone，回车后会让你填仓库地址，再选一个本地存放目录，然后自动开始克隆。

也可以在终端执行：

git clone git@gitee.com:用户名/仓库名.git

克隆完成后用 VSCode 打开对应文件夹，直接进入开发状态。

3.2 首次上传：把已有代码推到空仓库

把本地已有的项目推送到一个刚建好的空仓库，是新手最常卡住的环节。关键点在于默认分支名和远程仓库关联。

假设本地项目文件夹叫my-app，打开终端进入该目录，先初始化 Git：

git init

然后看到当前仓库的分支名。新版 Git 默认叫master，但 Gitee 新建仓库默认分支是master还是main取决于创建时的选择。最稳妥的做法是创建仓库时，把仓库名称、分支名都记下来，保持一致。

接下来把所有文件加入暂存区并提交：

git add . git commit -m "initial commit"

git add .是把当前目录下所有新增和修改的文件都加入暂存。注意，如果目录里有 node_modules、编译输出等不需要托管的内容，应提前创建.gitignore文件，否则会把一堆垃圾文件推上去，而且之后同步都受影响。.gitignore的基本写法：

node_modules/ dist/ *.log .DS_Store

提交之后，把本地仓库和远程关联起来。远程地址别名统一叫origin：

git remote add origin git@gitee.com:用户名/仓库名.git

首次推送要加上-u参数，把本地分支跟远程分支建立关联，之后再推就只需要git push：

git push -u origin master

如果本地分支名和远程默认分支名不一致，比如本地是master，远程仓库初始化用了main，会推送失败。解决办法是指定推送，或者更快的方式是直接改名：

git branch -M main git push -u origin main

3.3 日常迭代：改代码、提交、拉取的正确节奏

项目跑到日常维护阶段，最常见的一套操作就是：改代码 → 暂存 → 提交 → 推送。我自己的习惯节奏是：

1. 开工前先git pull，把远程最新代码拉到本地，确保自己在最新代码基础上改。
2. 完成一个小功能或修完一个 bug，及时git add相关文件，git commit -m "清晰的提交说明"。
3. 提交信息尽量写清楚“做了什么、为什么”，不要写update、update2这种没有信息量的内容。
4. 推送前如果再发现远程有别人更新的代码，先git pull再git push，能有效减少冲突。

这三个命令贯穿整个开发过程，熟记即可：

git status # 查看当前改动状态 git add <file> # 添加某个文件到暂存区 git commit -m "描述" # 提交暂存区内容 git push # 推送到远程

VSCode 左侧的源代码管理面板（快捷键Ctrl+Shift+G）把这些操作图形化了。修改过的文件会显示在列表里，点击文件可以查看行级差异，暂存、提交、推送都有按钮，非常直观。对于不熟悉终端命令的初学者，用面板操作也能完整走通这套流程。

3.4 分支操作：不要一直在 main 上裸奔

分支是 Git 里非常重要但被很多初学者一开始忽略的功能。主线分支（main 或 master）应该保持稳定、可发布的状态，开发新功能时单独开分支，验证没问题再合并，这样即使写崩了也不会影响主分支。

常用的分支命令：

git branch 新分支名 # 创建分支 git checkout 新分支名 # 切换到该分支 git checkout -b 新分支名 # 创建并切换，一条命令搞定 git branch -a # 查看所有本地和远程分支 git merge 新分支名 # 把该分支合并到当前分支

在 VSCode 的源代码管理面板底部可以看到当前分支名，点击就可以切换或创建分支。Gitee 仓库页面上也会展示所有分支，推送上去之后可以直接在网页端查看差异、发合并请求。

4. VSCode 里这些插件能让你效率翻倍

4.1 必备插件列表

VSCode 强大的地方很大程度来自插件生态。下面这几个插件是为 Gitee/Git 工作流服务的，装完之后体验提升非常明显：

• GitLens：最强大的 Git 插件之一。它能直接在代码行尾显示这行是谁、什么时候、因为什么提交修改的，点击能看到完整的提交历史和 diff。排查“这行代码为什么改过”特别好用。
• Git History：以图表形式展示所有提交记录、分支走向，还可以对某个文件查看它的历次修改历史。
• Remote - SSH：虽然名字里有 SSH，但用途是远程开发。配合 VSCode 插件体系，可以远程连接服务器直接在编辑器里改代码。

进扩展面板（Ctrl+Shift+X），搜索名字就能安装，不需要额外配置。

4.2 语言环境配置：C/C++、Python 实例

热搜词里很多人搜“vscode 配置 c/c++ 环境”、"vscode python 环境配置"，这里顺便把这两个最常见的配置思路说清。

在 VSCode 里配置开发环境，核心思路是：编辑器负责写代码，编译器/解释器负责运行。VSCode 自己不带编译器，需要先把工具链装好。

Python 环境算是最简单的：

1. 安装 Python 官方解释器，并勾选“Add Python to PATH”。
2. VSCode 安装 Python 扩展（微软官方出品）。
3. 打开任意.py文件，VSCode 会自动识别解释器，右下角可以切换。
4. 直接按Ctrl+F5或点击运行按钮就能跑脚本。

C/C++ 环境稍麻烦一点：

1. Windows 上推荐安装 MinGW-w64，把它bin目录添加到系统 PATH 环境变量。
2. VSCode 安装 C/C++ 扩展。
3. 写一个简单程序，按下 F5 选择“C++ (GDB/LLDB)”，VSCode 会生成launch.json和tasks.json两个配置文件，里面指定了编译命令和调试器。

虽然首次配置要花点心思，但配完之后体验比很多 IDE 都轻快，而且项目的编译调试配置都在仓库里，换机器重新构建也快。

5. 常见问题与避坑实录

5.1 推送被拒、权限报错怎么排查

用 git push 推送时遇到权限问题，大概率是 SSH 密钥没配对。排查顺序很有讲究：

1. 先验证密钥是否生效：运行ssh -T git@gitee.com，如果看到欢迎信息说明 SSH 链路没问题。
2. 如果提示权限 denied，去 Gitee 设置页检查 SSH 公钥是否粘贴正确，尤其注意不要带多余空格或换行。
3. 确认本地 Git 身份信息，对应的用户名邮箱和 Gitee 账号一致与否不影响 SSH 校验，但会影响提交记录的归属，最好设置正确。
4. 如果用的是 HTTPS 地址，推送时提示输入用户名密码却输不对，去 Windows 凭据管理器里删掉旧的 Gitee 凭据，重新推送时再输入一次就好。

还有一个比较高发的情况：远程仓库里有文件（比如初始化时勾选了 README 或 .gitignore），但本地仓库是全新的，两者没有共同历史，直接推送会报failed to push some refs。解决办法是先把远程内容拉下来合并：

git pull origin main --allow-unrelated-histories

加上--allow-unrelated-histories是允许两条独立历史合并，拉下来之后处理好冲突再推送，代码才能上去。

5.2 冲突处理：这块代码怎么同时被改了

多人协作时，冲突不可避免。场景简单描述：你和同事同时修改了同一个文件的同一段代码，你先推送成功，他再推送时被拒，因为有冲突需要解决。

处理冲突的操作路径：

1. git pull拉取远程代码，Git 会标记冲突文件，文件里会出现类似下面这样的标记：

<<<<<<< HEAD 你本地写的内容 ======= 远程拉下来的内容 >>>>>>> origin/main

2. 在 VSCode 里打开冲突文件，编辑器会用颜色块区分“当前更改”和“传入的更改”，顶部有“接受当前更改”“接受传入更改”“保留双方更改”等按钮，手动选择或直接编辑。
3. 保存文件后，在源代码管理面板里标记为已解决，然后照常提交推送。

解决冲突的核心原则：看清每段代码是干什么的，别盲目覆盖。如果不确定，找协作的同事沟通一下再合并，比事后排查快得多。

5.3 误操作补救：commit 错了、文件删了怎么办

代码托管平台带来的安全感之一就是误操作可以补救。Gitee 的仓库页面可以查看所有提交历史，找到某个历史提交后可以一键回滚，或者把它重置到某个状态。这个操作要小心，如果团队都在用同一个仓库，回滚会影响别人，操作前最好和团队确认。

本地误操作也有补救办法：

git log --oneline # 查看提交历史 git reset --soft HEAD~1 # 撤销最近一次提交，但保留改动 git reset --hard HEAD~1 # 撤销最近一次提交，同时丢弃改动 git reflog # 查看所有历史操作，包括 reset 之前的记录

git reflog是最后的救命稻草。即使误用了--hard，只要提交对象还在本地，就能找到对应的哈希值回到正确状态。我自己的习惯是：重要分支推送前先确认 diff，宁可多花一分钟检查，也不要推错代码。

5.4 批量删库这类高危险操作要谨慎

Gitee 上有一个“批量删库”功能，管理多个仓库时确实方便，但批量操作风险极高。曾经见过有人本想清理废弃仓库，不小心把还在正常使用的项目连同所有历史版本一起删掉。

几点建议：

• 删库前在本地确认这个仓库的代码都有完整备份，至少确保最近一次提交已经 clone 到了本地。
• 批量删库列表出来后逐个确认仓库名，不要只看缩略信息。
• Gitee 的仓库删除有二次确认机制，输入指定仓库名的操作千万别嫌麻烦，这是在给你最后一道保险。

我在实际使用中的体会是，Gitee 作为国内访问速度极快的代码托管平台，在个人备份、项目展示、团队协作这些场景下都非常顺手。但工具始终只是工具，真正决定项目质量的是你有没有规范的提交习惯、清晰的仓库结构、合理的分支管理。如果你正处在“写代码只会保存在本地 U 盘”的阶段，这篇教程应该能帮你把第一个仓库稳稳当当地推上去。等你养成每次提交都写清楚说明了习惯，你会发现代码管理的安全感远比想象中的爽。