At a startup, I find myself longing for the exceptional developer tools I had at Facebook. During a substantial chapter of my early career, I was spoiled by Facebook's comprehensive internal tooling environment. Tools like Phabricator, Mercurial, VSCode @ FB, bunnylol, and butterflybot made my initiation into the software engineering realm remarkably smooth.
The utility I found myself relying on most during my tenure at Facebook was Interactive Smartlog, a GUI that simplifies the execution of complex Mercurial commands to mere clicks and drags.
In this blog post, I’m going to explore the advantages of leveraging a git GUI, dispel some of the misconceptions around using one, and introduce you to some of my top picks.
Is using a GUI for version control a "noob" move?
There's this (sometimes not so)subtle stigma that GUIs are just learning tools for junior devs getting their feet wet. Once you "graduate" you need to drop the "kiddie wheels" and operate via CLI exclusively.
And sure, if you’re new GUIs do provide a handy visualization layer to grasp Git concepts. But they also offer power users some real perks:
Speed up workflows (no time wasted on typing)
Reduce errors (no typos or wrong git branch checkouts)
Cut down on memorization (who can remember every Git command and arg?)
Easily cherry pick specific commits without sifting through sprawling git logs
Create pull requests right from your IDE without juggling a bunch of different windows
Anecdotally, at Facebook, I used the Smartlog GUI for practically all interactions with the Mercurial repository. It not only simplified tricky rebase and merge scenarios into drag-and-drop operations but also accelerated my everyday use of hg commands.
And it wasn't just entry-level peeps using it - engineers from junior to senior staff relied on it daily. The GUI workflow proved so efficient that we've essentially rebuilt it for Git in the Graphite CLI.
The bottom line is that GUIs complement CLI proficiency rather than replace it. There are many ways to blend a GUI into your style - some folks use it just for visualizing branches or simplifying rebases, and prefer CLI for scripting custom flows.
If you're a VS Code user already leveraging the commit UI panel, from a complexity standpoint switching to a dedicated GUI is a relatively small change. From an efficiency and ease-of use standpoint though it can make a monumental difference! Don't let stigma hold you back - GUIs can enhance productivity regardless of your experience or engineering level.
Using a git GUI for “risky“ operations
There's this lingering sentiment among devs that rebasing is risky business. You'll see some even claim it's harmful or dangerous. Folks who dislike rebasing tend to:
a) Fear nasty merge conflicts and lost work
b) Worry about editing history with --force or --force-with-lease commands
c) Not fully understand what rebase is doing under the hood
I won't rehash the whole rebase vs merge debate here, but if you’re curious check out this still active, 14 year old stack overflow thread describing the best rebase/merge practices.
The key point is that at big companies like Facebook, rebasing happens constantly across hundreds of thousands of repos. It powers efficient collaboration at scale. But in the command line, interactive rebase with git rebase -i or git pull --rebase can get messy fast. One wrong move can lead to lost work or nightmarish merge conflict resolutions if you don't have the full context. This is especially true for newer developers not as experienced with git but even the most senior developers can sometimes make mistakes.
This is where a GUI saves the day - it makes even the gnarliest interactive rebases a breeze with simple clicks and drags.
ℹ️ For the purposes of this blog post, I’ll be using Graphite’s VS Code extension, a GUI that builds off Facebook’s internal tooling.
With a git GUI, fetching the latest changes from upstream is as easy as a single click. The "Pull" button handles the dirty work of rebasing your branch smoothly behind the scenes.
Using the GUI we can view our commit history in a clear, visual way, giving us the complete context on the state of our git repository.
Since I’ve pulled new changes from main, a rebase is required (ooh scary).
A GUI reduces the risk of user-error and bad decision making by streamlining the workflow for potentially complex operations. In this case what would have been a messy interactive rebase becomes extremely easy with either a button press, or intuitively dragging a branch on top of the latest changes. This guards against destructive user actions while allowing developers to maintain control of their entire gitops workflow in a simple, more efficient manner.
Making changes to a branch is also visual and easy - the list of changes is enumerated and can be selected/discarded/reset with the click of a button!
To check out a branch, all I have to do is press the “checkout” button, and I can see exactly where I’m moving!
I can also easily delete or hide(untrack) branches by simply right clicking on the branch name:
My top Git GUI tools
Graphite Interactive: Kick your Graphite PR stacks into visual high gear.
GitKraken: A top-notch Git client with guides to help beginners.
Fork (Mac only): Collapsible graph + merge conflict resolution helper.
Sourcetree (Mac only): Solid free option for Mac users.
Tower: Premium Git client for Mac.
While at Facebook we used Mercurial instead of platforms like GitHub, GitLab or Bitbucket, there are a wide variety of GUI’s for every use case. For any teams that use git for software development, adding a GUI can greatly accelerate your development process.
Wrap Up
Hopefully, this convinces you to give a Git GUI a spin if you haven't already. It can speed up and simplify your workflows regardless of your experience level. Overcome the subtle stigma and optimize your dev environment however, works best!
