Edit, diff, stage, commit, push, pull, sync

Why this matters

This is the loop you will repeat several times a day. Done well in the editor it is four clicks and a sentence, and the two habits that matter, reading the diff and staging deliberately, are easier here than anywhere else.

The loop

1. Edit a file and save it. It appears under Changes with an M.
2. Read the diff: click the file name. Left is the previous version, right is yours.
3. Stage what belongs in this commit with +, on the file or on individual changes.
4. Check the staged diff: click the file under Staged Changes. This is what will be committed.
5. Write the message in the box and click Commit.
6. Sync when you are ready to share, or push separately.

Steps 2 and 4 are the ones people skip and the ones that catch mistakes. The staged diff in particular is the last honest look at what you are about to record.

Staging part of a file

This is where the interface genuinely beats the terminal. In the diff view, select the lines you want, then Stage Selected Ranges from the editor's context menu or the Command Palette. The change block gets a small + in the gutter too.

The result: one file, some of its changes staged, the rest still in Changes. The Source Control view shows the file in both sections at once, which is confusing for a moment and then obvious (lesson 5.3).

Use it when one file ended up holding two unrelated changes, which happens constantly.

Writing the message

The box takes multiple lines: type the subject, press Enter, leave a blank line, then the body. It is a real editor, so wrapping and spellcheck work.

For a longer message, use Git: Commit from the Command Palette with an empty box, which opens COMMIT_EDITMSG as a proper tab.

The rules are the same as anywhere (lesson 5.4): imperative subject under about fifty characters, the issue number, and the why in the body.

Sync, pull and push

Sync Changes is git pull followed by git push. Its label carries the counts, 1↓ 2↑, so you can see what it will do before clicking it.

Fetch is the safe one, and with git.autofetch on VS Code does it for you, which is why the counts stay accurate.

If a push is rejected, VS Code shows Git's message. It usually means the branch has moved on the server (lesson 7.6); pull, resolve anything that conflicts, and push again.

Amending and undoing

Undo Last Commit is git reset --soft HEAD~1: the commit disappears and its changes go back to staged (lesson 12.4). Both amend and undo rewrite history, so use them only before pushing.

How to do it

$ git status
$ git diff docs/getting-started.md
$ git add -p docs/getting-started.md
$ git diff --staged
$ git commit -m "docs: add Windows steps to installation guide (#12)"
$ git pull && git push

Common mistakes

• Committing without reading the staged diff.
• One commit for two unrelated changes, when staging ranges makes splitting them easy.
• Clicking Sync when you meant Fetch, which pulls as well.
• Amending after pushing, which needs a force push (lesson 12.8).
• Using the ↺ discard button as an undo for staging. That is −.
• A one-word commit message, which the box makes it easy to write.