Commits & History

What a commit actually saves

Saving in VS Code writes a file to disk. A commit records a version of your tracked project in Git history. Those are separate actions: saving does not commit, and committing does not publish to GitHub. Git works locally without an internet connection.

A commit has a snapshot, author, message and an identifier called a hash. It also links to its parent commit (or parents when merging), forming a history. Unchanged tracked files remain in the snapshot; new files and edits only enter it when staged. Empty folders and ignored, untracked files are not saved by Git.

The three places — with a real example

1. Working directory — the files on disk that you edit and save.
2. Staging area — the version of each file selected for the next commit.
3. Local repository — the commits stored inside the project's .git folder.

Imagine you change index.html and style.css. You stage only index.html. The next commit records that HTML change, but not the CSS edit. If you edit the HTML again after staging, the staging area still holds the earlier version until you stage it again. This is why review matters.

Prepare safely before your first commit

Open your studio project in VS Code and use Terminal → New Terminal. Run pwd to check the folder. Run git status: if it says “not a git repository”, run git init once in this project, then repeat the status check. If it already shows a branch, do not initialise again. Avoid creating repositories inside repositories.

Git needs an author identity, not a GitHub password:

git config --global user.name "Your Name"
git config --global user.email "Your chosen commit email"

Replace both quoted values. The email appears in commit history; choose GitHub's private noreply commit address from its email settings if you do not want to publish a personal address. The global setting applies to other repositories on this computer too.

Create .gitignore in the editor before staging:

.env
.env.*
node_modules/
dist/
build/

These rules ignore untracked secrets and generated files. They do not untrack an already committed file. Never include passwords or secret keys in any tracked file. Inspect what Git proposes to save, even when an agent made the edits.

Make and inspect one focused commit

Use a small, saved change to index.html, such as improving a heading. Run each command separately in the project terminal; these Git commands work on Windows and Mac:

git status
git diff
git add index.html
git diff --staged
git commit -m "Clarify the studio page heading"
git status
git log --oneline

git status lists new, modified and staged files. git diff shows unstaged changes to tracked files; a new untracked file will not appear there. git diff --staged shows exactly what the next commit will change, including newly staged files. In a diff, - marks removed lines and + marks added lines; these markers are not source code.

Check that the staged diff contains only the intended change and no secrets. git add index.html selects a specific file; git add . selects all changes under the current folder, including deletions. Use the latter only after reviewing the whole selection. For the website practical, stage the intended HTML, stylesheet and any required assets, not just the example file.

After the commit, “working tree clean” means there are no outstanding tracked changes or visible untracked files. It does not mean the website passes tests or was uploaded. If other files still show as modified, that can be intentional: they were not part of this commit. Open the page and test the change yourself.

Read history rather than just listing it

Example output (your hashes will differ):

8a12bc3 (HEAD -> main) Clarify the studio page heading
4d56ef7 Add the initial studio page

The newest entry is first. The short hash identifies a commit; the text is its message. HEAD identifies your current checkout, and main is the branch name. A branch is a movable pointer to a line of commits, not a second project folder. Creating another commit advances the current branch.

Use git show --stat HEAD to see the latest commit's summary, and git show HEAD -- index.html to inspect its actual HTML changes. For a previous entry, replace HEAD with a hash copied from your own log. git log --oneline -- index.html limits history to commits affecting that file. If a long command opens a pager, press q to leave it; you have not broken the terminal.

Commit messages and useful checkpoints

Make one coherent change per commit. “Clarify booking button label” is useful; “stuff” or “fix everything” is not. Mention the reason when it helps. Commit a tested checkpoint before trying a risky layout change or accepting a large agent edit, then review and test the next change before committing it. A commit preserves code; it cannot certify that the code works.

Guided rehearsal: three checkpoints you can explain

Use your studio website, not an unrelated parent folder. Keep the browser open alongside VS Code. You are going to preserve three distinct stages, not commit the same unchanged files three times.

Checkpoint 1 — the baseline. Save the current website. Open it in the browser and check the heading, stylesheet and links. Run git status. On a new repository it may say “No commits yet” and list untracked files. Stage your real project files individually, for example git add index.html style.css if those are their names. Include required images too, using their actual paths. Review git diff --staged; commit with a message such as git commit -m "Add studio website baseline". Your commit must contain the files needed to display the page, not only one edited heading.

Checkpoint 2 — a content change. Change one heading in the editor, save and refresh the browser. Run git diff -- index.html and find the old and new heading. Stage that file, inspect git diff --staged and make a commit explaining the change. Check git log --oneline: the content change should be above the baseline.

Checkpoint 3 — a visual change. Adjust one CSS spacing value, save and refresh. Check both a narrow and a wide window. Stage only the stylesheet, review its staged diff and commit. History should now tell a readable story: baseline → content improvement → visual improvement. Your hashes and messages will differ from anyone else's.

Before continuing, answer without guessing: which commit contains the spacing change? What did the content commit change? Could a saved but unstaged edit enter the next commit? Run git show HEAD -- style.css to check your answer against evidence.

See staging freeze a version

After those checkpoints, edit and save a heading, then run git add index.html. Change that same heading again and save, but do not stage again yet. Run git diff --staged -- index.html and git diff -- index.html. The first shows the selected version compared with the last commit; the second shows what changed since staging. git status can show the same file in both sections. Decide which version you actually want, stage it again if necessary, review, test and commit. This is why “I saved it” is not sufficient evidence for a checkpoint.

GitHub is a separate copy

A remote is a named repository address. origin is the conventional name for your GitHub copy, not a magic word. Push sends committed history there; it does not send your unstaged edits. Fetch retrieves remote history without changing your working files. Pull fetches and integrates remote changes into your current branch.

Create the destination on GitHub

1. Sign in to GitHub in your browser. Git and GitHub are different: setting your Git author name did not sign you in or create a GitHub account.
2. Choose New repository from GitHub's create menu. Check the Owner is your account or the intended organisation. Give the repository a name such as studio-hq.
3. Choose visibility deliberately. Public means others can inspect the files and commit history; private limits access. Neither choice makes it safe to commit passwords. The academy is free; external services have their own plans and limits.
4. Leave the README, licence and .gitignore initialisation options off for this walkthrough: you already have a local history. Creating those files on GitHub first creates a separate history which your first push may not be able to integrate automatically.
5. Create the repository. In Quick setup, select HTTPS and copy the repository address. It should identify the correct owner and repository and end in .git. Do not copy the address of an individual file or the website you deployed.

Return to the terminal inside your existing project. Run git status and git log --oneline first: you need at least one local commit to push. Replace the placeholder below (do not type the angle brackets):

git branch -M main
git remote add origin <your-repository-HTTPS-URL>
git remote -v
git push -u origin main

Check the owner and repository in git remote -v before pushing. -u sets the upstream, linking local main to origin/main so later updates can use git push. Complete the supported browser sign-in when prompted; do not enter your GitHub account password as a terminal password. Open the repository on GitHub and confirm the files and latest commit message appear. Public repositories are visible to everyone; private ones still must not contain secrets.

What those four commands changed

git branch -M main names your current local branch main; it does not upload anything. git remote add origin … stores the destination; it does not copy files yet. git remote -v prints the configured fetch and push addresses so you can catch a wrong owner. git push -u origin main finally uploads main's commits and sets its upstream. Do this setup once, not before every checkpoint. If already connected, inspect the destination rather than adding origin again.

Sign-in without leaking credentials

A Git credential helper may open a browser window when you push. Check it is GitHub, sign in to the intended account, and finish the authorisation before returning to the terminal. Some computers instead show a username/password prompt. GitHub does not accept an account password for HTTPS Git operations; use a supported credential helper or GitHub's current HTTPS authentication instructions. A personal access token, if you choose that route, is a secret with repository permissions, not something to paste into a repository URL, source file, screenshot or assessment. Signing in to github.com in a browser does not always configure terminal authentication.

If authorisation fails, check the signed-in account can write to that repository. Organisation repositories may also require approval or single sign-on. Do not make a private repository public simply to get around a sign-in problem. GitHub's HTTPS authentication guidance explains the supported methods.

Verify the upload rather than trusting the command

After a successful push, open the repository's Code tab and select main. Check all of the following:

• The expected HTML, CSS and required assets appear. Open a file and confirm its contents match the version you committed.
• The latest commit message matches git log -1 --oneline locally. Compare the short hash too; GitHub may show a different number of hash characters, but their shared prefix must agree.
• Open the commit history from the latest commit/history link. Open a commit to inspect the changed files and highlighted additions and removals, rather than treating a file list as proof of history.
• Run git status locally. “Up to date with origin/main” compares with Git's last known remote state, not a continuous live check; ignored files and unsaved editor changes are not included.

If a change is missing online, follow the chain: did you save the file, stage the intended version, commit it and push the correct branch to the correct repository? A successful push can say “Everything up-to-date” while your working directory still has uncommitted edits.

GitHub's Code tab shows source, not a running website. Repository hosting and website deployment are different outcomes. The next lesson publishes the website; do not submit a repository address as if it were the deployed page.

Your next update: use the short loop

Make one more useful change, then save, test and review it. You already have a repository and origin: do not run git init or remote add again. With the correct file names, the loop is:

git status
git diff
git add index.html
git diff --staged
git commit -m "Clarify the studio introduction"
git push
git log -1 --oneline

Refresh GitHub and find that same commit. Before pushing, git status may report that main is ahead of origin/main by one commit: you have a local checkpoint not yet uploaded. After pushing, check again. If you disconnect from the internet you can still edit and commit; you cannot upload until connectivity returns.

Safely undo a committed mistake

Practise in a disposable copy or practice repository, not somebody else's shared work. Start with a clean git status and a tested commit. Make one deliberately bad heading change, save it and commit it. Use git log --oneline and git show HEAD -- index.html to confirm that the newest commit contains only that mistake.

Run git revert --no-edit HEAD. This creates a new commit reversing the latest commit, while keeping the original history. Refresh the browser: the heading should be back. Run git log --oneline again: there should be a new revert entry above the mistaken commit. If the mistake was already uploaded, git push shares this repair without rewriting anyone's history. Only revert HEAD when you have confirmed HEAD is the commit you intend to reverse; a revert can reverse more than the one line you noticed.

To unstage a file without deleting its edits, use git restore --staged index.html after your first commit exists, then check status and open the file. In contrast, git restore index.html discards unstaged edits to that tracked file; it is not a general-purpose “undo” button. Do not practise discard commands on work you need. If a revert reports conflicts, stop and ask for help reading the conflict before continuing. Avoid reset --hard and force-push as beginner fixes.

When the workflow stops

Practise before assessment

Create two small, meaningful commits in your studio or a disposable practice repository. Before each, explain which edits are staged and inspect their diff. Afterward, identify the newest hash and message, inspect that commit, and explain why an uncommitted edit cannot appear on GitHub. If already connected, push and compare the latest commit on both sides.

Assessment readiness checklist

• I can explain saving, staging, committing and pushing as four separate actions.
• I can inspect both diffs, select only intended files and recognise whether a secret would enter history.
• I can locate a checkpoint by its message/hash and show what it changed.
• I have connected the intended repository, uploaded the website and compared the latest local and GitHub commit.
• I can make a second update without repeating repository setup, and explain a safe revert versus discarding uncommitted edits.

For Quest 1.3, run git log --oneline and git remote -v in your real studio repository, then submit their actual output. Do not copy the lesson's example hashes or a token-bearing address. Keep your GitHub check separate: those two outputs identify local history and the configured destination, but alone cannot prove a successful upload. The three-checkpoint and revert rehearsals above build confidence; they do not add new pass rules or XP requirements.

This rehearsal is for understanding, not an extra unlock requirement. Quest 1.3 asks you to commit your website, push it and submit git log --oneline plus git remote -v. That terminal evidence shows history and the destination; checking the actual GitHub page yourself confirms the upload. The next branch lessons cover experiments and recovery in more depth.