---
title: "6.2 把代码推到远程仓库，并用 EdgeOne Pages 完成部署"
order: 2
---

# 6.2 把代码推到远程仓库，并用 EdgeOne Pages 完成部署

部署这件事，最容易把人吓到的地方，是它表面上涉及很多词：仓库、远程、构建、平台、环境变量、日志。其实对基础版来说，你只需要先把闭环跑通。先把代码推到远程仓库，因为它既是备份，也是部署平台读取代码的来源；再把仓库连到部署平台上，用一个国内访问更友好的默认方案，比如 EdgeOne Pages，把项目发出去。

## 先把这条路径记住

基础版不要求你一下吃透部署原理，你先记住这条最小路径就够了：

```text
本地项目
-> 远程仓库
-> 部署平台
-> 公网链接
```

这条链路一旦跑通，你的作品就不再只活在自己电脑里了。

## 为什么要先推到远程仓库

很多新手会问：我明明已经在本地有代码了，为什么还要先去 GitHub 或 Gitee？原因很简单，远程仓库在这里同时承担两件事：

- 它是你的代码备份
- 它也是部署平台读取代码的来源

所以这一步不是多余动作，而是发布链路的一部分。

## 第一次部署，只求跑通

这里最重要的不是理解所有底层细节，而是别把自己困在“等我全懂了再部署”。第一次部署只求跑通，不求一口气理解全部配置。很多默认值本来就是可以先用的。基础版也不要求你在这里进入协作工作流。你不需要现在就学分支策略、PR、团队流程。

你只需要完成最小路径：

1. 创建远程仓库
2. 把本地代码推上去
3. 在 EdgeOne Pages 连接仓库
4. 使用默认构建配置先跑一次
5. 拿到第一个可访问链接

到这里，这个作品就已经真正离开了你的电脑。

## 如果部署失败，先看日志，再交给 AI

如果中间失败，也不要立刻怀疑自己是不是哪里根本不会。先看日志，再把日志贴给 AI，让它帮你判断是构建命令、环境变量，还是平台设置的问题。

你可以直接这样问：

```text
这是我在部署平台看到的构建日志。
请先帮我判断最可能的失败原因是什么。
只告诉我下一步先改哪一项，不要一次给太多方案。
```

这和第 2 章本地跑项目时的思路其实是一样的：先看现象，再收窄范围。

::: details 想深入一点？
如果你想系统学习 Git 协作，可以跳转到进阶版继续读：
- [第十一章：协作开发](/Advanced/11-git-collaboration/)

如果你想系统理解部署平台、构建流程和 CI/CD，也可以继续读：
- [第十二章：无服务器自动部署](/Advanced/12-serverless-deploy-cicd/)
:::

---

[下一节：上线后自测，并收集第一轮真实反馈 →](./6.3-feedback.md)