GitHub Desktop on a Mac, beside the terminal you already use

Someone installs GitHub Desktop, commits through it for a week, and then hits the first operation that is not in the interface. The usual response is to open a terminal, type the command, and never fully return to the app. That pattern is worth examining before deciding whether to install it, because the question is not whether the app is good. It is which parts of a Git workflow it is meant to hold, and what the arrangement looks like once a shell is open next to it anyway.

What the Mac download actually includes

The documentation describes GitHub Desktop as a free, open source application that helps with files hosted on GitHub or other Git hosting services. Two details in that sentence matter later: it is free with no paid tier attached to the app itself, and it is not restricted to GitHub as a remote, although the features that integrate with a host assume one.

The supported systems are stated precisely. GitHub Desktop runs on macOS 12.0 or later and on Windows 10 64-bit or later, and the documentation states that Linux is not yet supported. The download page offers separate Mac builds for Apple silicon and for Intel chips, alongside the Windows installer and an MSI package for organisation wide deployment, and notes that downloading means agreeing to the Open Source Applications Terms.

Installation on a Mac is a zip file rather than a package: the file is unzipped in the Downloads folder, the application file is opened, and the app launches once installation completes. There is no separate credential setup step, because authentication happens inside the app. The documentation calls this out as one of the benefits, noting that authenticating to GitHub or GitHub Enterprise does not require a separate credential manager.

One more piece is easy to miss because it is filed under command line use. Selecting Install Command Line Tool from the GitHub Desktop menu adds a github command, after which github . opens the current directory's repository in the app and github /path/to/repo opens a named one. That single command is what makes the app usable from a shell rather than in place of one.

The part it makes genuinely easier

Three things in the interface are faster than their command line equivalents, and they are worth knowing even for people who intend to keep typing everything else.

Staging individual lines is the clearest case. Choosing which changed lines go into a commit is git add -p on the command line, an interactive loop that answers with letters, and in the app it is a set of checkboxes next to the diff. For a file where two unrelated fixes overlap, the visual version is not just friendlier, it is less likely to produce a commit containing half of the wrong change.

Adding a co-author is the second. The documentation lists it as one of the less common Git operations the interface exposes without needing to remember or look up syntax, which is accurate: the trailer format is easy to get subtly wrong by hand and the field in the commit box cannot be.

Checking out a pull request is the third. The docs note that a pull request can be checked out to run checks without opening a browser, which replaces a sequence of fetch and branch commands with a list to pick from. For reviewing someone else's branch, this is the operation the app is best at.

None of these require giving up a terminal. They are the parts where a graphical interface has a real advantage, and they stay available whether or not the rest of the work happens in a shell.

The history operations it covers without a shell

The documentation lists the commit operations the app supports, and the list is longer than most people assume. Undoing a commit, resetting to a commit, amending a commit, reverting a commit, cherry-picking a commit, reordering commits, squashing commits, managing tags, and checking out a commit are all documented as interface operations. Alongside them sit stashing changes, managing branches, managing worktrees, and working with Git hooks.

Squashing is a good example of how these work, because it shows both the convenience and the edge. Commits are selected in the History view using Command or Shift, then dropped onto the commit they should be combined with, and the messages of the selected commits are pre-filled into the Summary and Description fields. The documented error and notification cases are the useful part: if the branch was already pushed, a notification states that the change will require a force push to update the remote branch, and the sequence becomes Begin Squash followed by Force push origin. If a merge commit sits among the selected commits, the squash fails. If uncommitted changes are present, the app offers to stash them and continue.

The documentation attaches the right warning to the whole category, noting that changing the history of commits that have already been pushed should be avoided where possible, because other contributors may have based work on them. That is the same rule the command line version has, stated in the place where the drag and drop makes it easy to forget.

Where the terminal takes over

The documented list is a list, which means anything not on it is typed somewhere else. Three kinds of work fall outside it often enough to plan for.

The first is searching history by content. Finding the commit that introduced a string, which is git log -S"DEFAULT_TIMEOUT", or the commit that added a line matching a pattern, which is git log -G, has no equivalent in the interface. The History view shows commits and their diffs, not a query across them.

The second is recovery. git reflog, ORIG_HEAD and creating a branch at a hash that is no longer reachable are the tools for undoing a bad rebase, and they operate on a local record the interface does not display.

The third is anything in the long tail: git bisect to find where a behaviour changed, git worktree operations beyond the documented ones, custom merge strategies, or the parts of an interactive rebase that involve editing a todo list rather than reordering rows.

None of those three are exotic. They are the commands that get reached for on the day something has gone wrong, which is also the day nobody wants to be learning a new interface. Knowing in advance which side of the line each one sits on is what keeps the app from feeling like it failed at the worst moment.

There is also a documented limit worth knowing before it bites. The app can hold only one set of stashed changes at a time, and stashing through it stashes all unsaved changes. The command line stash is a stack with as many entries as needed, so a workflow that parks two or three unfinished pieces of work needs the shell version.

The AI features, and what they need

Recent versions of the app include Copilot features, and the documentation is specific about both scope and requirements. Copilot in GitHub Desktop covers features such as commit message generation and conflict resolution, and the model used for each feature can be chosen.

The requirements are the part to check first. The documentation states that being signed in to a GitHub account with access to Copilot in GitHub Desktop is a prerequisite, and that if access is managed by an organisation or an enterprise, the feature has to be enabled for the account.

Beyond the hosted models, the app supports connecting a provider of your own, described in the docs as BYOK. Three provider types are listed: OpenAI and OpenAI compatible endpoints, which covers services such as Ollama, vLLM and Foundry Local, Azure OpenAI Service, and Anthropic Claude models. Configuration happens in Settings under Copilot, on the Providers tab, with a name, a type, a base URL and at least one model identifier.

That is a narrower kind of assistance than an agent working in a repository. It writes commit messages and helps with conflicts inside the app's own screens, rather than running commands, reading a whole project, or editing files. Both are useful, and they are not substitutes for each other.

Running it beside the terminal you already use

The app is built on the assumption that other tools are open, and the shortcuts reflect that. Control plus backtick opens the current repository in the preferred terminal tool. Shift + Command + A opens it in the preferred editor. Shift + Command + F shows it in the Finder. Shift + Command + G opens it on the host in a browser.

The preferred editor is chosen in Settings under Integrations, from a supported list that includes Visual Studio Code, Sublime Text, BBEdit, Xcode, Nova, Zed, Emacs, Neovide and the JetBrains editors, with a Configure Custom Editor option for anything not listed, including a field for arguments after the target path.

Read as a whole, that set of shortcuts describes the intended arrangement honestly: the app is one window among several, and it hands work off to the others. The cost is not any one shortcut, it is the number of windows the arrangement requires to be open at once, each with its own idea of which directory is current.

The keyboard set is worth learning for the same reason. Command + 1 shows the pending changes, Command + 2 shows the commit history, Command + B lists branches, Shift + Command + N creates one, and Command + P pushes. Learned together with the handoff shortcuts, they turn the app into something that can be entered and left quickly, which is the way it works best next to a shell.

Three ways to arrange the window

The choice is less about which app is better and more about how many windows the work needs.

Arrangement	What it is good at	What it costs
Desktop app plus a separate terminal and the Finder	visual staging, pull request checkout, guided history edits	three windows, three current directories to keep in sync
Terminal only, with the Finder for files	one place, every command available, scriptable	line by line staging and history edits are typed, not seen
A file manager with a built-in terminal	folders, shell and assistant over one working directory	a graphical Git history view is not the centre of the app

The second row is where a lot of experienced users end up, and the reason is not preference for typing. It is that a single current directory removes a whole class of mistake, the one where a command is correct for the repository the file list is showing and wrong for the one the shell is in.

The third row keeps that single working directory and adds the folder listing back. What that arrangement covers is set out on the Features page, and how it differs from dual pane browsers and terminal first tools is described on Compared with other file managers.

What to change first

If the app is already installed, run Install Command Line Tool and start opening repositories with github . from wherever the shell already is, which removes the window that gets lost most often. If the recurring problem is three windows disagreeing about the current directory rather than any missing Git feature, that is the thing to change, and Atriens is one example of that shape.