Terminal and Git settings
Beginner IntelliJ UI
Why this matters
Every instruction you are sent will be a command, and the IDE has a terminal that opens in the right folder. Alongside it, the Console tab shows the commands the IDE runs for you, which is the fastest way to connect the two.
The terminal
View → Tool Windows → Terminal, or ⌥F12. It opens in the project root, so git status works immediately.
Useful habits:
- Several tabs: the plus icon, so a build and a Git session stay separate.
- Split: right-click the tab → Split Right, for a build in one half and commands in the other.
- Shell: Settings → Tools → Terminal → Shell path chooses it; on Windows, Git Bash is friendliest for instructions written for macOS or Linux.
The Console tab
The Git tool window's Console tab logs every Git command the IDE has run, and Git's reply:
21:04:11.221: [trailguide] git -c core.quotepath=false commit -m "docs: add Windows steps (#12)"
21:04:12.980: [trailguide] git -c core.quotepath=false push --progress origin docs/12-windows-install-steps:docs/12-windows-install-stepsTwo uses. It teaches: click something, read the command, and the interface stops being opaque. And it diagnoses: when an action does something unexpected, the exact command and Git's exact reply are both there (lesson 16.12).
The settings worth knowing
Settings → Version Control:
| Setting | Effect |
|---|---|
| Git → Enable staging area | Git's index instead of changelists (lesson 16.5) |
| Git → Update method | Whether Update Project merges or rebases |
| Git → Auto-update if push was rejected | Whether a rejected push is retried automatically; off is clearer while learning |
| Commit → Before Commit | Reformatting and other checks; leave the code-changing ones off |
| Commit → Use non-modal commit interface | Commit as a tool window rather than a dialog |
| Confirmation | Which destructive actions ask first; keep them on |
| Background | What runs without blocking the IDE |
| Version Control → Local History | How long the safety net keeps entries (lesson 16.8) |
Settings → Version Control → Git → Protected branches is worth a mention: it lists branch names IntelliJ will refuse to force-push, main and master by default. It is a local guard rail, not a substitute for the platform's protection (lesson 9.5), and there is no reason to remove entries from it.
What IntelliJ does not do
Even with its wide coverage, some things belong in the terminal:
| Task | Why |
|---|---|
git reflog |
No view for it, and it is the recovery command (lesson 12.1) |
git bisect |
No interface |
| Anything unusual with hashes and refs | Faster to type |
| Running the pipeline's own checks | They are commands (lesson 14.4) |
Interactive rebase is the exception in IntelliJ's favour: Git → Interactively Rebase from Here… on a commit in the Log gives a genuinely good dialog for squashing and reordering, which is easier than the terminal's editor for most people.
How to do it
$ git status
$ git log --oneline -5
$ git reflogThe first two answer most questions; the third is the one with no IDE equivalent.
The integrated terminal and View → Output → Git are the same pair. See lesson 15.9.
- View → Tool Windows → Terminal, ⌥F12
- The Git tool window's Console tab
- Settings → Version Control for everything in the table
- Git → Interactively Rebase from Here… on a Log commit
Nothing platform-specific, though glab works in the terminal like any other tool.
The same with gh.
Common mistakes
- Using a separate terminal application and then being in the wrong folder.
- Not knowing the Console tab exists.
- Turning on auto-update after a rejected push while still learning, which hides what happened.
- Removing entries from the protected-branches list.
- Assuming the IDE covers everything. The reflog does not appear anywhere in it.
Try it yourself
Goal: connect the actions to the commands.
- Open the Console tab and keep it visible.
- Stage, commit and push a change using the Commit window.
- Read the three commands logged, including their options.
- Open the terminal (⌥F12) and run
git log --oneline -1to confirm the result. - Look through Settings → Version Control and note which of the settings in the table are currently on.
Expected result: three logged commands you can now read, and a written note of how your IDE is configured.
Show solution
Step 3 rewards attention: IntelliJ passes options you would not type by hand, such as -c core.quotepath=false, which is why the logged command sometimes looks longer than expected. The verbs are still the ones you know, and that is what makes the log readable.