Git Course 0%

Other GUI clients

Intermediate ≈ 5 min

Before this lesson

What you will learn

  • What the common standalone clients are and who uses them
  • What they all share, so you can help without installing one
  • When a dedicated client beats an IDE

After this lesson you can

  • I can pair with someone using a client I have never opened

Why this matters

Not everyone uses an IDE for Git. When you pair with someone, or answer a question in a channel, knowing the shape of these tools means you can help without installing anything.

The common ones

Client Platforms Notable for
GitHub Desktop macOS, Windows The simplest of all; GitHub-focused, free, good for occasional contributors
Sourcetree macOS, Windows Free, from Atlassian; a detailed graph and a lot of options
GitKraken macOS, Windows, Linux A polished graph, merge tooling, paid for private repositories
Fork macOS, Windows Fast, liked by people who want a graph plus interactive rebase
Tower macOS, Windows Paid; strong undo and conflict tooling
Sublime Merge macOS, Windows, Linux Fast, shows the command for every action, which makes it a good teaching tool
lazygit Everywhere, in the terminal A keyboard-driven interface in the terminal, popular with people who live there
git gui and gitk Everywhere Ship with Git; plain, and always available in an emergency

What they all share

Every one of them is a view over the same repository, so the concepts transfer completely:

  • A list of changes, split into staged and unstaged.
  • A commit message box and a commit button.
  • A branch list, usually with a graph.
  • Pull and push, sometimes combined as "sync".
  • A conflict view, of varying quality.

That means the task table works for these too: find the tool's word for staging, and the rest follows. When helping someone, ask "what does your tool call the staged list?" rather than trying to remember its menus.

When a dedicated client is the right choice

An IDE is the obvious default when you already have one open. A standalone client earns its place in three cases:

  • You do not use an IDE. A writer working in a plain Markdown editor is better served by GitHub Desktop than by installing IntelliJ.
  • You want the graph. Sourcetree, GitKraken and Fork show branch structure better than either IDE in this course.
  • You do a lot of history surgery. Interactive rebase, cherry-picking and splitting commits are more comfortable in Fork, Tower or Sublime Merge than anywhere else.

Helping someone using one

Four questions get you anywhere, whatever the tool:

  1. "What does it say your branch is?" Every client shows this, usually top left.
  2. "What is in the staged list?" That is what a commit would contain.
  3. "What exactly did the error say?" Clients relay Git's messages, and the message is the diagnosis (Section 12).
  4. "Can you open a terminal in that folder?" git status and git log --oneline -3 describe any state, in any tool.

Question 4 is the one that resolves anything genuinely stuck. Every client sits on top of an ordinary repository, so the commands work regardless of what is showing on screen.

A note on the platform desktop apps

GitHub Desktop is worth singling out because it is the one you are most likely to be asked about. It deliberately hides much of Git: no rebase by default, no reflog, no cherry-pick in older versions. That makes it excellent for the case it targets, an occasional contributor making a small change, and frustrating for anything else.

GitLab has no equivalent official desktop client; GitLab users pick one of the general clients above, or an IDE.

How to do it

The universal fallback, in any repository, whatever tool created it:

Terminal
$ git status
$ git log --oneline -5
$ git remote -v

Nothing about a repository is client-specific, which is the point of this lesson.

Common mistakes

  • Assuming a client changes how Git works. It does not; it is a view.
  • Recommending your tool when someone asks for help with theirs.
  • Expecting GitHub Desktop to do everything. It deliberately does not.
  • Forgetting the terminal is available in any repository, regardless of the client.

Try it yourself

Goal: prove that the repository is independent of the tool.

  1. Make a commit in your practice project using VS Code or IntelliJ.
  2. Run git log --oneline -1 in the terminal and confirm it is there.
  3. If you have a second client installed, or install GitHub Desktop briefly, open the same folder in it.
  4. Confirm the same branch, the same history and the same pending changes appear.
  5. Make a commit in that client and confirm the first tool shows it immediately.

Expected result: three tools showing one repository, agreeing completely, because all of them are reading the same .git directory.

Show solution

Step 5 is the reassurance. There is no synchronisation between tools and nothing to keep in step: a commit made anywhere is simply in the repository, and every other tool sees it the moment it looks. That is why "which client should I use?" is a question about preference rather than compatibility.

Check yourself

1. What do all Git clients have in common?
2. A colleague's client is behaving oddly. What resolves almost anything?
3. Why does GitHub Desktop hide features like rebase and the reflog?

Key terms

IDE Commit Branch

Related