The integrated terminal
Beginner VS Code UI
Why this matters
Every instruction you will ever be sent by a colleague, or find in an answer online, is a command. The integrated terminal means following it does not require leaving the editor, and it always opens in the project folder, which removes the most common source of "that did not work".
Opening it
| Way | Notes |
|---|---|
| ⌃` (Control and backtick) | Toggles the panel |
| Terminal → New Terminal | Same thing |
| Right-click a folder in the Explorer → Open in Integrated Terminal | Opens there, which is occasionally what you want |
It starts in the folder you have open, so git status works immediately with no cd.
The Git output channel
View → Output, then choose Git from the dropdown. This is the log of every Git command VS Code has run on your behalf:
> git add -- docs/getting-started.md
> git commit -m "docs: add Windows steps to installation guide (#12)"
> git push origin docs/12-windows-install-stepsThat channel is the best teaching tool in the editor. Click a button, read the line it produced, and the interface stops being a black box. It is also the first place to look when something behaves unexpectedly, because it shows exactly what was run and what Git said back.
What is faster in the terminal
Honestly, most of the everyday loop is fine either way. Five things are meaningfully faster or only possible in the terminal:
| Task | Command |
|---|---|
| Seeing what happened after something went wrong | git reflog |
| Staging part of a file, if you like the terminal | git add -p |
| Anything involving a hash | git branch rescue/x <hash> |
| Reading history with a filter | git log --oneline -- docs/ |
| Running the pipeline's own checks | Whatever .gitlab-ci.yml says |
The reflog is the important one: VS Code has no reflog view, and it is the command that recovers work (lesson 12.1).
Making it pleasant
- Split it: the split icon gives two side by side, useful for running a build in one and Git in the other.
- Name it: right-click the tab → Rename, so "docs build" and "git" stay separate.
- Choose the shell: the dropdown next to the plus offers your installed shells; on Windows, Git Bash is often the friendliest for Git instructions written for macOS or Linux.
codefrom the terminal: with the shell command installed,code <file>opens a file in the editor you are already in (lesson 15.1).
How to do it
The three commands worth running in it every day:
$ git status
$ git log --oneline -5
$ git diff --stagedNone changes anything, and between them they answer most questions the interface raises.
- ⌃` to toggle the terminal
- View → Output → Git for the command log
- Terminal: Rename and the split icon for organisation
- Terminal: Select Default Profile to choose the shell
View → Tool Windows → Terminal, or ⌥F12. IntelliJ's equivalent of the Git output channel is the Console tab in the Git tool window. See lesson 16.10.
Nothing platform-specific, though glab gives you merge requests and pipelines from the same terminal.
The same with gh.
Common mistakes
- Opening a separate terminal application and then being in the wrong folder.
- Ignoring the Git output channel, which answers "what did that button just do?" precisely.
- Insisting on one mode. The interface is better for staging and diffs; the terminal is better for history and recovery.
- Running a long process in the terminal and closing the panel, which kills it.
Try it yourself
Goal: connect the buttons to the commands.
- Open the integrated terminal and run
git status. - Open View → Output → Git and keep it visible.
- In the Source Control view, stage a file, commit it, and push.
- Read the three lines that appeared in the Git output channel.
- Now run the same three commands yourself in the terminal on a second change, and confirm the result is identical.
Expected result: the same commit made twice, once by clicking and once by typing, with the output channel showing they were the same commands.
Show solution
Step 4 is the exercise. Once you have watched the interface produce git add, git commit and git push, every instruction written in commands becomes usable, and every button becomes predictable. That is the whole argument for reading the output channel occasionally.