Under the hood: the command behind every button
Intermediate VS Code UI
Why this matters
Instructions come in commands. Interfaces come in buttons. This page is the translation table, and it is the page to keep open while you are learning either one.
The map
| VS Code | Command |
|---|---|
| + on a file | git add <file> |
| + on the Changes header | git add -A |
| − on a staged file | git restore --staged <file> |
| ↺ discard | git restore <file> |
| Stage Selected Ranges | git add -p, roughly |
| Message box plus Commit | git commit -m "…" |
| Commit Staged (Amend) | git commit --amend |
| Undo Last Commit | git reset --soft HEAD~1 |
| Sync Changes | git pull then git push |
| Git: Pull / Push / Fetch | The same commands |
| Publish Branch | git push -u origin <branch> |
| Status Bar branch → Create new branch… | git switch -c <name> |
| Status Bar branch → a branch name | git switch <name> |
| Git: Delete Branch… | git branch -d <name> |
| Git: Merge Branch… | git merge <name> |
| Git: Rebase Branch… | git rebase <name> |
| Git: Abort Merge | git merge --abort |
| … → Stash | git stash push |
| … → Pop Latest Stash | git stash pop |
| Git: Clone | git clone <url> |
| Initialize Repository | git init |
| Clicking a file in Source Control | git diff <file> |
| Source Control Graph | git log --graph --oneline |
| Timeline on a file | git log -- <file>, plus VS Code's own local history |
| Complete Merge | git add <file> on the resolved file |
Watching it happen
View → Output → Git prints every command as VS Code runs it:
> git add -- docs/getting-started.md
> git commit -m "docs: add Windows steps to installation guide (#12)"
> git push origin docs/12-windows-install-stepsTen minutes with that panel open teaches more about Git than any amount of reading, because every click is annotated with its meaning (lesson 15.9).
Where the mapping is not one to one
Four places the interface does something a single command does not:
- Sync Changes is two commands, and which two depends on your
pull.rebasesetting (lesson 7.5). - Stage Selected Ranges builds a patch and applies it to the index, which
git add -pdoes interactively. - Stash & Checkout, offered when switching branches, is
git stash pushthengit switch. - The Timeline mixes Git history with VS Code's own record of file saves, which has no Git equivalent at all and is occasionally the only way to recover uncommitted work (lesson 12.1).
What the interface does not do
Worth knowing so you reach for the terminal without frustration:
| Task | Why not |
|---|---|
git reflog |
No view for it, and it is the recovery command |
| Anything by hash | git branch <name> <hash>, git cherry-pick <hash> |
git bisect |
No interface |
| Interactive rebase | Extensions add partial support; the terminal is clearer |
git filter-repo |
Nor should it |
How to do it
The reverse direction: given a command, where is it in the editor? The table above reads both ways, and the Command Palette is searchable, so typing "Git: " and the verb usually finds it.
- View → Output → Git to watch
- Command Palette → Git: to find a command by name
- Preferences: Open Keyboard Shortcuts to bind the ones you use most
IntelliJ's Git → Console tab is the same log. The mapping there is in lesson 16.11, and the two IDEs are compared side by side in Section 17.
Nothing here touches the platform: this is all local Git.
The same.
Common mistakes
- Assuming a button does exactly one command. Sync is two.
- Looking for the reflog in the interface.
- Force-pushing from the interface without checking the setting. VS Code needs
git.allowForcePushenabled and uses the lease-checked form by default (lesson 12.8). - Not knowing the palette names, which survive interface changes better than button positions.
Try it yourself
Goal: translate in both directions, once each.
- Open View → Output → Git and keep it visible.
- Perform five operations by clicking: stage, unstage, commit, create a branch, stash.
- Write down the command each produced, without looking at the table.
- Check your list against the table above.
- Now do the reverse: run
git switch -c test/mappingin the terminal and watch the Status Bar update.
Expected result: five correct translations from memory, and the observation that the editor reflects the terminal's changes immediately, because both are reading the same repository.
Show solution
Step 5 is the reassurance that matters. The editor is not a separate system that must be kept in sync: it is a view of the repository, so a command typed in the terminal appears in the interface at once. That is why mixing the two freely is safe.