A Full Day of Git Without Touching the Terminal
Part 2 of 4: Commits, branches, rebases, stashes, tags, and knowing when to sync — all inside Git Browse.
In Part 1 I introduced Git Browse, a local git GUI built with Next.js. This article walks through an actual working day with it: the morning pull, feature work, an interactive rebase before review, and a release tag at the end.
Morning: am I behind?
The first question every morning is “did anything change upstream?” Git Browse answers it in two places before you even click anything.
The Explorer sidebar shows every pinned repo with its current branch name and a dirty-state indicator — so a glance tells you which repos you left mid-work before you even open one. Right-clicking any folder also gives you Open in VS Code, which launches the folder in a new VS Code window without leaving Git Browse.
The Sync button in the top bar then gives you the precise counts against your branch’s upstream:
↓2— two commits to pull (shown in blue: incoming)↑1— one local commit to push (shown in amber: outgoing)
The counts refresh after every fetch/pull/push, when the window regains focus, and on a 60-second poll. One click on the button runs git pull; the caret next to it opens Fetch and Push. Or skip the mouse entirely: U pulls, P pushes.
One subtlety worth knowing: the Sync indicator compares your branch to its own upstream (feature-x vs origin/feature-x). Cross-branch comparison — "is develop ahead of me?" — is a different question, answered in the Branches tab below.
Reading history: the Log tab
The Log tab (L) renders the commit graph with branch lines, decorations for branch heads and tags, and relative dates. Click a commit to expand the files it touched; click a file to see its diff in the right panel. The "All branches" toggle switches between current-branch history and the full graph.
Making changes: the Changes tab
The Changes tab (C) is the working tree view. Modified, added, and deleted files are listed with their status; click a file to review its diff before staging. From here you can:
- Stage individual files or everything
- Write a commit message and commit (with an optional commit-all mode)
- Discard unstaged changes per file when an experiment goes wrong
After committing, the Sync button quietly switches to ↑1 — your cue to push when ready.
Branching: more than a list
The Branches tab (B) shows local and remote branches sorted by recency, each with its last commit subject and date. The current branch is highlighted with a HEAD badge. Two details make this view genuinely useful:
Get Lijo Jose’s stories in your inbox
Join Medium for free to get updates from this writer.
Divergence indicators. Every local branch shows how far it has diverged from what you’re on right now: develop ↑3 means develop has three commits you don't; main ↑1 ↓17 means main has one commit you lack and is missing seventeen of yours. It's a glanceable map of the whole repo's state — no git log --oneline --graph --all archaeology.
Right-click for everything else. Context menu on any branch: checkout, merge into current, rebase onto it, interactive rebase, delete. Destructive actions get a confirmation dialog that names exactly what will happen.
Interactive rebase, visually
The “Interactive…” button opens a dialog where you reorder, squash, reword, and drop commits with buttons instead of editing a pick-list in vim. For cleaning up a feature branch before review — squashing the "fix typo" commits into their parents — it turns a nervy operation into a sequence of obvious clicks.
Stash: the parking lot
The Stash tab lists every stash with its message. Push your current mess onto the stash before an urgent branch switch, then apply or pop it when you’re back. Drop the ones that turn out to be junk.
Shipping: tags
Release time. Press T (or ⌘K → Create tag…) and a dialog opens: type v2.1.0, hit Create & push, and Git Browse tags HEAD and pushes the tag to origin in one step. Existing tags are listed in the Branches tab with their dates and commit subjects.
If your CI builds on tag push — mine does — this is the entire release process.
Working across multiple repos
If you work across a family of repos — a monorepo’s siblings, a service and its SDK, a frontend and backend — the Explorer’s group feature keeps them together. Right-click any pinned repo to assign it to a named group; groups are collapsible and persist across sessions. Each repo in the list shows its active branch, so you can tell at a glance if your feature branch is checked out in both places before you start.
The safety story
A GUI for git lives or dies on trust. Git Browse’s rules:
- Confirm anything destructive. Branch deletion, discards, and merges get explicit dialogs.
- Show the real command. The set-upstream dialog displays the literal
git push --set-upstream origin <branch>it will run. - Report honestly. Every operation surfaces git’s actual output in a toast — success or failure, you see what git said.
Next up — Part 3: the comparison toolkit — diffing branches, folders, files, and even clipboard snippets — plus repo-wide search.
More details, screenshots, and release notes on
