GitHub Desktop Tutorial: The Five Operations That Cover Most of the Work

GitHub Desktop exists to make five operations obvious: clone a repository, create a branch, commit changes, push them, and open a pull request. Learn those five and you can work on a team indefinitely without touching a terminal. The rest of the interface is either a convenience wrapper on those five or an escape hatch for the situations where the graphical model stops being enough, and knowing which is which is the actual skill.

There is a persistent idea that using a graphical Git client is a stage you grow out of. It is not really true. Plenty of people who understand Git perfectly well use a GUI for the routine work because reviewing a diff visually before committing is genuinely better than reading it in a pager. What is true is that the GUI hides some of Git’s model, and the hidden parts are exactly the ones that bite during a merge conflict.

Install, sign in, and the one setting to change first
Clone a repository, or add one you already have
The commit loop
Branches, and why you should stop working on main
Push, pull request, and the button that does two things
What the interface hides, and when to open a terminal
How this fits the rest of the stack
FAQ

Install the application, sign in with your account, and it configures the credential handling for you. That removes the single most common beginner obstacle, which is authentication.

Before doing anything else, open the preferences and check the Git identity. The name and email set here go into every commit, and the email is what links commits to your account on the host. A mismatch means a history of commits that are not attributed to you, and that cannot be repaired later without rewriting history.

Two other settings worth changing on day one:

Default branch name for new repositories. Set it to main unless your team uses something else.
External editor. Set it to whatever you actually use, so the Open in editor button does the right thing.

That is the whole setup. Everything else in preferences can stay at its default forever.

Clone a repository, or add one you already have

Cloning downloads a full copy of a repository, including its entire history, onto your machine.

File, then Clone repository.
Pick from the list of repositories your account can see, or paste a URL for one it cannot.
Choose a local path. Keep all your repositories in one folder; future you will appreciate it.
Clone.

If you already have a project folder that is a Git repository, use File then Add local repository instead. If the folder is not a repository yet, the application offers to create one, which runs the equivalent of git init and leaves the files untouched.

One thing to check on a cloned repository before you start work: whether it has a gitignore file, and whether it covers your editor’s junk. Committing an editor settings folder or a local environment file is the classic first-week mistake, and the second half of it, committing a file with secrets in it, is a genuine problem rather than an embarrassment.

The commit loop

This is the operation you will repeat hundreds of times. The interface makes it a three-step loop.

The left panel lists every changed file. Clicking one shows the diff on the right, with added lines in green and removed lines in red. The checkbox next to each file decides whether it goes into the next commit, which is the graphical equivalent of staging.

Two things the interface does better than the command line here:

Line-level staging. You can click individual lines in the diff to include only part of a file’s changes in a commit. Doing this on the command line means an interactive add session, which is fiddly enough that most people skip it.
Reading the diff before writing the message. Having the change in front of you while describing it produces noticeably better commit messages.

Write a summary in the first box and, when the change deserves it, an explanation in the second. The summary should say what changed; the description should say why, because the why is the part nobody can reconstruct from the diff six months later.

Branches, and why you should stop working on main

A branch is a separate line of work. Making one is instant and free, and the habit is worth building before it is strictly necessary.

Use the branch selector at the top, click New branch, name it after the work rather than after yourself, and start committing. Switching branches swaps the files in your folder to match that branch, which is disorienting the first time and quickly becomes second nature.

The reason to branch even on a solo project: it makes the change abandonable. Work directly on main and a half-finished idea is entangled with everything else. Work on a branch and abandoning it is deleting the branch.

One rule that prevents most branch confusion: before creating a branch, make sure you are on an up-to-date main. The interface has a Fetch origin button at the top; press it, pull anything that came down, then branch. A branch created from a stale main produces a pull request full of other people’s changes, which is confusing for whoever reviews it.

Push, pull request, and the button that does two things

Commits live only on your machine until they are pushed. The button at the top of the window is context-sensitive and this is the part that most often confuses people, because it changes label depending on state.

Publish branch. This branch does not exist on the host yet. Pressing it creates it and uploads your commits.
Push origin. The branch exists remotely and you have local commits it does not have.
Pull origin. The remote has commits you do not. Pressing it downloads and merges them.
Fetch origin. Nothing to send or receive as far as the app knows; pressing it checks again.

After pushing, the app offers to create a pull request, which opens the host in a browser with the branches pre-filled. A pull request is a request to merge your branch into another one, plus a place to discuss it. Even alone it is useful, because it gives you a diff of the whole change rather than commit by commit.

The habit worth forming: fetch before you start work and push when you stop. Most painful merge conflicts are the result of a branch that diverged for a week.

What the interface hides, and when to open a terminal

The GUI covers the common path well and deliberately does not surface the sharp tools. The gaps worth knowing about:

Merge conflicts. The app detects them and offers to open an editor, but resolving a non-trivial conflict means understanding what both sides changed, and the interface does not explain that.
Rewriting history. Interactive rebase, squashing, amending an old commit and cherry-picking are mostly absent. This is a defensible choice, because these are the operations that lose work.
Submodules. Supported inconsistently. A repository with submodules is a terminal repository.
Stashing. Present but shallow. If you juggle several in-progress changes, the command line handles it better.
Reflog. The thing that recovers work you thought you destroyed. Not exposed at all, and it is the single best reason to know one terminal command.

The pragmatic position: use the GUI for the loop you repeat all day, and keep a terminal open in the same folder for the rare operations. They operate on the same repository, so there is nothing to reconcile between them, and switching costs nothing.

# The one worth memorising: it lists everything HEAD has pointed at,
# including commits you think you lost.
git reflog

How this fits the rest of the stack

The natural next step after a repository is on the host is having a push actually deploy something, and that is where the cost of the project starts to be a real number rather than a plan. The RunxBuild hosting calculator shows the pieces separately, so the service, the database, the storage and the bandwidth are visible before anything is committed to. On RunxBuild a project connects to a GitHub repository and builds on push, with build logs, environment variables, a live route, custom domains and a rollback to the previous deploy, which keeps the workflow the same five operations described here.

Useful related references:

FAQ

Is GitHub Desktop good for beginners?

Yes, and it is good for experienced people doing routine work too. It handles authentication, shows diffs clearly and supports line-level staging better than the command line does. Its limits are merge conflicts, history rewriting and submodules, all of which are better handled in a terminal.

Can I use GitHub Desktop with a repository not hosted on GitHub?

You can clone and work with any Git repository by pasting its URL, and commit, branch and push all work normally. The integrated features that assume the GitHub host, such as the pull request shortcut, will not apply.

What is the difference between fetch, pull and push?

Fetch checks whether the remote has anything new without changing your files. Pull fetches and then merges those changes into your branch. Push sends your local commits to the remote. The single button at the top of the window changes label to whichever of these is currently relevant.

Do I still need to learn Git commands?

For everyday work, no. For recovery, yes. Knowing git reflog and git status covers most of the situations where something has gone wrong and the interface cannot express the fix. That is a small amount of learning for a large reduction in panic.

Why are my commits not showing on my profile?

Almost always because the commit email does not match a verified email on your account. Check the Git identity in preferences, fix the email, and note that existing commits keep the old address unless the history is rewritten.