|<<>>|34 of 275 Show listMobile Mode

You should be using a GUI for Git

Published by marco on

 I’ve seen this Noob question: Does anyone use things like git gui? by Collekt (Reddit) again and again.

“Just curious as I’m learning and getting familiar with git. Do real production teams use any kind of tools for git like “git gui” or others? Or does everyone just use it from command line? Thanks for any insight. :)”

You almost certainly have several use cases for your source control:

  • clone/push/pull
  • commit
  • amend/squash/rebase interactive
  • merge
  • diff
  • code forensics (log/blame, cross-reference, find changes)
  • work with submodules

The command-line isn’t the most efficient or least error-prone for any of these tasks.

For example—something you do every day—a good GUI client will let you very quickly navigate diffs in your working tree with only a few arrow-key presses. You can’t beat that with the command line.

And, once you have to merge … you’ll want a more powerful view on things than you’re going to get from command-line tools. Of course, it’s possible to merge on the command-line! I’m just saying it’s more error-prone and not as efficient—especially for most developers. There are probably a couple of John Henrys out there, but c’mon.

It’s great that the command-line exists! It allows us to build UIs on top of it. It allows us to integrate anything we’d like into a headless process like CI/CD.

However, you’re going to be more efficient with a good GUI. There are pros/cons to the various UIs. I’ve landed quite firmly on SmartGit after an evaluation of all of the other tools (in no particular order: Tower, VS, VSCode, GitLens, Kraken, GitExtensions, GitHub Desktop, SourceTree, Git GUI).

Why an external rather than an integrated Git client?

  • Uniformity regardless of IDE
  • Hotkeys are more intuitive (in-IDE source-control tends to end up with strange hotkeys)
  • Ability to integrate a good merging tool (e.g. BeyondCompare)
  • etc.

Why an integrated rather than external Git client?

  • inline change markers
  • inline history/blame
  • etc.

You can use both, of course! Use whatever helps you be more accurate and efficient and happy.

Visual Studio Code’s default source control is very limited (no code forensics to speak of), so be careful of defaulting to that one. Visual Studio is getting better all the time, though. Still feels a bit weird for me, but it’s 10x better than it was a couple of versions ago.

Of course, YMMV, but please don’t continue to believe in the myth that using a command line is somehow a requirement to being a “real” developer. Developers who only use the command line are probably wasting time, probably making mistakes they shouldn’t, almost certainly missing out on powerful enhancements to their workflow.