用 Android 和 iPhone 跑通 GitHub 工作流：从仓库到 Pull Request
过去在手机上处理 GitHub，往往只能看一眼通知；接着切到别的应用找仓库、克隆、编辑、跑命令、推送。一次小修改，常常就卡在这些工具之间的交接上。
从 NimoteCode 2.2.0 开始，Android、iPhone 和 iPad 都可以使用原生 GitHub 工作流：登录、找到仓库、在本机或 SSH 工作区中打开它、查看围绕它的协作信息，再回到同一个工作区完成一处经过审查的改动。
目标不是把手机变成缩小的桌面电脑，而是保留交付闭环中真正重要的部分：仓库上下文、真实的运行环境、可读的 diff，以及有意识的交付动作。
从仓库开始，而不是从一条 URL 开始
打开 GitHub 页面后，可通过浏览器设备授权或个人访问令牌登录。NimoteCode 会列出当前账号有权限访问的仓库，因此不必先复制一条克隆 URL。
克隆时，需要先决定代码在哪里运行：
- This device 适合能在手机上完成的文件与工作流。
- SSH host 会保留你已有的 Mac、Linux 机器或服务器上的仓库、依赖和项目命令。
对于已经搭好环境的项目，SSH 往往更从容：手机负责界面，主机仍是开发环境。若要处理私有仓库，请在目标主机上配置 GitHub SSH 密钥和 known_hosts 条目；应用不会把应用内保存的 GitHub 令牌转发给主机。
让 Issue 说明这次工作的边界
打开仓库后，GitHub 页面会集中展示默认分支、其他分支、Issue、拉取请求、评审和检查状态。对移动端任务而言，这些才是有用的上下文：不仅是“该改哪个文件”，还有“为什么要改、应在哪个分支上改、用什么来验证”。
你可以筛选 Issue 和拉取请求、创建 Issue，也可以从 Issue 发起带上下文的 Agent 任务。有了上下文，交接会更清楚，但它不能代替判断。先读验收条件，检查受影响的代码，并把任务控制在能在小屏幕上认真审查的范围内。
一套紧凑、可审查的移动端闭环
对于文档小修或聚焦的 bug 修复，流程可以很直接：
- 阅读 Issue 与仓库上下文，创建或选择分支。
- 在选定工作区中克隆或打开项目。
- 完成聚焦的修改，运行项目自己的测试、构建或 lint 命令。
- 在源代码管理中检查 diff，特别留意本不该变动的文件。
- 确认 diff 与检查结果都符合预期后再推送，并创建拉取请求。
手机上同样需要遵守桌面端的护栏。GitHub 的检查状态告诉你协作与 CI 的进度，但不能证明本地改动正确。只有项目不依赖完整提交历史时，浅克隆才适合大仓库。克隆会打开工作区，却不会自动安装依赖或配置项目。
Android 与 iOS 分别怎样融入这套流程
在 Android 上，GitHub 可以配合 SSH 工作区，也可以配合受支持的本地工作流。Android Local Linux 是可选的独立环境，iOS 不提供该环境。在 iPhone 和 iPad 上，SSH 工作区更适合保留主机上的工具链，同时仍在设备上使用同一套 GitHub、编辑器、终端和审查流程。
无论在哪个平台，GitHub 是入口与协作层；工作区才是检查、编辑、执行与审查的地方。把两者的职责分清，手机上的体验就不再只是远程控制，而是可以完成真实开发。
登录、克隆位置、私有仓库、Issue、拉取请求与检查状态的具体说明，请查看 GitHub 工作流指南。完整范围参见 NimoteCode 2.2.0 发布说明。
在 Android 或 iOS 上，把 GitHub 仓库带到一处经过审查的改动。