My progress
Menu

Level 1 · Digital Foundations · Course 1.3 Version Control

Module 9: Introduction to Git

Goal: use Git to save the history of your work, so you can see what changed and go back when something breaks. This is your most important safety net when working with AI.

You'll need: VS Code and the my-first-site folder from Module 8.

Lessons

  1. 1Why version control exists15–25 minutes✓
  2. 2Repositories15–25 minutes✓
  3. 3Commits15–25 minutes✓
  4. 4Staging and history15–25 minutes✓
  5. 5Restoring changes15–25 minutes✓

🛠️Module practice: your first history

In my-first-site:

  1. Make three separate, small changes to index.html, committing each with a clear message.
  2. Show the history with git log --oneline.
  3. Make a fourth change, but throw it away with git restore.
  4. Revert your second commit with git revert and look at the history again.

✅Module check

Explain in a few sentences, in your own words:

How does Git protect your work when an AI is making changes to your project?

Show a good answer

A good answer mentions: Git records each commit as a snapshot with a message, so you can see exactly what changed (git status, git diff) and go back. If you commit before asking the AI for a change, a bad result can be thrown away with git restore, and a bad commit can be undone safely with git revert. Small commits make each change easy to check and undo.

📝Module quiz

10 questions · 10 marks each · 100 marks in all · pass mark 70% · retry as often as you like ·

1. Are Git and GitHub the same thing?

Why each option is right or wrong

  • “Yes, but only on Windows; on a Mac they're separate tools” (Incorrect): Git and GitHub are different things on every operating system.
  • “No, GitHub is a programming language used to write Git” (Incorrect): GitHub is a website and service, not a language.
  • “Yes, they're two names for one program made by one company” (Incorrect): Git is free open-source software; GitHub is a separate company's website built around it.
  • “No: Git records history on your computer; GitHub stores Git projects online” is correct.

    Git is a program that tracks every change to your project, on your own machine, even offline. GitHub is a website that hosts Git repositories so you can back them up, share them and collaborate.

    • Git without GitHub: works fine, just only on your computer.
    • Alternatives: GitLab and Bitbucket also host Git repositories.

📖 Revise: Lesson 1: Why version control exists

Question ID module-09-q1 · Report a mistake in this question
2. Why is Git especially important when AI writes code for you?

Why each option is right or wrong

  • “Git makes the AI smarter by showing it your history” (Incorrect): Git records changes; it doesn't improve the AI's answers.
  • “Git writes the code for you, so the AI only plans it” (Incorrect): Git doesn't write code. It only records what you or the AI wrote.
  • “AI tools refuse to work in folders that aren't Git repositories” (Incorrect): Most AI tools work in any folder. Git is for your protection.
  • “AI makes many quick changes; Git shows exactly what changed and lets you undo” is correct.

    An AI assistant can edit dozens of files in seconds. Without a record, you can't see what it touched or get back to a working version. Git gives you both.

    • Commit before each AI task: a safe point to return to.
    • Review with git diff: see every line the AI changed.
    • Undo cleanly: git restore . puts edited files back to your last commit if the AI's changes are wrong (check git status for new or staged files too).

📖 Revise: Lesson 1: Why version control exists

Question ID module-09-q2 · Report a mistake in this question
3. What's inside the hidden .git folder?

Why each option is right or wrong

  • “A list of the website's visitors and their visits” (Incorrect): Git knows nothing about website visitors.
  • “Your saved passwords for GitHub and other sites” (Incorrect): Git doesn't store your passwords there. Don't commit them either.
  • “Nothing important; it can be safely deleted to save space” (Incorrect): It's the most important folder in the project: it holds all of history.
  • “The repository's entire history” is correct.

    The .git folder holds every commit, branch and setting for the project. Your working files are just the current version; the history lives in .git.

    • Delete it and: your files stay, but all history, branches and undo points are gone.
    • Hidden for a reason: don't edit it by hand.

📖 Revise: Lesson 2: Repositories

Question ID module-09-q3 · Report a mistake in this question
4. Why add .env to .gitignore?

Why each option is right or wrong

  • “Because Git can't track files whose names start with a dot” (Incorrect): Git tracks dot-files fine, like .gitignore itself. Ignoring .env is a choice, to protect secrets.
  • “To make the project load faster when it is cloned” (Incorrect): One small file makes no difference to speed. Protecting secrets is the point.
  • “To delete the .env file from your own computer” (Incorrect): Ignoring a file doesn't delete it. It just keeps it out of Git.
  • “So secret values are not recorded or uploaded” is correct.

    .gitignore lists files Git should ignore, as long as they were not already committed. Putting .env there means your API keys and passwords aren't committed, so they can't leak through GitHub or any copy of the repository.

    • Do it before the first commit: once a secret is committed, it stays in history.
    • Share safely: commit a .env.example with placeholder values instead.

📖 Revise: Lesson 2: Repositories

Question ID module-09-q4 · Report a mistake in this question
5. Which is the better commit message?

Why each option is right or wrong

  • “"asdf", since the code shows what changed anyway” (Incorrect): Keyboard mash tells nobody anything. History becomes useless for finding changes.
  • “"changes", which covers everything in the commit” (Incorrect): Every commit contains changes; the word adds no information.
  • “"stuff I did today before lunch on the website"” (Incorrect): Long but vague. It doesn't say what actually changed.
  • “"Fix the broken link on the home page"” is correct.

    A good commit message says what changed, so that months later you or a teammate can scan the history and find the right change quickly.

    • Short and specific: start with a verb, like Fix, Add or Update.
    • When needed: add a second line with why.

📖 Revise: Lesson 3: Commits

Question ID module-09-q5 · Report a mistake in this question
6. You changed three files but want to commit only one. How?

Why each option is right or wrong

  • “Push first, then add the file you want to commit” (Incorrect): Pushing sends existing commits. It doesn't choose files for a new one.
  • “Commit all three together and fix it up later on” (Incorrect): Mixing unrelated changes makes history hard to read and undo.
  • “Delete the other two files so only one is left” (Incorrect): That throws away your work. Staging lets you keep it.
  • “git add only that file, then commit” is correct.

    Git has a staging area: you choose which changes go into the next commit with git add. Only staged changes are committed; the others stay as uncommitted edits.

    • Check first: git status shows what's staged and what isn't.
    • Benefit: each commit stays focused on one change, easy to understand and undo.

📖 Revise: Lesson 4: Staging and history

Question ID module-09-q6 · Report a mistake in this question
7. An AI edited ten files and broke your site. You committed just before, and git status shows only those ten files as modified, nothing staged and no new files. What's the quickest way back?

Why each option is right or wrong

  • “Reinstall the operating system to clear out the changes” (Incorrect): Reinstalling doesn't touch your project's history and wastes hours.
  • “Delete the hidden .git folder, so Git forgets the AI's edits and every file returns to how it was” (Incorrect): That deletes your history, the very thing that lets you go back, and the edited files stay broken.
  • “Retype every file from memory as it was this morning” (Incorrect): Slow and error-prone when Git can restore exactly in one command.
  • “git restore . from the project's top folder, putting those files back as at your last commit” is correct.

    Plain git restore copies the staged version of each tracked file back over your working copy. Because nothing is staged, that staged version is still your last commit, so all ten files go back to how they were. It only covers the folder you name (. is the current folder), so run it from the top of the project.

    • Look first: git status and git diff show exactly what will be thrown away.
    • Staged or new files? git restore . leaves staged edits and brand-new files alone; git restore --staged --worktree . resets staged ones, and new files need deleting separately.
    • Unsure? git stash -u sets every change aside, new files included, so you can bring it back with git stash pop.

📖 Revise: Lesson 5: Restoring changes

Question ID module-09-q7 · Report a mistake in this question
8. Why is git revert safer than rewriting history?

Why each option is right or wrong

  • “It deletes the bad commit forever so nobody can see it” (Incorrect): Revert keeps the bad commit and adds an undo on top.
  • “It's faster to type than any other undo command in Git” (Incorrect): Typing speed isn't why it's safer.
  • “It skips the history so the project starts fresh again” (Incorrect): Revert adds to history; it doesn't skip it.
  • “It undoes a commit by adding a new one, so nothing is deleted” is correct.

    git revert creates a new commit that reverses an earlier one. History stays intact, so anyone else with a copy of the project stays in step, and you can see what was undone and when.

    • Rewriting history (reset, rebase, force push) changes commits others may already have.
    • Use revert on shared branches like main.

📖 Revise: Lesson 5: Restoring changes

Question ID module-09-q8 · Report a mistake in this question
9. What does plain git diff show?

Why each option is right or wrong

  • “Who last changed each line of every file in the project, and in which commit and when” (Incorrect): That's git blame.
  • “A list of all the branches and which one is active” (Incorrect): That's git branch.
  • “The repository's total size on disk and on GitHub” (Incorrect): Git diff shows changes, not size.
  • “The lines you've changed but not staged yet, compared with the staging area” is correct.

    git diff compares your working files with the staging area. Before you stage anything that's the same as "changes since the last commit", but once you git add part of your work, those staged lines drop out of git diff. It's how you review changes before staging and committing them.

    • Staged changes: git diff --staged compares the staging area with the last commit.
    • Everything since the last commit: git diff HEAD.
    • Red and green: removed lines start with -, added lines with +.

📖 Revise: Lesson 4: Staging and history

Question ID module-09-q9 · Report a mistake in this question
10. Why commit small and often instead of once at the end of the day?

Why each option is right or wrong

  • “Git charges a fee for each commit over a daily limit” (Incorrect): Git is free and has no commit limits.
  • “Large commits are rejected by Git when you try to save them” (Incorrect): Git accepts large commits; they're just harder to review and undo.
  • “Small commits use less disk space than one large commit” (Incorrect): Disk use is about the same. The benefit is clarity and safety.
  • “Each small commit is easy to understand and undo on its own” is correct.

    A small commit does one thing. If it causes a problem, you can find it, understand it and revert it without losing the rest of the day's work.

    • Clear history: each message describes one change.
    • Safe points: more places to return to when something breaks.

📖 Revise: Lesson 3: Commits

Question ID module-09-q10 · Report a mistake in this question

ProLearners Assist