Edit, diff, stage, commit, push, update, fetch
Beginner IntelliJ UI
Why this matters
This is the loop you repeat all day. IntelliJ has two versions of it, and the difference is the biggest single thing to understand about Git in this IDE.
Changelists or the staging area
Settings → Version Control → Git → Enable staging area decides which you get.
| Staging area off (default) | Staging area on | |
|---|---|---|
| You choose what to commit with | Checkboxes in the Commit window | Staged files, exactly like git add |
| Grouping | Changelists: named groups of pending changes | Git's index |
| Exists in Git? | No. Changelists are IntelliJ's own idea | Yes |
| Suits | People who never use the terminal | Anyone who also uses Git commands |
Changelists are genuinely useful: you can keep "the fix" and "the debugging noise" in separate lists and commit only the first. They are also invisible to Git, to your colleagues, and to git status, which is why a colleague looking at your terminal will not see them.
The recommendation for readers of this course: turn the staging area on. Everything you have learned then applies directly, and the Commit window becomes a view of the same staging area the commands use.
The loop
- Edit a file. Change markers appear in the editor gutter, and the file appears in the Commit window.
- Read the diff: click the file in the Commit window, or click a gutter marker for that block alone.
- Stage what belongs in this commit: ⌘⌥A on a file, or the gutter marker's stage button for one block.
- Write the message, with the clock icon for earlier messages.
- Commit (⌘K), or Commit and Push… (⌥⌘K).
- Push (⇧⌘K) when you are ready to share.
Step 3's per-block staging is IntelliJ at its best: the gutter marker beside a changed block offers to stage just that block, which is git add -p without the interactive prompt.
The message box
The box takes a subject and a body, and the clock icon lists earlier messages, which is useful for conventional prefixes (lesson 13.8).
Amend as a checkbox rewrites the last commit rather than making a new one, which is right before pushing and wrong after (lesson 12.2).
The gear icon holds Before Commit options: reformatting, optimizing imports, running tests. Leave the code-changing ones off unless the team agreed (lesson 16.1).
Push, and the push dialog
Git → Push (⇧⌘K) opens a dialog listing the commits about to go, which is a useful last look. It offers:
| Control | Does |
|---|---|
| Push | git push |
| Force push (in the dropdown) | git push --force-with-lease where the IDE can, which it prefers |
| Define remote | Adds a remote if the branch has none |
| The commit list | What you are about to publish |
Reading that list takes five seconds and catches the commit you forgot was still there.
Update Project
Git → Update Project (⌘T) is IntelliJ's pull, and it asks how:
| Option | Equivalent |
|---|---|
| Merge incoming changes into the current branch | git pull |
| Rebase the current branch on top of incoming changes | git pull --rebase |
Choose the one your team uses (lesson 7.5); the dialog can remember it. Fetch alone is the refresh icon in the VCS widget, and it changes nothing in your files, which makes it the safe way to see what has arrived.
How to do it
$ git status
$ git diff docs/getting-started.md
$ git add docs/getting-started.md
$ git commit -m "docs: add Windows steps to installation guide (#12)"
$ git pushWith the staging area enabled in IntelliJ, these and the IDE are the same operations on the same index.
The Source Control view combines what IntelliJ splits, and always uses Git's staging area. See lesson 15.6.
- Commit ⌘0, Commit ⌘K, Commit and Push… ⌥⌘K
- Add to VCS ⌘⌥A on unversioned files; the gutter marker to stage one block
- Git → Push ⇧⌘K; Git → Update Project ⌘T; Fetch in the VCS widget
- Find Action (⇧⌘A) → "Commit", "Push", "Update Project"
The push arrives and the pipeline starts; the merge request updates itself. Nothing in the loop changes because of the platform (lesson 9.7).
The same, with checks instead of a pipeline.
Common mistakes
- Not knowing whether the staging area is on, so the Commit window's behaviour is a mystery.
- Treating changelists as something Git knows about. It does not.
- Amending after pushing (lesson 12.8).
- Committing without reading the diff, which the Commit window makes easy to skip.
- Using Update Project without knowing whether it merges or rebases.
- Leaving Before Commit reformatting on.
Try it yourself
Goal: run the loop both ways and pick one.
- With the staging area off, make two changes and commit one using the checkboxes. Note that
git statusin the terminal shows both files as modified, and no changelists. - Turn the staging area on in Settings → Version Control → Git.
- Repeat: stage one block from a gutter marker, and check
git statusagain. This time the terminal agrees with the IDE. - Commit, then use Git → Push and read the commit list in the dialog before pushing.
- Run Update Project and note which option it used.
Expected result: the same work done twice, with the second run visible to Git commands, which is the argument for enabling the staging area.
Show solution
Step 1 and step 3 are the comparison. With changelists, the IDE knows something the terminal cannot see; with the staging area, both tools describe the same state. If you ever pair with a colleague or follow instructions written in commands, the second is much less confusing.