跳到主要内容

expo个人开发的GitHub和Eas发布流程

背景​

  • 国内的网络环境还是什么原因，导致2025年7月起，Eas的打包命令严重问题，没有一次成功。即使开无双，也会在访问Google服务的一瞬间出错。自2025年7月2X日起，我expo.dev的dashboard就没有更新信息了。
  • 本地打包仍然可用，但容易卡死，反复无数次才能成功。本地缓存问题？以前没有这么难，奇怪了。本地打包实在太慢，特别是iOS。
  • Github在开无双时还算基本可以用。
  • 我日常代码管理非常简单：Github的private项目，只有一个main分支，commit后push就完了，即使对个人开发也比较简单粗暴。
  • App项目大版本升级时，会新建一个repo，其他时候都是同一个repo。因为我的本地开发，在大版本升级时，会从头新建项目。

目标​

打造一个日常GitHub管理代码的流程，稍微规范点，日常还是在main分支开发，打包发布前单开一个branch，主要用于触发Eas服务。 通过GitHub和Expo官方Eas服务联动，触发打包，高效快速（至少iOS比本地块多了）。

需求实现方式
日常开发就在 main 分支上继续直接用 main 写代码，无需每次都建分支
需要远程构建时触发 PR + Expo 构建快速从 main 创建一个构建分支，发 PR，贴 Label，完成后自动删除

准备​

  1. 项目push到Github Github新建项目和本地同步的方法，这里就略过，之后单开。 注意要Private，并配置好本地.gitignore文件。

  2. 初始化项目的Eas服务

# 确保已登录
eas login
# 只需运行一次（确保会提示生成 projectId 和上传签名材料）
eas build --platform android --non-interactive
eas build --platform ios --non-interactive

如果这一步也出问题就麻烦了，我这个项目是7月初执行的这一步，当时似乎还好。 这时一定要保证有好的网络条件。 执行完后，到expo.dev检查面板，如果有项目名称则ok。

Terminal中，在项目目录执行:

# 初始化项目的eas配置
eas config

这下生成了基本的eas.json

  1. 定义打包的profiles 在eas.json中配置自己的profile，当然可以用原来的profile如production改，但我建议不要影响原有的，为GitHub触发模式专门准备，和其他（如本地）的profile分开。 我的如下：
{
...

  "build": {
    "prod_android": {
      "extends": "production",
      "android": { "image": "latest" }
    },
    "prod_ios": {
      "extends": "production",
      "ios": { "image": "latest" }
    },
    "prod_all": { // 这个基本不用
      "extends": "production",
      "android": { "image": "latest" },
      "ios": { "image": "latest" }
    }
  }
}

android和iOS分开最好，默认使用最新构建镜像（Expo 官方推荐）。

  1. Expo配置GitHub连接 登录 expo.dev → Project Settings → GitHub → Connect GitHub 仓库（只授予该 app 仓库访问）docs.expo.devdocs.expo.dev； 在 “Build triggers” 配置中：
  • 例如 main 分支推送触发打包 prod_all；
  • 也可以设置 PR label 触发 —— PR 中添加 label 如 eas-build-android:prod_android 即可打 Android;
  • 支持平台选择：eas-build-ios:prod_ios 或 eas-build-all:prod_all;
  • 触发方式灵活多样：通过网页 “Build from GitHub” → 选择分支/平台，或给 PR 打 label，操作简单，不需要 CI 文件。 此方案完全不影响本地已有打包方式，无侵入，只需项目和 expo.dev 后台关联。

我选择了PR label触发，相对平衡一点。 这一步注意，代码根目录要正确，默认就是"/"。

当然Expo 还提供 .eas/workflows/*.yml 原生工作流方式，直接运行在 expo.dev，而无需 GitHub Action。 问题是你Expo的网络上传有问题啊！😓

日常​

✅ Step 1：日常开发保持在 main​

继续在 main 分支做日常开发、调试、测试，无需变动流程。

# 有人推荐git checkout main，也行
git switch main
# 编辑代码...
git commit -am "修复组件显示 bug"
git push origin main

✅ Step 2：需要构建时，创建一个构建专用分支​

你只在需要构建的时候，从当前的 main 快速拉个构建用分支（不做额外开发）：

git checkout -b build/eas-android-20250803
git push origin build/eas-android-20250803

📌 命名建议：build/eas-平台-日期，比如 build/eas-android-20250803

✅ Step 3：GitHub 上发起 PR（无需修改任何代码）​

  1. 在新建的build分支下，修改一点内容，然后commit/push，以触发下面动作。

  2. 打开 GitHub，进入pull requests，页面会自动提示你：

  Compare & pull request

  1. 点击提示按钮，进入 PR 页面。

  2. 在右侧添加 Label，例如：

eas-build-android:prod_android

注意名称和expo规范的及eas.json的profile一致。

  1. 不需要写代码 diff，不需要添加 Reviewer，你自己点就好。

✅ Step 4：Expo GitHub App 识别 Label 并构建​

  • 构建过程会在 PR → Checks 里展示；

  • Expo Dashboard 会显示构建进度和下载链接；

  • 你可以继续用电脑干别的事，等它构建完成。

✅ Step 5：构建完成后，合并 PR 并清理分支​

如果你希望主分支也保留这次构建记录，可在 GitHub PR 页面点击 “Merge Pull Request”。 然后回到本地。

git switch main
# 拉一下保证一致性
git pull origin main
# 可以删除这个临时分支了
git branch -d build/eas-android-20250803
git push origin --delete build/eas-android-20250803

也可以 不合并，直接关闭 PR 然后删除分支也没关系 —— 因为你本来就在 main 写代码，构建用 PR 只是工具人 😎。

✅ Step 6：补充：构建不成功，要少量修改再反复提交时​

第4步中，如果Eas build不成功，还要少量修改再提交。

  • 不要进入第5步。
  • 确保你的开发环境还在新的build分支。
  • 修改代码等等，commit/push本分支，Github端啥都别动，提交代码会自动触发Eas服务再次build。
  • 如果build成功了，进Step 5，否则重复修改。

不管最后如何，你的build分支可能修改了不少东西（热修），记得清除前Merge到main（如有必要）。

git switch main
# 拉一下保证一致性
git pull origin main

# 把 build 上的热修拿回来
git merge build/eas-android-20250803
git push origin main

当然如果是发现了大问题要修改，就不是热修了，最好回到main分支修改。

其他​

switch和checkout的区别​

来自kimi

git switch 和 git checkout 都能用来“切换分支”，但它们的设计目的不同，switch 是 Git 2.23 起新增的“专门用来切换分支的命令”，而 checkout 是一个“瑞士军刀”式命令，功能更杂。

✅ 1. 语法对比​

表格

复制

目的推荐命令（Git ≥ 2.23）旧命令（仍然可用）
切换分支git switch <branch>git checkout <branch>
创建并切换分支git switch -c <branch>git checkout -b <branch>
放弃工作区修改git restore <file>git checkout -- <file>
切换到某次提交git switch --detach <commit>git checkout <commit>

✅ 2. 为什么要用 switch？​

  • 语义更清晰：
    switch 只做“切换分支”，不会误操作文件（checkout 既能切换分支又能恢复文件，容易混淆）。

  • 更安全：
    git switch 默认拒绝覆盖未提交的修改，除非你显式加 --force。

  • 未来趋势：
    Git 官方文档推荐用 switch/restore 取代 checkout 的“分支切换”和“文件恢复”功能。

✅ 3. 什么时候还会用 checkout？​

  • 老脚本、老教程里大量存在。

  • 需要“检出单个文件”到工作区：

    bash

    复制

    git checkout HEAD~2 -- path/to/file

    （switch 不支持恢复单个文件，要用 git restore）

✅ 总结一句话​

切换分支用 switch，恢复文件用 restore，checkout 仍能工作，但不再是首选。