Push Changes to GitHub with VS Code and NVDA

Watch the video

I use NVDA and the keyboard to move a local change through review, staging, committing and pushing. The final check happens on GitHub: I refresh the repository page and read the updated README.

Before you start

This continues Create and Clone a GitHub Repository with NVDA. Have your own repository cloned locally, Git installed in the environment where you run your commands, and a GitHub account with permission to push to that repository.

I demonstrate Windows 11, NVDA, VS Code, WSL Ubuntu and Brave. Install VS Code and set up WSL and Ubuntu if you need those prerequisites. Git inside WSL is separate from Git for Windows. The commands below run in the WSL terminal from the repository folder; touch is a Linux command used in this demonstration.

I stay on main for this personal practice example. Follow your project's branch and review rules when working with other people.

Open the local repository

In the terminal, navigate to the folder you cloned in part one. Check where you are and open that folder in VS Code:

pwd
code .

Press Ctrl+Shift+E to open Explorer, then find README.md. In this recording the existing README contains the repository name as a level-one heading.

Edit and save the README

Move to the end with Ctrl+End and add a blank line, a level-two heading and a short paragraph. For example:

## Purpose

The purpose of this repository is to demonstrate GitHub in my YouTube videos.

The space after the two number signs is part of the heading syntax. Save with Ctrl+S. This creates a local file change; it does not update GitHub yet.

Review and stage the change

Press Ctrl+Shift+G to open Source Control. I have GitLens installed, but the basic Source Control view is built into VS Code. Find README.md under Changes and press Enter to open its comparison. I demonstrate the editor's change sounds and briefly open the Accessible Diff Viewer with F7.

Return to Source Control, focus the changed file, and open its context menu with the Applications key or Shift+F10. Choose Stage Changes. To stage every reviewed change, use Stage All Changes on the Changes group. Check the Staged Changes group before committing. These are the file changes selected for the next commit. VS Code source-control guide.

Compare a modified file with a new file

In the video I create an empty source folder, then an empty Python file inside it:

mkdir src
cd src
touch index.py

An empty directory does not appear as a tracked item in this example. The new file appears as untracked until I stage it. The existing README is modified; the new index.py is added. The word “index” in a staged status refers to Git's staging area, which is different from the filename index.py.

Review these changes and stage the new file. If you repeat the commands, inspect your existing folder first rather than assuming src is new.

Write a commit message and commit

Move to the Source Control message field. Describe the change, for example:

Add README purpose and initial Python file

In the recording I use GitHub Copilot to help draft the message, then read it before choosing Commit. You can type your own message. Committing records the staged changes in local Git history; pushing is a separate step.

Check the remote and push

In the integrated terminal, I check the branch, fetch information from GitHub, check again, and push:

git status
git fetch
git status
git push
git status

git fetch downloads remote information and updates remote-tracking references such as origin/main. It does not merge those changes into the checked-out branch. After fetching, git status can show whether the local branch is ahead, behind or diverged from its upstream. The video shows a branch one commit ahead and a successful push. Stop and resolve an unexpected behind or diverged state before treating it as the same case. Git fetch documentation.

VS Code's Sync Changes control combines pulling and pushing. I cancel that combined action in the video and use separate terminal commands so I can inspect the state between steps. VS Code remote operations.

Authenticate when prompted

Public visibility lets people read a repository; it does not grant everyone permission to push. In the recording, VS Code asks to use GitHub, and I select my existing coding-blind-tech account. Your first sign-in may include additional steps. This lesson does not demonstrate creating an account, setting up a token or configuring an SSH key.

HTTPS and SSH are authentication choices, not public-versus-private repository categories. Use the method configured for your remote. Do not enter your GitHub account password into an old-style Git password prompt; GitHub documents supported sign-in and credential-helper options. GitHub authentication guide.

Verify on GitHub with NVDA

After the push, git status reports that the branch is up to date with origin/main and the working tree is clean. I return to the repository in Brave and refresh with Ctrl+R. In NVDA browse mode, I navigate to the README heading, then read the new Purpose heading and paragraph.

Keyboard clarification: use NVDA+Space to switch to focus mode when sending GitHub's own shortcuts, such as G then D. Return to browse mode for NVDA's H heading, K link and D landmark navigation. The recording says “browse mode” before the GitHub shortcut; focus mode is the intended mode there. NVDA browse and focus modes.

The refreshed README is the visible confirmation that the local commit reached GitHub. Continue with the Getting Started with GitHub Using NVDA playlist.