← Back to Ideas
tech

WSL 写代码，Windows 跑 Android Studio：一套不再手动 copy 的工作流

用一份 WSL worktree 加一份 Windows 工作副本，再配一个本地 bare 仓库中转，就可以彻底告别手动 copy 文件。

George Hu7 min readtech

最近我在做一个 Next.js + Capacitor + Android 的实验。Web 代码我还是更习惯在 WSL 里开发，但真正跑 Android 壳时，又离不开 Windows 上的 Android Studio。

一开始我用的是最笨的方法：

  • 在 WSL 里写代码
  • 改完后手动 copy 到 Windows 目录
  • 再用 Android Studio 打开 Windows 那份工程

这个方法短期能用，但很快就会变得非常痛苦：

  • 很容易漏文件
  • 容易把 .next、node_modules、build 这种不该复制的产物一起带过去
  • 分支状态会越来越乱
  • 你根本不清楚 Windows 那份代码到底和 WSL 哪个 commit 对应

后来我把这套流程改成了：

  • WSL 负责 Web 开发
  • Windows 负责 Android Studio
  • 两边不用手动 copy，只用 Git 同步
  • 如果正在开发分支上，也能同步，不需要每次先 push 到 GitHub

这篇文章就把整套流程一步一步记录下来。

先说结论：不要再手动 copy

最稳的做法不是让 Android Studio 直接操作 WSL 目录，也不是每次复制文件，而是拆成三份位置：

  1. WSL 里的开发目录
    这是你平时写代码的地方。

  2. Windows 上的本地 bare 仓库
    它只负责做 Git 中转，不直接改代码。

  3. Windows 上给 Android Studio 用的工作副本
    这是 Android Studio 真正打开的目录。

在我的实际场景里，这三个路径分别是：

WSL 开发目录 /home/hujing/my-website/.worktrees/capacitor-android-shell Windows bare 仓库 H:\git-sync\my-website.git Windows Android 工作副本 H:\projects\my-website-android

整体数据流是这样的：

WSL worktree -> push 到 Windows bare 仓库 -> Windows 工作副本 pull -> Android Studio 运行

这样以后就没有“复制代码”这一步了。

为什么 Android Studio 不直接打开 WSL 目录

如果你现在的环境和我差不多，问题通常不是代码本身，而是运行环境不顺：

  • Web / Node / Next.js 在 WSL 里更舒服
  • Android Studio 和 Gradle 在 Windows 原生环境里更稳
  • Android 模拟器、SDK、GUI 工具也更适合跑在 Windows 上

所以更合理的分工不是“想办法让 Android Studio 适应 WSL”，而是：

  • WSL 专门干 Web 开发
  • Windows 专门干 Android GUI 工具链

只要这两边用 Git 同步，你就不用在“共享目录”“手动 copy”“路径兼容”之间反复折腾。

1. 在 Windows 建一个本地 bare 仓库

这个仓库只做同步中转，不直接写代码。

在 Windows PowerShell 里执行：

mkdir H:\git-sync cd H:\git-sync git init --bare my-website.git

执行完后，你会得到：

H:\git-sync\my-website.git

注意这里的 .git 目录本身就是一个仓库，不需要再进去改文件，也不要拿它给 Android Studio 打开。

2. 在 Windows clone 一份给 Android Studio 用的工作副本

接下来需要从这个 bare 仓库 clone 一份正常工作目录。

mkdir H:\projects cd H:\projects git clone H:\git-sync\my-website.git my-website-android

执行完后，你会得到：

H:\projects\my-website-android

这才是之后给 Android Studio 打开的目录。

如果你之前像我一样，直接在 H:\projects 里执行：

git remote add windows H:\git-sync\my-website.git

然后看到：

fatal: not a git repository (or any of the parent directories): .git

那不是 remote 命令有问题，而是因为 H:\projects 只是普通文件夹，还不是 Git 仓库。
你必须先 clone 出 H:\projects\my-website-android，再在那个目录里执行 Git 仓库命令。

3. 把 WSL 的开发 worktree 绑定到 Windows bare 仓库

我这边真正开发的是一个 worktree：

cd /home/hujing/my-website/.worktrees/capacitor-android-shell

在这个目录里，把 Windows bare 仓库加成一个新的 remote：

git remote add windows /mnt/h/git-sync/my-website.git

如果你之前已经加过这个 remote，就不用重复加。
可以先检查一下：

git remote -v

你应该能看到类似：

windows /mnt/h/git-sync/my-website.git (fetch) windows /mnt/h/git-sync/my-website.git (push)

4. 把当前开发分支推到 Windows 本地仓库

假设你当前正在开发的分支是：

feature/capacitor-android-shell

那么在 WSL 的 worktree 里执行：

git push windows feature/capacitor-android-shell

这一步不会推到 GitHub，只会把当前分支推到你 Windows 本地的 bare 仓库里。

这正是这套工作流最舒服的地方：

  • 你可以继续在开发分支上工作
  • 不用每改一次都 push 到 GitHub
  • 也不需要手动 copy 文件

5. 让 Windows 那份工作副本切到同一个开发分支

接下来到 Windows 的工作副本里操作：

cd H:\projects\my-website-android git fetch origin git checkout -b feature/capacitor-android-shell origin/feature/capacitor-android-shell

如果这个分支已经存在了，就直接：

cd H:\projects\my-website-android git checkout feature/capacitor-android-shell git pull origin feature/capacitor-android-shell

这里的 origin 实际上就是你本地的 bare 仓库，因为这份工作副本就是从 H:\git-sync\my-website.git clone 出来的。

6. 以后每天最短同步流程

这一步最重要，因为它决定你以后会不会又回到手动 copy。

WSL 侧：继续正常开发

在 WSL worktree 里：

cd /home/hujing/my-website/.worktrees/capacitor-android-shell

改完代码后执行：

git add . git commit -m "feat: update capacitor android shell" git push windows feature/capacitor-android-shell

Windows 侧：同步给 Android Studio

在 Windows 工作副本里：

cd H:\projects\my-website-android git pull origin feature/capacitor-android-shell

这样两边就同步好了。

你会发现，这个流程虽然还是 Git，但已经比“手动 copy 文件”干净太多了，而且状态可追踪。

7. Android Studio 应该打开哪个目录

Android Studio 不要打开：

  • WSL 路径
  • bare 仓库
  • H:\projects

应该打开的是：

H:\projects\my-website-android\android

也就是 Windows 工作副本里的 android 工程目录。

这时你的职责就很清楚了：

  • WSL 改 Web 代码
  • Windows 跑 Android 工程

8. Capacitor / Android 壳的同步

如果你的项目像我一样还用了 Capacitor，那么除了 Git 同步之外，通常还需要同步 Android 壳资源。

在 Windows 工作副本里执行：

cd H:\projects\my-website-android npx cap sync android

然后再回到 Android Studio 运行。

什么时候需要跑 npx cap sync android

这些情况建议都跑一下：

  • 改了 capacitor.config.ts
  • 改了 Capacitor 插件
  • 更新了 Android 壳相关依赖
  • 不确定 Android 工程有没有吃到最新的 Web 侧配置

如果你只是改了一点普通页面文案，有时不一定需要；
但如果你正在做 App 壳适配，我的建议是：宁可多跑一次，也不要拿旧工程状态排查问题。

9. 哪些地方在 WSL 改，哪些地方在 Windows 改

这一步不严格规定的话，两边很容易互相污染。

更稳的分工是：

主要在 WSL 改

  • app/
  • components/
  • lib/
  • content/
  • package.json
  • capacitor.config.ts

也就是绝大多数 Web 代码和项目逻辑。

主要在 Windows 改

  • android/ 目录下 Android Studio 直接生成或修改的文件
  • Gradle、Manifest、Android Studio 项目设置

如果你在 Windows 这边改了 Android 工程，记得也要在 Windows 工作副本里：

git add . git commit -m "fix: update android project config" git push origin feature/capacitor-android-shell

然后回 WSL 那边再 git pull windows feature/capacitor-android-shell。

也就是说：

  • Web 逻辑以 WSL 为主
  • Android 工程以 Windows 为主
  • 但两边都还是用 Git 说话

最后总结：以后不要再手动 copy

这套工作流真正解决的不是“怎么把文件挪到另一个盘”，而是把职责彻底拆清楚：

  • WSL 负责舒服地开发 Next.js / Node / Web
  • Windows 负责舒服地运行 Android Studio / Gradle / 模拟器
  • Git 负责两边同步

如果你现在也在做类似的事情，我最推荐的最短工作流就是：

一次性初始化

  1. Windows 建 bare 仓库
  2. Windows clone 一份工作副本
  3. WSL worktree 绑定 bare 仓库 remote
  4. 推送当前开发分支
  5. Windows 工作副本切到同一分支

日常开发

WSL：

git add . git commit -m "..." git push windows feature/capacitor-android-shell

Windows：

git pull origin feature/capacitor-android-shell npx cap sync android

然后在 Android Studio 里运行。

这比任何手动 copy 流程都更稳，也更适合长期维护。

Elsewhere

记录自己的第一次个人网站的上线

Discussion

Questions, disagreements, and follow-up notes all belong here.

Comments (0)