DEV Community

Cover image for GitFuse ⚡ — Move committed Git work between machines without pushing WIP branches
Iacon
Iacon

Posted on

GitFuse ⚡ — Move committed Git work between machines without pushing WIP branches

#showdev #opensource #go #git

I kept running into the same Git workflow problem whenever I switched between development machines.

I’d have a few commits locally that I wanted to continue working on somewhere else, but the branch wasn’t ready to be pushed yet.

The usual workflow became:

commit locally
↓
create a temporary WIP branch
↓
push it
↓
switch machines
↓
pull it
↓
clean up the branch later
Enter fullscreen mode Exit fullscreen mode

There’s nothing technically wrong with doing that.

It just felt odd to keep using a central Git remote as a transport mechanism for work I wasn’t ready to publish.

So I built GitFuse ⚡.

The workflow

GitFuse reduces that process to:

git commit
gitfuse sync
Enter fullscreen mode Exit fullscreen mode

Switch machines:

gitfuse pull
Enter fullscreen mode Exit fullscreen mode

Or simply:

git commit → gitfuse sync → switch machine → gitfuse pull
Enter fullscreen mode Exit fullscreen mode

The goal is intentionally narrow:

Move committed Git work between trusted machines without requiring a temporary remote branch.

GitFuse isn’t trying to replace GitHub, GitLab, or your normal Git remote.

It fills the gap before you’re ready to push.

What does GitFuse sync?

GitFuse works with committed Git state.

It deliberately does not behave like Dropbox, Syncthing, or a general-purpose folder synchronization tool.

It does not sync:

  • uncommitted working-tree changes
  • untracked files
  • ignored files
  • stashes
  • arbitrary files from the project directory

If something hasn’t been committed to Git, GitFuse leaves it where it is.

That boundary is intentional. I wanted GitFuse to remain repository-aware instead of becoming another filesystem synchronization system.

The CLI

The GitFuse CLI is written in Go.

A basic session looks like:

gitfuse auth login

cd my-project
gitfuse add .
gitfuse sync
Enter fullscreen mode Exit fullscreen mode

Then on another trusted machine:

gitfuse auth login
gitfuse pull
Enter fullscreen mode Exit fullscreen mode

The CLI currently includes:

  • authentication and headless authentication
  • repository tracking
  • sync and pull
  • dry runs
  • commit selection
  • repository status
  • sync history
  • trusted-device management
  • restore and recovery workflows
  • diagnostics and updates

Go has been a good fit because I wanted GitFuse to ship as a small cross-platform binary without requiring users to install another runtime.

Trusted devices

GitFuse uses an account + trusted-device model.

A new CLI device goes through an authorization flow before it can access the workspace, and connected devices can later be reviewed or revoked.

There’s also a Next.js dashboard for:

  • repositories
  • trusted devices
  • sync history
  • usage
  • account settings
  • upgrade plans

The CLI remains the main interaction point. The dashboard mainly provides visibility and account/device management.

Installation

macOS / Linux 

curl -fsSL https://gitfuse.dev/install.sh | sh
Enter fullscreen mode Exit fullscreen mode

Homebrew 

brew tap VectorSolus/gitfuse https://github.com/VectorSolus/GitFuse.git
brew install VectorSolus/gitfuse/gitfuse
Enter fullscreen mode Exit fullscreen mode

Windows 

winget install gitfuse
Enter fullscreen mode Exit fullscreen mode

Pre-built binaries are also available through GitHub Releases.

Why not just use a private branch?

That’s a completely valid option.

There are already several ways to move work between machines:

  • temporary/private Git branches
  • git bundle
  • SSH/SCP
  • Syncthing
  • another private Git remote

GitFuse isn’t trying to say those approaches are wrong.

What I’m trying to make smaller is this specific workflow:

commit → sync → continue elsewhere
Enter fullscreen mode Exit fullscreen mode

without creating remote branches purely to transport unfinished work.

Current state

The Free version of GitFuse is live.

Pro and Team plans are coming later with larger limits and additional workspace features.

The main question I’m trying to answer right now is simpler:

Is this actually useful for developers who regularly move between multiple machines?

If you use two or more development machines, how do you currently move committed-but-not-yet-published work between them?

Do temporary branches already work well enough, or does a workflow like GitFuse solve a real annoyance for you?

I’d also appreciate technical feedback on the Go CLI — command structure, error handling, recovery behavior, cross-platform behavior, or anything that feels more complicated than it needs to be.

Links

GitHub: https://github.com/VectorSolus/GitFuse

Live: https://gitfuse.dev

Docs: https://gitfuse.dev/docs

The GitFuse CLI is open source under AGPL-3.0.

Top comments (0)