GIT Going with GitHub

Day 1 Chapter Episode 44 10-12 min

Choose Your Tools

A guided tour of browser GitHub, github.dev, VS Code, GitHub Desktop, and the CLI.

Workshop docs

choose your tools

Listen

Download MP3 Subscribe via RSS

Transcript

Alex: Welcome back. Today we're doing something that can save a lot of frustration later: choosing the tool that fits the job, instead of assuming there is one correct way to use GitHub.

Jamie: I like that framing, because people can feel behind before they even start. One person is in a browser, someone else is in VS Code, someone else is using a terminal, and it can sound like they are all in different workshops.

Alex: They are using different doors into the same work. The workshop supports multiple tool paths because real teams do that too. A chapter might say, "open the file," and your job is to know whether that means the GitHub website, github.dev, VS Code, GitHub Desktop, or the GitHub CLI for you.

Jamie: So we are not choosing a tool forever. We are learning what each one is good at, what it cannot do, and how it feels with a screen reader or low vision setup.

Alex: There are five environments in this tour. GitHub.com is the website in your browser. github.dev is a browser-based editor that feels like VS Code. VS Code is the full desktop editor. GitHub Desktop is a graphical Git app. And GitHub CLI is a command-line tool called `gh`.

Jamie: Do learners need to install all of them?

Alex: No. Most people start with GitHub.com on Day 1, because it needs no installation and it is where issues, pull requests, repository pages, and reviews already live. Many learners add VS Code on Day 2 when they need a full workspace for editing, running commands, and working across files.

Jamie: And the other tools are not extra credit tools. They are alternate routes if they match the way you work.

Alex: Exactly. Later lessons use tool cards, which are expandable notes that show the same task in different tools. That way, you can follow the path that fits your access needs, your comfort level, and the task in front of you.

Jamie: Let's start with the browser, because that is the foundation for Day 1.

Alex: GitHub.com is the GitHub website. If you can sign in at github.com, you can browse repositories, open files, create and comment on issues, review pull requests, merge when you have permission, manage labels and project boards, and edit a single file with the built-in web editor.

Jamie: But it is not a full development environment.

Alex: Right. You cannot run code locally there, you do not get a full editor with desktop extensions, and you cannot work offline. It is excellent for collaboration and repository navigation, but limited for deeper coding work.

Jamie: How does it feel with a screen reader?

Alex: GitHub.com has strong screen reader support. Pages use landmarks, headings are generally consistent, and many actions have keyboard shortcuts. You can jump to main content or search with `S`, use `/` for search in many places, move by headings with `H`, and move by landmarks with `D` in browse mode. In a repository, `G` then `I` can take you to Issues.

Jamie: And for low vision users, the theme controls matter a lot.

Alex: They do. In appearance settings, you can choose light, dark, light high contrast, dark high contrast, or sync with your operating system. GitHub also responds well to browser zoom, and the layout usually adapts up to high zoom levels. The learning cards also remind people to enable link underlines in accessibility settings so links are not identified by color alone.

Jamie: github.dev feels like the bridge tool to me. It is still in the browser, but it is more editor-like.

Alex: That is a good way to put it. github.dev runs a VS Code-style editor in your browser, with a file explorer, tabs, diffs, staging, and commits. You can open it from a repository by pressing the period key, or by changing `github.com` to `github.dev` in the address bar.

Jamie: So if I am viewing a file on GitHub and I press period, I move into that editor experience?

Alex: Yes. It is especially useful when a change touches more than one file, or when you want a clearer editing workspace without installing anything. You can edit files, review the differences, and commit to a branch.

Jamie: What should people not expect from it?

Alex: It does not run your program, build your project, or execute normal terminal commands. Some browser-compatible VS Code extensions work, but anything that needs a local runtime may not. And like GitHub.com, it is not an offline tool.

Jamie: Any screen reader notes there?

Alex: Because github.dev is VS Code in the browser, the command palette is a central control point. Use `Ctrl+Shift+P` on Windows or Linux, and `Cmd+Shift+P` on macOS. Some screen readers may need focus mode or application mode in the editor area. If keys are not reaching the editor, press `Escape`, then try the command palette again.

Jamie: Then there is full VS Code on the desktop.

Alex: VS Code is the workshop's main full workspace for Day 2 and beyond. It does require installation, along with Git for local version control. Once set up, it gives you editing, extensions, an integrated terminal, Git tools, debugging, and GitHub Copilot features in one place.

Jamie: This is where you can actually run commands and test code on your own machine.

Alex: Exactly. You can stage, commit, push, and pull through the Source Control panel, or use the terminal if you prefer commands. You can run scripts, use language tools, install extensions, and keep working offline, then sync when you are back online.

Jamie: What does it not do by default?

Alex: Without extensions, VS Code does not give you the full GitHub issue and pull request workflow inside the editor. For that, you usually add the GitHub Pull Requests extension. You can still use Git from VS Code without it, but issues and pull request review may send you back to the website.

Jamie: And accessibility-wise, VS Code has its own learning curve.

Alex: It does, but it also has good keyboard support and screen reader features. The command palette is useful here too, because it lets you search for commands instead of hunting through menus. Low vision users can adjust themes, zoom, font size, and high contrast settings. The VS Code reference appendix is there for deeper setup help when learners are ready.

Jamie: Where does GitHub Desktop fit? I sometimes hear people assume it is only for beginners, but that seems unfair.

Alex: It is a real tool, and it can be a good fit. GitHub Desktop is a desktop Git client with a visual interface for cloning repositories, creating branches, seeing changed files, writing commits, pushing, pulling, and syncing with GitHub.

Jamie: So it helps with Git without requiring people to type Git commands.

Alex: Yes. That can reduce stress when the goal is to understand branches, commits, and sync status. It is also nice for reviewing a set of changed files before committing.

Jamie: But it is not a code editor, right?

Alex: Right. You usually pair it with an editor such as VS Code. It also does not run your project, and it is not the best choice for automation or scripted workflows. For issues, pull requests, settings, and deeper review, you may still move back to GitHub.com.

Jamie: How should screen reader users approach it?

Alex: Try it with your own screen reader before relying on it for a timed task. Some people like the clear commit workflow, while others find the browser or terminal more predictable. If it matches your access setup, it can be a comfortable middle ground.

Jamie: Now for the terminal people: the GitHub CLI.

Alex: The GitHub CLI is a command-line tool called `gh`. It lets you interact with GitHub from a terminal, so you can create issues, view pull requests, check repository information, authenticate, and automate repeated tasks.

Jamie: That sounds powerful, but also a little unforgiving.

Alex: It can be, which is why the learning path should start small. Install the tool, sign in with `gh auth login`, use `gh help`, and try one safe read-only command before changing anything. The goal is to build trust in what each command does.

Jamie: What can it not do for you?

Alex: It does not replace a code editor. You still need something to edit files, and you still need Git itself for many local repository operations. The CLI is strongest when you want speed, scripting, repeatable commands, or a terminal-first workflow.

Jamie: And for screen reader users, terminals can actually be appealing.

Alex: Yes, because command output can be linear and predictable. But precision matters. A missing flag or a wrong repository can change the result, so it helps to read command output carefully and use help text often. The CLI learning cards point learners toward small commands, authentication, and pull request workflows instead of trying to memorize everything.

Jamie: If someone is deciding where to start, what is the plain recommendation?

Alex: Start Day 1 in GitHub.com. The Learning Room repository is provisioned for each learner, and the early contribution workflow happens there: issue, branch, commit, pull request, and merge. The browser keeps everyone close to the collaboration pieces.

Jamie: Then Day 2 is when VS Code becomes more important.

Alex: Yes. When you need a full editing workspace, a terminal, extensions, Copilot, or local testing, VS Code is the recommended main path. github.dev is helpful when you want a quick editor without installation. GitHub Desktop is helpful when you want a visual Git workflow. The CLI is helpful when the terminal is comfortable or automation is part of the work.

Jamie: So switching tools is normal, not a sign that you chose wrong.

Alex: Absolutely. You might open an issue in the browser, edit three files in github.dev, test locally in VS Code, commit through GitHub Desktop, and check a pull request with the CLI. The best tool is the one that lets you understand the task, make the change, and verify what happened.

Jamie: I like ending with something small. What is the first confidence exercise?

Alex: Pick any repository you can safely explore, ideally your Learning Room repository once it is available. Find the README file, open it, and identify how you would make a small edit in each tool you are trying. You do not have to commit a real change in every tool. The exercise is about knowing where the file lives and how editing would begin.

Jamie: In GitHub.com, that means opening the README on the website and finding the edit control, usually the pencil icon when you have permission.

Alex: Yes. In github.dev, press period from the repository page or change the URL, then find the README in the explorer. In VS Code, open the cloned repository folder and find the README in the file explorer. If VS Code is not set up yet, skip that route for now.

Jamie: In GitHub Desktop, you would clone or open the repository, then use its option to open the files in your external editor.

Alex: And in the CLI, you might use `gh repo view` to confirm the repository, then use normal Git and your editor for file changes. Success looks simple: you can say which tool you used, where the repository was, where the README was, and what you would do before committing a change.

Jamie: And if someone gets stuck, what should they check before assuming they broke something?

Alex: Check the basics in order: which tool am I in, which repository am I looking at, which branch is active, which file is open, and have I actually saved the change? Then look for the matching appendix or official documentation for that tool. VS Code setup, GitHub Desktop, the GitHub CLI manual, and the GitHub Accessibility Lab CLI guide are all useful references.

Jamie: And when asking for help, include the tool and the exact point where things stopped making sense.

Alex: Yes. "I am in github.dev, on my Learning Room repository, trying to open the README, and the period key did not open the editor" is much easier to help with than "GitHub does not work." Clear context helps someone reproduce the problem or suggest a different path.

Jamie: That is a reassuring place to land. You do not have to become a browser expert, editor expert, desktop app expert, and terminal expert all at once. You just need enough orientation to choose the route that supports the work you are doing today.

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.

Choose Your Tools

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 doing something that can save a lot of frustration later: choosing the tool that fits the job, instead of assuming there is one correct way to use GitHub.

Jamie: I like that framing, because people can feel behind before they even start. One person is in a browser, someone else is in VS Code, someone else is using a terminal, and it can sound like they are all in different workshops.

Alex: They are using different doors into the same work. The workshop supports multiple tool paths because real teams do that too. A chapter might say, "open the file," and your job is to know whether that means the GitHub website, github.dev, VS Code, GitHub Desktop, or the GitHub CLI for you.

Jamie: So we are not choosing a tool forever. We are learning what each one is good at, what it cannot do, and how it feels with a screen reader or low vision setup.

Choose Your Adventure: A Tool Tour

Related appendices: Appendix G: VS Code Reference | Appendix H: GitHub Desktop | Appendix I: GitHub CLI | Appendix J: Codespaces Authoritative sources: VS Code Docs: Setup | GitHub Desktop Docs | GitHub CLI Manual | GitHub Accessibility Lab: CLI Guide

Day 1, Opening Material

Before you write your first line of code, you need to know what tools are available and which ones match the way you work. This chapter is a guided tour of the five tool environments you can use throughout this workshop. You do not need to install anything right now -- just explore what is available so you can make confident choices later.

Table of Contents

  1. Why This Matters
  2. The Five Paths
  3. Path 1: GitHub.com (Browser)
  4. Path 2: github.dev (Browser-Based Editor)
  5. Path 3: VS Code (Desktop)
  6. Path 4: GitHub Desktop
  7. Path 5: GitHub CLI
  8. Which Path Should I Start With?
  9. Your First Confidence Exercise
  10. If You Get Stuck

1. Why This Matters

There is no single "right" way to use GitHub. Some people prefer a browser. Some prefer a desktop application. Some prefer a terminal. Some switch between all of them depending on the task.

The workshop is designed so that every exercise can be completed using any of the five paths described below. When a chapter gives step-by-step instructions, it always covers at least the browser path and one local path. In later chapters, you will see tool cards -- expandable blocks that show how to complete a step using each tool.

Your job in this chapter is not to pick one path forever. It is to understand what each path offers so that when a chapter says "open the file," you know where that happens in your tool of choice.

Screen reader note: Every path in this chapter is described by its interface behavior, not its visual appearance. If a path works well with your screen reader, that information is stated up front.

2. The Five Paths

The following table summarizes all five environments at a glance. Read through the summaries first, then explore the sections that interest you.

Path What It Is Needs Installation? Best For
GitHub.com The GitHub website in your browser No Issues, pull requests, repository navigation, code review
github.dev A VS Code editor that runs inside your browser No Editing files, multi-file changes, quick commits
VS Code A desktop code editor with Git built in Yes Full development, extensions, terminal, Copilot
GitHub Desktop A desktop Git client with a visual interface Yes Branching, committing, and syncing without typing commands
GitHub CLI A command-line tool called gh Yes Scripting, automation, power users who prefer the terminal

You do not need all five. Most students start with GitHub.com (Path 1) on Day 1 and add VS Code (Path 3) on Day 2. The other paths are available if they match your workflow.

3. Path 1: GitHub.com (Browser)

What it is: The GitHub website at github.com. Every repository, issue, pull request, and setting lives here. If you have a browser, you have GitHub.

No installation required. Sign in at github.com and you are ready.

What you can do here

  • Browse repositories, files, and folders
  • Create, comment on, and close issues
  • Open, review, and merge pull requests
  • Edit individual files using the built-in web editor (pencil icon)
  • Manage labels, milestones, and project boards
  • Configure repository settings and branch protection

What you cannot do here

  • Run code or tests locally
  • Use a full-featured code editor with extensions
  • Make offline changes

Screen reader experience

GitHub.com has strong screen reader support. Every page uses ARIA landmarks, headings follow a consistent hierarchy, and keyboard shortcuts are available for most actions.

Key navigation patterns:

Action How to do it
Jump to main content S shortcut on any page, or navigate to the "main" landmark
Open search / or S key
Navigate tabs (Code, Issues, PRs) D to the "Repository navigation" landmark, then arrow keys
Jump between headings H key in browse mode
Jump between landmarks D key in browse mode

Screen reader tip: Chapter 2 covers GitHub's page structure in full detail. If you are new to GitHub with a screen reader, read that chapter next.

Low vision experience

GitHub supports light and dark themes, high contrast themes, and responds to your operating system's contrast preferences. To configure your preferred theme:

  1. Go to github.com/settings/appearance
  2. Choose from Light, Dark, Light high contrast, or Dark high contrast
  3. Or select "Sync with system" to follow your OS setting

GitHub's layout adapts to browser zoom up to 400% without horizontal scrolling on most pages.

Learning Cards: GitHub.com (Browser)

Screen reader users
  • Press S on any GitHub page to jump to the main search field; press / as an alternative
  • Press D in Browse Mode to jump between ARIA landmark regions; the repository tabs (Code, Issues, Pull Requests) are inside the "Repository navigation" landmark
  • Press G then I (two keystrokes in sequence) to jump directly to the Issues tab from anywhere in a repository
Low vision users
  • Switch to "High contrast dark" or "High contrast light" at github.com/settings/appearance for maximum border and text contrast
  • Browser zoom up to 200% keeps GitHub's layout intact; above 200% the repository sidebar collapses into a hamburger menu
  • Enable "Link underlines" in GitHub Accessibility settings so links are distinguishable without color
Sighted users
  • The repository navigation tabs (Code, Issues, Pull Requests, etc.) appear as a horizontal bar just below the repository name
  • Code files turn into clickable links in the file tree; folders show a folder icon and files show a document icon
  • The green "Code" dropdown button on the repository home page is where you find clone URLs and the "Open with github.dev" option

4. Path 2: github.dev (Browser-Based Editor)

What it is: A VS Code editor that runs entirely in your browser. Open any repository by pressing the . key on its GitHub page, or by changing github.com to github.dev in the URL.

No installation required. Same browser, same sign-in, richer editor.

What you can do here

  • Edit multiple files in a VS Code-like interface with a file explorer, tabs, and an integrated terminal preview
  • View file diffs and stage changes
  • Commit directly to a branch
  • Use many VS Code extensions that run in the browser

What you cannot do here

  • Run code, build projects, or execute terminal commands (the terminal is read-only for Git operations)
  • Use extensions that require a local runtime (debuggers, compiled tools)
  • Work offline

How to open it

Method Steps
From any repo page Press the . (period) key on your keyboard
From the URL bar Change github.com to github.dev in the URL
From a file While viewing a file on GitHub.com, press . to open it in the editor

Screen reader experience

github.dev is VS Code running in the browser, so the same keyboard navigation and screen reader support applies. The command palette (Ctrl+Shift+P or Cmd+Shift+P) is available, and all editor keybindings work.

Note: Some screen readers may need to switch to focus mode or application mode to interact with the editor area. If keystrokes are not reaching the editor, try pressing Escape to ensure focus is in the editor, then Ctrl+Shift+P for the command palette.

When to use github.dev over GitHub.com

Use github.dev when you need to edit more than one file in a single commit, or when you want the code editor experience without installing anything. For single-file edits, the pencil icon on GitHub.com is simpler.

5. Path 3: VS Code (Desktop)

What it is: Visual Studio Code is a free desktop code editor from Microsoft. It has built-in Git support, an integrated terminal, thousands of extensions, and GitHub Copilot included.

Installation required. Download from code.visualstudio.com. Installation is covered in Chapter 0, Step 6.

What you can do here

  • Edit files with full IntelliSense, syntax highlighting, and extension support
  • Use the integrated terminal to run Git commands, scripts, and programs
  • Stage, commit, push, and pull using the Source Control panel or the terminal
  • Run and debug code
  • Use GitHub Copilot for code suggestions, chat, and code review
  • Work offline (Git operations sync when you reconnect)

What you cannot do here (without extensions)

  • Manage GitHub issues and pull requests directly (install the GitHub Pull Requests extension for this)
  • View repository insights or settings (use GitHub.com for that)

Screen reader experience

VS Code has a dedicated accessibility mode that activates automatically when a screen reader is detected. Key features:

  • Screen reader optimized mode announces line content, cursor position, and editor state
  • The Accessibility Help dialog (Alt+F1 or Option+F1) is available in every view
  • All panels are reachable via keyboard shortcuts:
Panel Shortcut (Windows/Linux) Shortcut (macOS)
File Explorer Ctrl+Shift+E Cmd+Shift+E
Source Control Ctrl+Shift+G Cmd+Shift+G
Terminal Ctrl+` Cmd+`
Command Palette Ctrl+Shift+P Cmd+Shift+P
Extensions Ctrl+Shift+X Cmd+Shift+X
Problems panel Ctrl+Shift+M Cmd+Shift+M

Deep dive: Chapter 11 covers the VS Code interface in detail. Chapter 12 covers accessibility-specific configuration. Appendix G is the quick-reference card.

Low vision experience

VS Code supports high contrast themes, custom zoom levels (Ctrl+= to zoom in, Ctrl+- to zoom out), and configurable font sizes. The minimap (the small code preview on the right side of the editor) can be disabled if it is distracting: open the command palette, type "minimap," and toggle the setting.

Learning Cards: VS Code (Desktop)

Screen reader users
  • Press Ctrl+Shift+E to focus the File Explorer tree; Up/Down Arrow navigates files, Enter opens a file, Right Arrow expands a folder
  • Press Ctrl+Shift+G to focus Source Control; the tree lists changed files and each item announces its Git status (modified, untracked, etc.)
  • Press Alt+F1 inside any view to open the Accessibility Help dialog, which lists every keyboard shortcut for that specific panel
Low vision users
  • Press Ctrl+K Ctrl+T to open the theme picker; "High Contrast" and "High Contrast Light" offer the strongest visual differentiation
  • Press Ctrl+= repeatedly to zoom the entire interface; the zoom level persists after restart
  • Disable the minimap to reclaim screen width: Ctrl+Shift+P, type "minimap", toggle "Editor: Minimap Enabled" off
Sighted users
  • The Activity Bar (left edge) shows icons for Explorer, Search, Source Control, Run/Debug, and Extensions; a dot badge means there is activity in that panel
  • The Status Bar (bottom edge) shows your current Git branch on the far left and sync status (cloud icon with arrows) next to it
  • Click the split-editor icon (top right of any tab) to view two files side by side for comparison

6. Path 4: GitHub Desktop

What it is: A desktop application that provides a graphical interface for Git operations. Instead of typing git commit in a terminal, you use buttons, lists, and visual diffs.

Installation required. Download from desktop.github.com. See Appendix H for setup details.

What you can do here

  • Clone repositories with one click
  • Create, switch, and merge branches
  • View file diffs in a side-by-side or unified view
  • Stage individual files or specific lines within a file
  • Commit with a message and push to GitHub
  • Open pull requests (launches GitHub.com)

What you cannot do here

  • Edit code (GitHub Desktop is a Git client, not a code editor -- it opens your preferred editor)
  • Review pull requests with inline comments
  • Manage issues, labels, or project boards

Screen reader experience

GitHub Desktop uses Electron and provides basic screen reader support. Branch switching, commit history, and file lists are navigable. However, the diff viewer has limited screen reader support compared to the VS Code diff viewer or the GitHub.com Files Changed tab.

Recommendation for screen reader users: GitHub Desktop works best as a companion to VS Code or a text editor. Use VS Code for editing and reviewing diffs, and GitHub Desktop for visual branch management if you prefer a graphical tool.

When to choose GitHub Desktop

Choose GitHub Desktop if you prefer a visual representation of branches and commits, and you do not want to memorize Git commands. It is a good stepping stone between the GitHub.com web editor and the full VS Code workflow.

7. Path 5: GitHub CLI

What it is: A command-line tool called gh that brings GitHub features to your terminal. It handles authentication, issue management, pull request workflows, and repository operations -- directly from the command line.

Installation required. Install via winget install GitHub.cli (Windows), brew install gh (macOS), or see Appendix I for full instructions.

Getting started principles (CLI learning path)

Use this sequence for the most reliable onboarding experience:

  1. Start with local Git basics (git status, git add, git commit) before remote workflows.
  2. Add GitHub CLI (gh) once local operations feel predictable.
  3. Use plain-text command output as your primary verification layer.
  4. Keep browser workflows available for confirmation and recovery.
  5. Use short command cycles: run one command, confirm output, then continue.

What you can do here

  • Create, view, and close issues: gh issue create, gh issue view 42
  • Open, review, merge PRs: gh pr create, gh pr review, gh pr merge
  • Clone repos and manage branches: gh repo clone owner/repo
  • View CI/CD status: gh run list, gh run view
  • Manage repository settings, labels, and releases
  • Automate workflows with shell scripts

What you cannot do here

  • Edit files (the CLI manages GitHub operations, not file editing -- use your preferred editor)
  • View visual diffs (use git diff for text-based diffs, or VS Code for a richer view)

Screen reader experience

The GitHub CLI is a text-based tool running in a terminal. Screen reader users read its output directly as plain text -- no landmarks, headings, or ARIA to worry about. Output is generally well-formatted with tables and structured text.

Tip for terminal users: The gh command integrates with git seamlessly. After running gh repo clone, all standard git commands work in the cloned directory. You can mix git and gh commands freely.

When to choose GitHub CLI

Choose the CLI if you are comfortable in a terminal and want fast, scriptable access to GitHub features. It pairs well with VS Code's integrated terminal, giving you the best of both worlds.

Learning Cards: GitHub CLI

Screen reader users
  • CLI output is plain text; use Up Arrow to re-read previous lines or pipe output through more to page through long results
  • Run gh issue list --state open and output reads as a tab-separated table; each row is one line your screen reader can navigate
  • Use gh pr view --web to open the current PR directly in your browser where full ARIA landmarks are available
Low vision users
  • Increase terminal font size in VS Code: Settings (Ctrl+,), search "terminal.integrated.fontSize" and set to 18-24
  • Use gh pr diff to view diffs in the terminal with colored additions (green) and deletions (red); if colors are hard to see, pipe through less -R for paginated output
  • Set your terminal theme to high contrast in VS Code's theme picker (Ctrl+K Ctrl+T) to improve command and output readability
Sighted users
  • The gh tool uses colored output by default: green for success, red for errors, yellow for warnings
  • Run gh repo view --web to instantly open the current repository's GitHub page in your browser
  • Tab completion is available after running gh completion -s powershell | Out-String | Invoke-Expression in PowerShell

8. Which Path Should I Start With?

There is no wrong answer, but here is practical guidance based on when different tools become most useful in the workshop.

Day 1 recommendation

Your comfort level Recommended starting path Why
New to GitHub, new to coding GitHub.com (browser) Everything happens in one window. No installs. Clear, labeled interface.
Some web experience, want to edit files GitHub.com + github.dev Use the browser for navigation, press . to edit when needed.
Already use VS Code VS Code + GitHub.com Edit locally, use the browser for issues and PRs.

Day 2 recommendation

On Day 2, you work with Git locally. Most students add VS Code (Path 3) at this point:

Your Day 1 path Day 2 addition How they work together
GitHub.com only Add VS Code Clone the repo, edit locally, push changes, review PRs in the browser
GitHub.com + github.dev Add VS Code Transition from browser editing to local editing with full tool support
VS Code already Add GitHub CLI (optional) Speed up repetitive operations like creating issues and PRs

Switching paths is normal

You will likely use more than one tool during the workshop. The tools complement each other:

  • Browse the repository on GitHub.com to understand its structure
  • Edit files in VS Code or github.dev for a better coding experience
  • Manage branches in GitHub Desktop if you prefer the visual workflow
  • Automate repetitive tasks with the GitHub CLI

The workshop chapters always tell you which tool to use for each step. If a step says "open the file in your editor," use whichever editor you chose.

Learning Cards: Which Path Should I Start With?

Screen reader users
  • Start with GitHub.com on Day 1; its ARIA landmarks, heading hierarchy, and single-key shortcuts (G I for Issues, G P for Pull Requests) provide the most navigable experience
  • When Day 2 adds VS Code, press Shift+Alt+F1 immediately to enable Screen Reader Optimized mode before doing anything else
  • You can switch tools mid-exercise; the workshop always tells you which tool each step targets, so look for the tool name at the start of each instruction
Low vision users
  • GitHub.com at 150-200% zoom with a high-contrast theme is the easiest starting environment; no installation needed
  • When you add VS Code on Day 2, set both the editor zoom (Ctrl+=) and the font size (Settings, "editor.fontSize") independently for maximum comfort
  • GitHub Desktop's visual branch diagram uses thin colored lines; if those are hard to see, stick with VS Code's Source Control panel which uses text labels
Sighted users
  • Start with GitHub.com to learn the layout; the repository tabs, file tree, and right-hand sidebar become familiar quickly
  • On Day 2, VS Code's split-pane layout lets you view the terminal and editor side by side, which speeds up the Git workflow
  • If you like visual branch history, GitHub Desktop draws branches as colored lines in a timeline; VS Code's Source Control panel is text-based by default

9. Your First Confidence Exercise

This exercise takes approximately five minutes. It verifies your tool is working and builds your confidence before Day 1 begins.

The task

Open the public workshop curriculum repository and find the README file.

Path 1: GitHub.com

  1. Go to github.com/Community-Access/git-going-with-github.
  2. The README is displayed below the file list on the repository's home page.
  3. Screen reader users: press H to navigate headings. The README's first heading announces the repository name.
  4. You are done when you can read the first paragraph of the README.

Path 2: github.dev

  1. Go to github.dev/Community-Access/git-going-with-github.
  2. The file explorer opens on the left. Press Ctrl+Shift+E (or Cmd+Shift+E) to focus it.
  3. Navigate to README.md and press Enter to open it in a tab.
  4. You are done when the file content appears in the editor.

Path 3: VS Code (if set up)

  1. Open VS Code.
  2. Open the command palette: Ctrl+Shift+P (or Cmd+Shift+P).
  3. Type "Git: Clone" and press Enter.
  4. Paste the URL: https://github.com/Community-Access/git-going-with-github.git
  5. Choose a folder to clone into and wait for the download.
  6. When it finishes, VS Code offers to open the repository. Accept.
  7. Open the file explorer (Ctrl+Shift+E) and select README.md.
  8. You are done when the file content appears in the editor.

Path 4: GitHub Desktop

  1. Open GitHub Desktop.
  2. Go to File, then Clone repository (or press Ctrl+Shift+O).
  3. Paste the URL: https://github.com/Community-Access/git-going-with-github.git
  4. Choose a local path and click Clone.
  5. Once cloned, the repository appears in GitHub Desktop. Click "Open in Visual Studio Code" (or your preferred editor) to read the README.

Path 5: GitHub CLI

  1. Open your terminal.
  2. Run:
gh repo clone Community-Access/git-going-with-github
cd learning-room
  1. Open the README in your preferred way:
cat README.md       # print to terminal
code README.md      # open in VS Code
  1. You are done when you can read the first paragraph.

What success looks like

You opened a real repository and found a real file. That is the core action of this entire workshop -- everything else builds on it.

10. If You Get Stuck

Problem What to try
Cannot sign in to GitHub.com Verify your email and password. Check Chapter 0, Step 1.
github.dev does not open Ensure you are signed in to GitHub.com first. Some browsers block the redirect -- try Chrome or Firefox.
VS Code is not installed Follow Chapter 0, Step 6.
Git clone fails Check your internet connection. Verify Git is installed: run git --version in a terminal. See Appendix D for authentication issues.
Screen reader does not announce page content Ensure browse mode is active (NVDA: press Escape; JAWS: press Num Pad Plus). Maximize the browser window.
Not sure which path to choose Start with GitHub.com in your browser. You can always add more tools later.
GitHub Desktop cannot find the repo Verify the URL is correct and your GitHub account has access to the repository.
GitHub CLI says "not authenticated" Run gh auth login and follow the prompts. See Appendix I.

Next Step: Start your learning journey with Chapter 02: Understanding GitHub.

Next: Chapter 02: Understanding GitHub
Back: Chapter 00: Pre-Workshop Setup
Related appendices: Appendix H: GitHub Desktop | Appendix I: GitHub CLI | Appendix J: Codespaces

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.