GIT Going with GitHub

Appendix Episode 52 10-12 min

GitHub Desktop

Using GitHub Desktop as an accessible alternative for cloning, branching, committing, and syncing.

Workshop docs

github desktop

Listen

Download MP3 Subscribe via RSS

Transcript

Alex: Welcome back. Today we're looking at GitHub Desktop, which is Git in a dedicated graphical app instead of only in the browser, VS Code, or the terminal.

Jamie: I like this topic because a lot of people hear "use Git" and assume the command line is the only serious option.

Alex: It really isn't. GitHub Desktop is free, open source, made by GitHub, and available for Windows and macOS. The appendix works like a reference path through the app: what it can do, how to install and sign in, then cloning, branches, commits, syncing, conflicts, history, and recovery tools.

Jamie: So it's not replacing every tool. It's another way into the same Git workflow.

Alex: Exactly. The browser is still great for issues, pull requests, repository settings, and reviews. VS Code is strong when you're editing files and need an accessible diff or terminal nearby. The Git CLI is still the most complete tool, but GitHub Desktop can handle a lot of the everyday contribution loop in a calmer interface.

Jamie: What does GitHub Desktop actually cover well?

Alex: It covers the core work most contributors repeat all the time. You can clone repositories, create and switch branches, stage files, stage individual chunks of a file, write commit messages, commit, push, pull, open pull requests, resolve many merge conflicts, view history and diffs, cherry-pick commits, stash changes, restore them, undo commits, and discard changes.

Jamie: That's more than I expected. What's outside the app?

Alex: Some advanced Git operations are not in the Desktop interface. For interactive rebase, git bisect, git clean, annotated tags, or commit signing with GPG or SSH, use the terminal or VS Code's terminal. GitHub Desktop helps there too, because Repository, then Open in Terminal, opens you in the correct folder.

Jamie: That removes one of the scary parts, which is landing in the wrong directory and running a command against the wrong project.

Alex: Right. Also, the ordinary commit message fields are standard editable text fields, and many controls are reachable from the keyboard. For low vision users, system zoom and high contrast settings apply to the app, though the red and green diff colors may still be easier to read in VS Code with a custom theme.

Alex: Installation is straightforward. On Windows, you can install with winget using the package name GitHub.GitHubDesktop, or download the installer from desktop.github.com. On macOS, you can use Homebrew with brew install --cask github, or download the app, unzip it, and drag GitHub Desktop into Applications.

Jamie: And Linux?

Alex: GitHub Desktop is not officially supported on Linux. If you're on Linux, the better path is VS Code's Source Control panel, the Git CLI, or a supported Git GUI in your environment.

Jamie: Once it's installed, do learners need to make tokens or set up SSH keys before they can do anything?

Alex: No. On first launch, choose Sign in to GitHub.com. Your browser opens, you sign in to your GitHub account, authorize GitHub Desktop, and then switch back to the app. Desktop stores the credential securely in the system keychain, so you don't have to paste a token every time.

Jamie: What if someone's school or workplace uses GitHub Enterprise Server?

Alex: Then they choose Sign in to GitHub Enterprise Server and enter the organization's server URL. Same general idea, just a different GitHub host.

Jamie: Can we describe the interface without assuming someone can see the layout?

Alex: Yes. At the top, there is a toolbar with the current repository, the current branch, and the Fetch, Push, or Pull button. The left side has a Changes tab for uncommitted work and a History tab for past commits. The main area shows the selected file's diff or the details of a selected commit, and the bottom-left commit area has the summary field, the optional description field, and the commit button.

Jamie: So the controls that matter most are repository, branch, sync, changes, history, commit message, and commit button.

Alex: That's the practical map. You can press Tab to move through focus regions, and the branch selector is searchable: type part of a branch name, use Down Arrow to review matches, and press Enter to select. The commit button is announced with the branch name, usually like "Commit to main" or "Commit to feature-branch".

Jamie: Low vision learners may care about where the stable landmarks are.

Alex: The toolbar stays at the top, so repository, branch, and sync status remain in a predictable place. OS display scaling can enlarge the whole app. If the diff panel's colors or small symbols are hard to use, open the repository in VS Code for more theme, font, and diff options.

Alex: Cloning means making a local copy of a repository on your computer. From GitHub.com, go to the repository page, activate Code, then choose Open with GitHub Desktop. Desktop opens, confirms the repository URL, lets you choose a folder, and then you activate Clone.

Jamie: That's the path I would use if I was already browsing the repository and wanted the least typing.

Alex: From inside GitHub Desktop, use Ctrl+Shift+O on Windows or Cmd+Shift+O on macOS to open Clone a repository. The GitHub.com tab lets you browse repositories your account can access, and the URL tab lets you paste a repository URL. Choose the local path, activate Clone, and wait for the files to download.

Jamie: And if someone already uses GitHub CLI?

Alex: They can run gh repo clone owner/repo-name, then open that folder in GitHub Desktop. The command github followed by the path to the repository can launch Desktop on that local repo when the command is available on the system.

Jamie: Once the repo is local, branches are usually the next place people get nervous.

Alex: A branch is a named line of work. In GitHub Desktop, use the current branch control to create a new branch, give it a clear name, and base it on the right starting branch. If the branch only exists on your computer at first, Desktop will offer to publish it to GitHub when you're ready.

Jamie: And switching branches?

Alex: Use the same branch selector. Type to filter, arrow through matches, and press Enter on the branch you want. When a branch is truly finished and already merged or no longer needed, Desktop can delete it, but pause before deleting anything that still has unpushed or unmerged work.

Jamie: That warning is important. Deleting the wrong branch feels like dropping a notebook in a lake.

Alex: Exactly, so check the branch name, check whether it has been pushed, and check whether its pull request has been merged before you clean it up.

Alex: Committing starts in the Changes tab. Each changed file appears in the file list, and selecting a file shows its diff in the main area. Staging means choosing which changes will go into the next commit.

Jamie: So a commit doesn't have to include every changed file on my machine.

Alex: Right. You can stage whole files, or in many cases stage individual lines or hunks, which are small groups of nearby changed lines. That lets you make focused commits, like one commit for a typo fix and another for a documentation update, even if you edited both during the same work session.

Jamie: Then the summary field is where the commit message goes?

Alex: Yes. Write a short summary in the summary field, add a description if more context is useful, then activate the commit button. The button includes the branch name, so it gives you one more chance to notice whether you're committing to the branch you intended.

Jamie: After the commit, the work is still only local until it is pushed, right?

Alex: Correct. Push uploads your commits to GitHub. Pull downloads commits from GitHub and applies them to your local branch. Fetch checks GitHub for new commits without applying them yet, and GitHub Desktop's sync button changes depending on what is available; the app menus also list keyboard shortcuts for these commands on your operating system.

Jamie: And pull requests?

Alex: After you push a branch, GitHub Desktop can offer to create a pull request. Activating that opens GitHub.com in your browser, where you finish the title, description, reviewers, checks, and any template fields the project requires.

Jamie: How does GitHub Desktop help when the repository is a fork?

Alex: If you cloned a fork, Desktop can help you keep it up to date with the original repository by fetching and updating from upstream when that remote is configured. A remote is a saved connection to a copy of the repository on a server. If upstream is missing, you may need to add it in the terminal with git remote add upstream followed by the original repository URL, or use VS Code's terminal from the same folder.

Jamie: So Desktop can be the normal workspace, and the terminal can handle the setup step if the remote relationship is missing.

Alex: Exactly. Merge conflicts are another place where tools meet. A conflict happens when Git cannot automatically combine two edits to the same area of a file.

Jamie: What does the repair process look like?

Alex: Desktop identifies the conflicted files and offers to open them in your editor. In the file, choose the version you want, or combine both, remove the conflict markers, save the file, return to Desktop, mark the conflict as resolved if needed, and commit the merge. If the conflict is detailed or the diff is hard to understand, VS Code is often the better place to do the actual editing.

Alex: The History tab is where you review past commits. You can move through commits, hear or read the commit message, author, and changed files, and inspect the diff for a selected commit.

Jamie: Can you narrow that down when the history is long?

Alex: Yes, use filtering when available to search for commits, and use file-specific history when you need to understand how one file changed over time. You can also compare branches to see what one branch contains that another branch does not.

Jamie: Where does cherry-pick fit in?

Alex: Cherry-pick means copying one commit from one branch onto another branch without merging the whole branch. In Desktop, you select the commit from history, choose the cherry-pick action, and pick the target branch. If a conflict appears, resolve it the same way: open the file, fix the content, save, return, and continue.

Jamie: And stashing is the temporary shelf, right?

Alex: Exactly. If you have uncommitted changes but need to switch branches, stash them, switch branches, and restore the stash when you're ready. Desktop also lets you undo the last commit, discard changes in one file, or discard all changes, but discarding is destructive, so treat it like deleting text from your only copy.

Jamie: Let's talk plainly about accessibility. What works well, and where should learners be cautious?

Alex: GitHub Desktop works best for routine actions that use labeled controls: choosing a repository, choosing a branch, writing a commit message, committing, fetching, pushing, and pulling. Browser-based sign-in is familiar, standard text fields are announced as editable text, and system zoom or high contrast settings can help with visibility.

Jamie: The harder part is the diff, isn't it?

Alex: Often, yes. Diffs can be dense, and some information is communicated visually through colors, icons, indentation, and line positioning. NVDA and JAWS users on Windows can usually move through the main controls with Tab and menus, while VoiceOver users on macOS may rely more on Control+Option navigation, but complex diff review may still be smoother in VS Code.

Jamie: So when should someone leave Desktop and use another tool?

Alex: Use Desktop for the everyday flow: clone, branch, review a manageable change, commit, push, and start a pull request. Use VS Code when you need accessible editing, better diff themes, conflict resolution, or the integrated terminal. Use the browser for issues, pull request forms, reviews, project pages, and repository settings, and use the Git CLI for the advanced commands Desktop does not expose.

Alex: The safest source for exact commands and interface changes is the official GitHub Desktop documentation, along with the GitHub Desktop download site. For background on Git concepts, GitHub's About Git material is helpful, and for sign-in and credential behavior, GitHub's security documentation gives the broader context.

Jamie: And for accessibility expectations, WCAG is the larger standard vocabulary, even though your day-to-day choice may come down to which tool lets you read, edit, and verify your work most comfortably.

Alex: That's the takeaway. GitHub Desktop is a solid option when you want Git actions separated from your editor and less dependent on terminal commands. Keep VS Code, the browser, and the CLI nearby, and choose the tool that makes the current task clearest.

Workshop Content

Full chapter content from the Git Going with GitHub workshop guide.

Companion Podcast and Transcript

Use audio and transcript companions to review concepts in a conversational format.

GitHub Desktop

Companion audio: this episode reinforces key ideas and may not be a word-for-word reading of this page.

Open audio file (external) Full transcript source (external)

Transcript preview

Alex: Welcome back. Today we're looking at GitHub Desktop, which is Git in a dedicated graphical app instead of only in the browser, VS Code, or the terminal.

Jamie: I like this topic because a lot of people hear "use Git" and assume the command line is the only serious option.

Alex: It really isn't. GitHub Desktop is free, open source, made by GitHub, and available for Windows and macOS. The appendix works like a reference path through the app: what it can do, how to install and sign in, then cloning, branches, commits, syncing, conflicts, history, and recovery tools.

Jamie: So it's not replacing every tool. It's another way into the same Git workflow.

Appendix H: GitHub Desktop

Episode coming soon: GitHub Desktop - a conversational audio overview of this appendix. Listen before reading to preview the concepts, or after to reinforce what you learned.

Reference companion to: Chapter 01: Choose Your Tools | Also relevant: Chapter 14

Authoritative source: GitHub Desktop Docs

A Visual Git Client for Every Workflow

Who this is for: You want a dedicated graphical Git application — something separate from your code editor, with a clear visual interface for cloning, branching, committing, and managing pull requests. GitHub Desktop is a great fit if you prefer working with a purpose-built Git GUI, or if VS Code's Source Control panel feels too embedded in the editor for your workflow.

GitHub Desktop is free, open source, and made by GitHub. It works on Windows and macOS.

Table of Contents

  1. What GitHub Desktop Does (and Doesn't Do)
  2. Installing GitHub Desktop
  3. Signing In and Authentication
  4. The Interface at a Glance
  5. Cloning a Repository
  6. Creating and Switching Branches
  7. Staging and Committing Changes
  8. Push and Pull
  9. Syncing Your Fork
  10. Resolving Merge Conflicts
  11. Viewing History
  12. Cherry-Pick in GitHub Desktop
  13. Stashing Changes
  14. Undoing Changes
  15. Accessibility and Screen Reader Notes
  16. GitHub Desktop vs VS Code vs Git CLI — When to Use Each

1. What GitHub Desktop Does (and Doesn't Do)

GitHub Desktop covers the everyday Git workflow that most contributors use on most days.

What it supports

  • Supported: Clone repositories from GitHub
  • Supported: Create, switch, and delete branches
  • Supported: Stage files (and individual lines/hunks within files)
  • Supported: Write commit messages and commit
  • Supported: Push and pull from GitHub
  • Supported: Open pull requests (launches GitHub.com in your browser)
  • Supported: Resolve merge conflicts with a visual editor
  • Supported: View commit history and diffs
  • Supported: Cherry-pick commits between branches
  • Supported: Stash and restore uncommitted changes
  • Supported: Undo commits and discard changes

What it does not support (use Git CLI or VS Code terminal instead)

  • Not supported in the GitHub Desktop UI: Interactive rebase (git rebase -i)
  • Not supported in the GitHub Desktop UI: git bisect
  • Not supported in the GitHub Desktop UI: git clean
  • Not supported in the GitHub Desktop UI: Creating annotated tags
  • Not supported in the GitHub Desktop UI: Commit signing (GPG/SSH)

For these operations, open the repository in your terminal directly from GitHub Desktop — Repository → Open in Terminal or Repository → Open in Command Prompt puts you in the right directory instantly.

Learning Cards: What GitHub Desktop Does

Screen reader users
  • GitHub Desktop handles cloning, branching, staging, committing, and pushing -- all accessible via keyboard and standard form controls
  • For operations Desktop does not support (rebase, bisect, clean), use Repository then Open in Terminal to land in the right directory instantly
  • All commit message fields are standard text inputs that screen readers announce as editable text
Low vision users
  • GitHub Desktop supports system-level zoom and high-contrast OS themes on both Windows and macOS
  • The diff panel uses green and red backgrounds for additions and deletions -- pair these with font size adjustments in your OS display settings
  • If the diff colors are hard to distinguish, open the same diff in VS Code via Repository then Open in VS Code for more theme options
Sighted users
  • The three-panel layout (toolbar, file list, diff view) gives you a visual snapshot of your repository state at a glance
  • Look for the badge count on the Fetch/Push button to see how many commits are waiting to push or pull
  • The check mark, plus, and minus icons next to filenames show modified, added, and deleted status instantly

2. Installing GitHub Desktop

Windows

Option A: Winget (recommended)

winget install GitHub.GitHubDesktop

Option B: Direct download

  1. Go to desktop.github.com
  2. Select "Download for Windows"
  3. Run the installer — it installs and launches automatically

macOS

Option A: Homebrew

brew install --cask github

Option B: Direct download

  1. Go to desktop.github.com
  2. Select "Download for macOS"
  3. Open the downloaded .zip, drag GitHub Desktop to your Applications folder

Linux: GitHub Desktop does not officially support Linux. Linux users should use VS Code's Source Control panel or the Git CLI.

3. Signing In and Authentication

GitHub Desktop uses browser-based OAuth sign-in — no tokens or SSH keys needed. It handles authentication for you automatically.

Sign in on first launch

  1. Open GitHub Desktop
  2. Select "Sign in to GitHub.com"
  3. Your browser opens to a GitHub authorization page — sign in with your GitHub account
  4. Authorize GitHub Desktop when prompted
  5. Switch back to GitHub Desktop — you're signed in

That's it. GitHub Desktop stores your credentials securely in the system keychain. You won't be asked for a password again.

If you use GitHub Enterprise or a GitHub organization: Select "Sign in to GitHub Enterprise Server" and enter your organization's server URL.

4. The Interface at a Glance

GitHub Desktop has three main areas:

┌─────────────────────────────────────────────────────────┐
│  Toolbar: Current Repository ▾  |  Current Branch ▾  |  │
│                                    Fetch/Push button      │
├─────────────────┬───────────────────────────────────────┤
│                 │                                         │
│  Left panel:    │  Main area:                            │
│  Changes tab    │  File diff view                        │
│  (staged /      │  (what changed in the selected file)   │
│  unstaged)      │                                        │
│                 │                                         │
│  OR             │                                         │
│                 │                                         │
│  History tab    │  Commit detail / diff                  │
│  (past commits) │                                        │
│                 │                                         │
├─────────────────┴───────────────────────────────────────┤
│  Commit area: Summary field | Description | Commit button │
└─────────────────────────────────────────────────────────┘

Key controls

Element What it does
Current Repository (top left) Switch between your cloned repos
Current Branch (top middle) Switch branches, create new branches
Fetch/Push button (top right) Sync with GitHub (fetch, push, pull)
Changes tab Shows your uncommitted changes
History tab Shows your commit history
Summary field (bottom left) Where you type your commit message
Commit button (bottom left) Commits staged changes

Learning Cards: The Desktop Interface

Screen reader users
  • Use Tab to move between the toolbar, file list, diff pane, and commit area -- each is a distinct focus region
  • The branch selector is a searchable dropdown: type to filter, Down Arrow to navigate, Enter to select
  • The commit button is announced as "Commit to [branch name]" -- press Enter to activate
Low vision users
  • The toolbar at the top stays fixed as you scroll -- repository name, branch, and sync button are always visible
  • Increase your OS display scaling to enlarge all panels proportionally without breaking the layout
  • The Changes and History tabs are side-by-side at the top of the left panel -- each tab label is clearly distinct
Sighted users
  • The left panel toggles between Changes (uncommitted work) and History (past commits) -- click each tab to switch
  • The main diff area updates when you select a different file in the left panel
  • Look for the upward or downward arrow on the Fetch/Push button to see whether you need to push or pull

5. Cloning a Repository

From GitHub.com

The easiest way is to go to the repository on GitHub.com and use the Code button:

  1. On the repository page, activate Code → Open with GitHub Desktop
  2. GitHub Desktop opens with a dialog confirming the URL
  3. Choose where to save the repository on your computer
  4. Select "Clone"

From inside GitHub Desktop

  1. Press Ctrl+Shift+O (Windows) or Cmd+Shift+O (macOS) — "Clone a repository"
  2. Choose the GitHub.com tab to browse your own repositories, or the URL tab to paste any repo URL
  3. Select or type the repository
  4. Choose a local path
  5. Select "Clone"

GitHub CLI alternative

gh repo clone owner/repo-name
# Then open it in GitHub Desktop:
github /path/to/repo

6. Creating and Switching Branches

Create a new branch

  1. Click Current Branch in the toolbar (or press Ctrl+Shift+N / Cmd+Shift+N)
  2. Type a name for your new branch
  3. Select "Create Branch"
  4. Choose whether to base it on the current branch or another — usually keep the default

GitHub Desktop switches to the new branch immediately.

Switch to an existing branch

  1. Click Current Branch in the toolbar
  2. Type to search or scroll through the branch list
  3. Click the branch name — GitHub Desktop switches and updates your files

Delete a branch

  1. Click Current Branch in the toolbar
  2. Right-click the branch you want to delete
  3. Select "Delete..."

Screen reader tip: The branch selector is a dropdown that opens a searchable list. Screen readers announce the currently selected branch name in the toolbar. After switching, the branch name in the toolbar updates to confirm the switch.

7. Staging and Committing Changes

Reviewing your changes

When you edit files in your editor and save them, GitHub Desktop automatically detects the changes and shows them in the Changes tab on the left.

  • The left panel lists every changed file with a checkbox
  • The right panel shows the diff for the selected file — red lines removed, green lines added

Staging files

Every file with a checked checkbox will be included in your next commit.

  • Check all — click the checkbox at the top of the list to stage everything
  • Uncheck a file to exclude it from the commit (it stays as an uncommitted change)

Staging individual lines (hunks)

If a file has multiple changes and you only want to commit some of them:

  1. Select the file in the Changes list
  2. In the diff view, right-click a line or block
  3. Select "Stage Line" or "Stage Hunk" — only those lines get included in the commit

Writing your commit message

  1. In the Summary field at the bottom, type a short commit message (under 72 characters is ideal)
  2. Optionally add a longer description in the Description field below it
  3. Select "Commit to [branch name]" — your changes are committed locally

GitHub Copilot can help: Not sure what to write? Open VS Code alongside GitHub Desktop, open Copilot Chat, and ask: "Write a commit message for these changes: [describe what you changed]." Or use the conventional commit format: feat:, fix:, docs:, refactor:.

Screen reader tip (Windows, NVDA/JAWS): The Summary and Description fields are standard text inputs — navigate to them with Tab and type normally. The commit button is announced as a button labelled "Commit to [branch name]."

8. Push and Pull

After committing, your changes are saved locally but not yet on GitHub. The Fetch/Push button in the top-right toolbar handles syncing.

Pushing commits to GitHub

After committing, the button changes to "Push origin" with an upward arrow and the number of commits waiting.

  • Click "Push origin" — your commits go to GitHub

Pulling changes from GitHub

When collaborators have pushed new commits, the button shows "Pull origin" with a downward arrow.

  • Click "Pull origin" — GitHub Desktop downloads the new commits and updates your local branch

Fetching (checking without pulling)

  • Click "Fetch origin" — GitHub Desktop checks for new commits and shows you the count, but doesn't update your files yet
  • This is safe to do at any time — it's read-only

Keyboard shortcuts

Action Windows macOS
Push / Pull / Fetch Ctrl+P Cmd+P

9. Syncing Your Fork

If you forked a repository and the original upstream repo has new commits you want to bring in:

  1. Go to Branch → Merge into current branch...
  2. In the branch picker, switch to the "Other branches" tab
  3. Select upstream/main (or upstream/master) — the upstream remote's default branch
  4. Select "Create a merge commit"
  5. Then push to your fork with "Push origin"

Setting up the upstream remote (if not already there)

GitHub Desktop adds the upstream remote automatically when you clone a fork from GitHub.com. If it's missing:

  1. Open the repository in terminal: Repository → Open in Terminal
  2. Run:
git remote add upstream https://github.com/ORIGINAL-OWNER/ORIGINAL-REPO.git
git fetch upstream
  1. Switch back to GitHub Desktop — it will now see the upstream branches

10. Resolving Merge Conflicts

When you pull from GitHub or merge a branch and there are conflicts, GitHub Desktop shows a dialog listing the conflicting files.

Step by step

  1. GitHub Desktop shows a "Resolve conflicts before merging" screen

  2. Each conflicting file has two options next to it:

    • "Open in [your editor]" — opens the file with conflict markers for manual editing
    • "Use mine" / "Use theirs" — accept one entire side of the conflict without editing
  3. For simple conflicts (one side is clearly right), use "Use mine" or "Use theirs"
  4. For conflicts where you need to keep parts of both, select "Open in [editor]" and resolve manually

After resolving in your editor

  1. Save the file
  2. Switch back to GitHub Desktop — the file moves from "Conflicting" to "Resolved"
  3. Once all conflicts are resolved, select "Continue merge"

GitHub Copilot can help: Open the conflicting file in VS Code alongside GitHub Desktop. Place your cursor inside a conflict region and open Copilot Chat (Ctrl+Alt+I, or Chat: Open Chat from the Command Palette if your keymap differs): "Resolve this merge conflict - keep meaningful changes from both sides." Copilot suggests a resolution; you review and save.

Screen reader tip: The conflicts dialog lists files as a navigable list. Each file entry includes the action buttons ("Open in editor", "Use mine", "Use theirs"). Navigate with Tab between the file entries and buttons.

11. Viewing History

The History tab (next to the Changes tab in the left panel) shows every commit on the current branch.

  1. Click the History tab
  2. Each commit appears as a row: author avatar, commit message, author name, and timestamp
  3. Click any commit to see the full diff on the right — what changed in each file

Filtering commits

Type in the search field above the commit list to filter by commit message, author, or SHA.

Viewing a specific file's history

  1. Right-click any file in your project (via the Files panel in the diff area)
  2. Select "Show in History" — the commit list filters to only commits that touched that file

Comparing branches

  1. Click History
  2. In the branch comparison bar above the commit list, switch to another branch
  3. GitHub Desktop shows the commits that are different between your current branch and the selected branch

12. Cherry-Pick in GitHub Desktop

Cherry-pick lets you take a commit from another branch and apply it to your current branch — without merging the whole branch.

How to cherry-pick

  1. Switch to the branch you want to copy the commit FROM (the source branch)
  2. Open the History tab
  3. Find the commit you want to copy
  4. Right-click the commit
  5. Select "Cherry-pick commit..."
  6. Choose the destination branch — the branch you want to apply the commit TO
  7. GitHub Desktop applies the commit and switches to the destination branch

If there's a conflict

GitHub Desktop shows the conflict resolution screen (same as merging). Resolve the conflicts in your editor, then switch back to GitHub Desktop to continue.

GitHub Copilot can help: Before cherry-picking, open Copilot Chat and paste the commit diff: "What does this commit do? Is it safe to cherry-pick onto a branch that doesn't have the surrounding context?"

13. Stashing Changes

Stash saves your uncommitted changes temporarily so you can switch branches or pull without committing half-finished work.

Stash your changes

  1. Go to Branch → Stash All Changes (or press Ctrl+Shift+H / Cmd+Shift+H)
  2. Your working directory reverts to the last commit
  3. You can now switch branches safely

Restore your stash

  1. Switch back to the branch where you stashed
  2. Go to Branch → Pop Stash
  3. Your changes come back

Note: GitHub Desktop supports one stash at a time per branch. For multiple stashes, use the Git CLI: git stash list, git stash apply stash@{1}. See Chapter 14, Section 10 for the full stash guide.

14. Undoing Changes

Undo the last commit

Go to Edit → Undo Last Commit (or press Ctrl+Z / Cmd+Z right after committing)

This is equivalent to git reset --soft HEAD~1 — your changes come back as staged files. Nothing is lost.

Discard changes to a file

In the Changes tab:

  1. Right-click a file
  2. Select "Discard Changes..."
  3. Confirm the dialog — the file reverts to its last committed state

Warning: Discarding changes cannot be undone. The changes are permanently deleted, not moved to trash.

Discard all changes

  1. Right-click anywhere in the Changes list
  2. Select "Discard All Changes..."
  3. Confirm — everything in your working directory reverts to the last commit

15. Accessibility and Screen Reader Notes

GitHub Desktop has partial screen reader support. Core workflows work well with keyboard navigation; some visual-only elements (like avatar images and some icons) don't have text equivalents.

What works well

Feature Accessibility notes
Commit message fields Standard text inputs, fully accessible
Branch selector Searchable dropdown, keyboard navigable
File list (Changes/History) Arrow keys to navigate, checkboxes announceable
Commit button Labelled with branch name, activatable with Enter
Conflict resolution dialog Buttons ("Use mine", "Use theirs") are labelled
Keyboard shortcut access Most operations have keyboard shortcuts

What has limitations

Feature Limitation
Diff view The colored diff panel is partially accessible; individual lines may not be announced clearly on all platforms. Workaround: Open in VS Code for better diff navigation
File icons Status icons (M for modified, A for added, D for deleted) may not always be announced — the filename is still readable
Context menus Right-click context menus work via keyboard (Shift+F10 on Windows; Ctrl+Click on macOS)

Windows — NVDA / JAWS

  • Use Tab to move between panels; arrow keys within lists
  • The commit summary field is reached with Tab after the file list
  • Conflict dialogs are modal — screen reader focus moves into the dialog automatically

macOS — VoiceOver

  • Use Tab and VO+Arrow to navigate panels
  • The diff view can be explored with VO+Right through the lines
  • Branch selector opens a searchable popup — type to filter, Down Arrow to navigate, Return to select

VS Code as a better accessible alternative

If screen reader navigation in GitHub Desktop is frustrating for a specific operation, VS Code's Source Control panel is often more accessible. The two tools complement each other — use whichever works best for the task at hand.

Learning Cards: Desktop Accessibility

Screen reader users
  • Commit message fields, branch selector, and conflict resolution buttons are fully keyboard-accessible and announced
  • The diff panel has partial screen reader support -- for difficult diffs, switch to VS Code's Accessible Diff Viewer (F7 / Alt+F2)
  • Use Shift+F10 on Windows to open context menus via keyboard when right-click actions are needed
Low vision users
  • File status icons (M, A, D) are small -- increase OS scaling or watch for the filename and status text that accompany them
  • The conflict resolution dialog uses labeled buttons ("Use mine", "Use theirs") that are easy to identify at any zoom level
  • If diff colors are indistinguishable at your contrast settings, open the same file in VS Code for richer theme support
Sighted users
  • The colored diff highlights (green for added, red for removed) are visible in the main panel as soon as you click a file
  • Modal conflict dialogs appear front-and-center with clear action buttons -- no hunting required
  • Keyboard shortcuts like Ctrl+Shift+O (Clone) and Ctrl+Shift+N (New Branch) speed up common workflows visually

16. GitHub Desktop vs VS Code vs Git CLI — When to Use Each

Situation Best tool
You want a clean visual overview of changes before committing GitHub Desktop
You want to stage individual lines or hunks GitHub Desktop or VS Code
You're doing complex operations (rebase, bisect, clean) Git CLI (terminal)
You want the fastest screen-reader-friendly experience Git CLI or VS Code terminal
You want to open a PR or manage issues without leaving your tool VS Code (GitHub Pull Requests extension)
You want to manage multiple repos at once with a visual switcher GitHub Desktop
You're doing quick commits mid-coding session VS Code (Source Control panel — already open)

GitHub Desktop, VS Code, and the Git CLI all talk to the same Git repository. You can switch between them freely — use GitHub Desktop to stage and commit, then open the terminal for a git rebase -i. They don't conflict.

Next: Appendix I: GitHub CLI Reference
Back: Appendix G: VS Code Reference
Teaching chapter: Chapter 01: Choose Your Tools

Authoritative Sources

Use these official references when you need the current source of truth for facts in this chapter.

Section-Level Source Map

Use this map to verify facts for each major section in this file.