Use your phone as a remote Git client

I wanted something very specific:

the repo stays on my computer
I can review changes from my phone
I can make a decision (keep / revert / comment / commit)
and I can push when I’m confident

Not because I love “developing on a phone”.

Because the hard part of Git isn’t writing code.

It’s when you’re away from your keyboard and you still need to answer:

“Is this change OK?”

This guide is the workflow I’ve found that makes remote Git review feel straightforward and repeatable.

The core trade-off (before we get cute)

Remote Git workflows always pay one of these costs:

You mount a filesystem (SSH mounts, iOS Files providers, etc.)
You remote into a UI (remote desktop)
You do terminal Git (SSH/tmux)
You keep a copy of the repo on your phone (a real mobile Git client)

All of these can work.

But they feel very different in practice.

What I tried first (and where I bounced off)

SSH from my phone: works, but I don’t want to scroll through long output in a tiny terminal.
Remote desktop: heavy and fiddly. Fine in emergencies; I don’t want it as the default.
A mobile Git client that clones locally: also works — and if you’re doing “iPad-first dev”, it can be great. One well-known example is Working Copy (Git on iOS). It’s solid. But it’s not what I want when my computer is the source of truth and already has the repo + tooling.

What I wanted was a lighter loop: review diffs, leave comments, commit, push — without moving the repo to my phone.

A workflow that worked for me

I ended up using a “remote UI over my computer” approach.

Happier is one option that supports that approach.

It has a Projects tab where you can add folders from a connected computer and treat them like first-class projects — with the same Files + Source control surfaces you’d normally expect inside a session.

Trade-off: it still depends on the computer being online.

If you’re new to Happier (what it is, and where to get it)

If you haven’t seen Happier before: it’s an open-source companion app (mobile/web/desktop) that lets you keep coding workflows on a computer you trust, then manage them from your phone.

Get set up:

GitHub: https://github.com/happier-dev/happier
Install/download: https://github.com/happier-dev/happier#how-it-works
Discord: https://discord.gg/W6Pb8KuHfg

Step-by-step: use your phone as a remote Git client

1) Add a project folder

In the app:

Open Projects.
If it’s your first time, you’ll see No projects yet.
Tap ADD A PROJECT.
Tap Choose a folder on your computer.
In Select Path, pick the folder you want.
Tap Use.

At this point, you have a project that’s “just a folder” on your computer.

If it’s a Git repo, the Source control view will light up.

2) Open Source control → Changed files

Open the project, then:

Tap Source control.
Start on the Changed files sub-tab.

This gives you three super practical things:

a changed-files list
a diff review surface
a commit surface

3) Review diffs (without rereading everything)

On Changed files, you’ll see:

Changed files (with a count)
a ↓ Review button

Tap ↓ Review.

If the repo is large, you may see:

Large diff detected; diffs will load as you scroll.

That’s not a bug. It’s a guardrail: load diffs progressively instead of trying to render 600 files on a phone.

My actual phone review loop

On a phone, I don’t try to do a perfect review.

I do a bounded pass:

Open the riskiest file first.
Decide: keep / revert / comment.
Stop.

Most mistakes happen when review becomes unbounded.

4) Use review comments to make changes precise

This is the part I wish more tools did well.

When I’m reviewing on a phone, I don’t want to write a big message like:

“Please fix that part in the diff.”

Instead, I leave line-level review comments on the diff.

That gives you a literal checklist anchored to:

the file path
the line
a snippet of surrounding code

It’s also a great way to “queue up” work for later.

5) Commit (when you’re confident)

At the bottom of Changed files, you’ll see:

a commit selection summary (for example: 0 files selected for the next commit.)
an All button
a Commit message field
a Commit button

A small habit that saves me:

don’t commit everything by default
select the smallest coherent set of files
write a clear commit message that describes the intent

If the UI tells you something like:

Operation requires a clean working tree.

…take it literally.

That message is telling you “you’re trying to run an operation that expects the repo to be clean.”

6) Pull / Push (sync with upstream)

In Source control, you’ll see actions for:

Pull
Push

If you’re doing remote Git from your phone, this is where you want to be deliberate.

My rule:

I’ll pull freely.
I’ll push only after I’ve reviewed the diff and I’m confident.

7) Use History when you need context

If you’re trying to answer “what happened?” rather than “what changed right now?”, open:

History → Recent commits

You can also Load more commits.

This is especially useful when you’re reviewing a repo on your phone and you’ve forgotten what you were doing yesterday.

Terminal (optional, for the 10% case)

Sometimes you need the terminal.

In Projects, you also have a fully-featured terminal accessible on the terminal icon in the project page header (on the right).

My strong recommendation:

keep the default workflow UI-first (diffs, history, commit)
use terminal for the rare cases where you truly need it

If you use terminal for everything, you’re back to “SSH on a phone”, just with nicer buttons.

FAQ

Is this “Git on my phone” or “Git on my computer from my phone”?

It’s the second one.

The repo stays on the computer.

Your phone is the review + control surface.

What’s the biggest failure mode?

The host computer goes offline (sleep, lid closed, network changes).

No remote Git client can fix physics.

The best you can do is make “is it online?” obvious and avoid workflows that silently half-apply changes.

When should I use a real mobile Git client instead?

If you truly want the repo on your iPhone/iPad (offline work, travel, iPad-first dev), use a real mobile Git client.

Tools like Working Copy exist for a reason.

This guide is for the “my computer has the repo; I just want remote review and small interventions” case.