Inspiration
As a developer working across multiple environments (Windows, WSL, and macOS), I kept running into the same painful ritual: promoting code between branches like develop → staging → main meant manually cherry-picking commits one by one, hoping I didn't drag along unfinished work or miss something important. Existing Git GUIs either oversimplified the process or didn't handle conflicts gracefully, and none of them treated "what should move forward" as a deliberate, visual decision. I wanted a tool that made selective promotion safe, transparent, and genuinely usable across every environment I actually work in.
What it does
BranchGate is a local-first, cross-platform desktop application that lets developers selectively promote Git changes between branches through visual pipelines, instead of manually cherry-picking commits. Users define a pipeline between two branches, pick exactly which pull requests or changes are ready to move, and BranchGate coordinates the rest. It detects genuine merge conflicts before they cause damage, opens the repository directly in the user's preferred editor, monitors resolution progress in real time, and lets the user safely continue or abort. It also flags stale commits, keeps a full history of past promotions, supports both native Windows Git and WSL, and works entirely offline, queuing anonymous analytics locally until a connection is available.
How we built it
BranchGate is built with Tauri, pairing a React and TypeScript frontend with a Rust backend. The Rust side handles Git operations, cross-platform process execution, and conflict detection, while the frontend focuses on making pipeline creation and promotion tracking visual and intuitive. SQLite handles local persistence, including promotion history and offline-queued analytics. Process execution was designed separately for Windows, macOS, and WSL to ensure editor handoff and conflict monitoring work consistently without blocking the UI or spawning visible terminal windows.
Challenges we ran into
The biggest challenge was reliably spawning and monitoring native processes across three very different environments (Windows, macOS, and WSL) without freezing the UI thread or leaking terminal windows, which required rethinking how child processes are launched and tracked on each platform. Git conflict detection was another major hurdle: distinguishing a genuine conflict from a resolvable one, and knowing when it's actually safe to continue versus when to abort, took a lot of careful handling of merge ancestry and staging state. Handling interrupted operations cleanly, so a crashed or aborted promotion never left a repository in a broken state, also took significant iteration.
Accomplishments that we're proud of
I'm proud that BranchGate handles real Git edge cases, like stale commits, interrupted promotions, and genuine merge conflicts, without leaving the user's repository in an inconsistent state. I'm also proud of getting native Windows Git, WSL, and macOS process execution working reliably from a single codebase, and of building an offline-first architecture where the app remains fully functional without a connection, syncing only when it can.
What we learned
Building BranchGate taught me how to bridge a React/TypeScript frontend with a Rust backend through Tauri, and how to reason carefully about process boundaries between a UI thread and native system calls. I deepened my understanding of Git internals, cherry-picking, conflict states, merge ancestry, staging, branch recovery, stale object detection, and cleanup after interrupted operations. I also learned to design cross-platform process execution for Windows, macOS, and WSL without blocking the UI or leaking terminal windows, which required rethinking how child processes are spawned and monitored on each platform. Beyond Git, I strengthened my grasp of SQLite migrations, offline-first data queues, and persistent application state. Designing the interface also pushed me to think more seriously about responsive layout, accessibility, and keyboard navigation. Overall, the project sharpened both my systems-level thinking and my ability to communicate complex developer workflows clearly.
What's next for BranchGate
Next, I want to harden the conflict-detection and recovery engine for production-scale reliability, add team-oriented features like shared pipeline configurations and promotion audit logs, and get macOS code-signing and notarization in place so users don't hit Gatekeeper warnings on first run. Longer-term, I'd like to explore integrations with GitHub/GitLab PR metadata directly in the pipeline view, and build out better onboarding and documentation to grow BranchGate's contributor base as an open-source project.
Log in or sign up for Devpost to join the conversation.