Computer Science - ICT Grade 9 Version Control Git and GitHub Basics

Study Guide: Version Control – Git and GitHub Basics (Grade 9, Computer Science/ICT)

1. The Driving Question

"You’re working on a group project—maybe a game, a website, or a research paper—and your teammate accidentally deletes a file you just spent hours perfecting. How do you get it back without starting over? And how do you make sure everyone’s changes don’t overwrite each other like a bad game of telephone? Why can’t you just email files back and forth like in middle school?"

By the end of this guide, you’ll know how developers actually collaborate—without panic, lost work, or endless "final_final_v2" file names.

2. The Core Idea – Built, Not Listed

Imagine you’re writing a choose-your-own-adventure story with three friends. Every time someone adds a new path or fixes a typo, they scribble their changes on a fresh sheet of paper and staple it to the stack. The stack grows, but you can always flip back to see who changed what—and if someone’s "dragon battle" ending accidentally breaks the plot, you can peel off their sheet and restore the last good version.

Git is that stack of paper, but for code (or any digital file). It tracks every change, lets you "flip back" to old versions, and merges everyone’s work without chaos. GitHub is like a shared notebook where your team stores the stack online, so no one loses their copy. Instead of emailing files, you "commit" (staple) your changes to the stack, "push" (upload) them to the notebook, and "pull" (download) your teammates’ updates. The magic? Git remembers the order of changes and can combine them intelligently—even if two people edit the same line.

Key Vocabulary:
- Repository (Repo): The "stack of paper" for your project. A folder where Git tracks all changes to your files.
Example: A repo for your school’s robotics club code, stored on GitHub so the whole team can access it.
College note: In professional workflows, repos can be monorepos (one giant repo for an entire company) or microrepos (one per service), each with trade-offs in complexity.

• Commit: A "stapled sheet" in your stack. A snapshot of your files at a specific time, with a message explaining what changed.
  Example: A commit titled "Fixed login button color" that changes a CSS file from background: red to background: blue.
  College note: Commits become atomic (small, focused changes) in industry—each should do one thing to make debugging easier.

• Branch: A parallel "stack" where you can experiment without messing up the main project. Like writing a new ending to your story on a separate sheet before deciding if it’s better.
  Example: A dark-mode branch where you test a new UI theme while the main branch stays stable for users.
  College note: Branching strategies (e.g., Git Flow, Trunk-Based Development) dictate how teams organize work in large projects.

• Pull Request (PR): A request to merge your branch into the main stack. Like saying, "Hey team, I wrote a new dragon battle ending—should we add it?" Example: A PR titled "Add user profile page" with screenshots and a checklist of tasks before merging.
  College note: PRs become code reviews in industry, where peers scrutinize changes for bugs, style, and performance.

3. Assessment Translation

How this appears in class:
- Formative: Exit tickets with questions like: "You made a commit but forgot to add a file. What command do you use to fix it?" (Answer: git add <file> + git commit --amend) - Proficient: Names the correct commands and explains why --amend is safer than a new commit.
- Developing: Lists commands but doesn’t explain the difference between --amend and a new commit.

• Project-based: A group assignment to build a simple website (e.g., a club homepage) using GitHub. Graded on:
• Commit messages (clear, descriptive, not "fixed stuff").
• Branching (e.g., one branch per feature).
• Resolving merge conflicts (e.g., two people edit the same HTML file).
• Proficient: Commits are small and focused, branches are named logically (e.g., add-contact-form), and conflicts are resolved with explanations in the PR.

State standardized tests (if applicable):
- Rarely test Git directly, but may include questions about collaboration tools or debugging where Git knowledge helps. Example: "Which tool helps a team track changes to code over time?" (Answer: Version control system like Git.) - Distractor patterns: Answers like "a shared Google Drive" or "email" (which don’t track changes or allow branching).

SAT/ACT framing:
- Unlikely to appear, but logical reasoning questions about workflows (e.g., "Which step comes first: committing or pushing?") could test understanding.

Model proficient response (to a project rubric):

"Our team used three branches: main for the stable site, navbar for the navigation bar, and about-page for the club description. I worked on the about-page branch and made 5 commits, each with a message like ‘Added club history section’ or ‘Fixed typo in mission statement.’ When I finished, I opened a pull request to merge into main. Our teammate noticed a merge conflict in the HTML file because we both edited the <head> section. We resolved it by keeping the navbar changes and my about-page content, then merged the PR. The commit history shows all our changes in order, so if we break something, we can revert to an earlier version."

4. Mistake Taxonomy

Mistake 1: The "I’ll Just Commit Everything" Spaghetti
- Prompt: "You’re working on a Python game. You fixed a bug in player.py, added a new enemy in enemy.py, and tweaked the colors in settings.json. Write the commands to commit these changes with a good message." - Common wrong response: bash git add .
git commit -m "fixed stuff" - Why it loses credit: - git add . stages all changes, even unrelated ones (e.g., a typo in README.md).
- The commit message is vague—future you (or your team) won’t know what "fixed stuff" means.
- Correct approach: bash git add player.py git commit -m "Fixed player collision bug in move() function" git add enemy.py git commit -m "Added new enemy type: Ghost" git add settings.json git commit -m "Updated color palette to match theme" Key: Commit one logical change at a time with a message that answers: What changed, and why?

Mistake 2: The "I Forgot to Pull" Overwrite
- Prompt: "You and a teammate are working on the same file. You edit line 10, save, and push to GitHub. Meanwhile, your teammate also edited line 10 and pushed first. What happens when you try to push, and how do you fix it?" - Common wrong response: - "I just push again—it’ll work." - "I delete my changes and start over." - Why it loses credit: - Git rejects your push because your local repo is out of date.
- Overwriting your teammate’s work is a cardinal sin in collaboration.
- Correct approach: 1. git pull to fetch their changes.
2. Git will show a merge conflict in the file (marked with <<<<<<<, =======, >>>>>>>).
3. Open the file, decide which changes to keep (or combine them), then delete the conflict markers.
4. git add <file> and git commit to finalize the merge.
5. Now you can git push.

Mistake 3: The "Branch? What Branch?" Chaos
- Prompt: "Your team is building a website. You’re adding a login page, and your teammate is fixing a bug in the homepage. How should you organize your work in Git?" - Common wrong response: - "We both work on the main branch—it’s easier." - "I’ll make a branch called my-branch." - Why it loses credit: - Working on main risks breaking the stable version.
- Branch names like my-branch are meaningless—future you won’t know what it was for.
- Correct approach: - Create a branch per feature/bugfix with a descriptive name:
bash
git checkout -b add-login-page
git checkout -b fix-homepage-bug - Work on your branch, commit changes, then open a PR to merge into main.
- Bonus: Delete the branch after merging to keep the repo clean.

5. Connection Layer

1. Within CS: Version control → Debugging

2. Git’s commit history is like a time machine for bugs. If a feature stops working, you can git bisect to find the exact commit that broke it—no more guessing.

3. Across subjects: Git branches → History (counterfactuals)

4. Branches let you explore "what if" scenarios in code (e.g., "What if we used a different algorithm?"). Historians do the same with counterfactuals (e.g., "What if the South won the Civil War?"). Both are tools for controlled experimentation.

5. Outside school: Pull requests → Wikipedia edits

6. When you edit a Wikipedia page, your changes go into a "pending" state for review—just like a PR. The community discusses, suggests edits, and approves (or rejects) your contribution. GitHub is Wikipedia for code.

6. The Stretch Question

"GitHub lets you ‘fork’ a repo—make your own copy to experiment with. But if you fork a project, make changes, and want to contribute back, you have to open a pull request from your fork to the original. Why doesn’t GitHub just let you push directly to someone else’s repo? What’s the point of this extra step?"

Pointer toward the answer:
- Ownership: The original repo’s owner controls what gets merged. A PR is a request—they can review, suggest changes, or reject it. This prevents random people from breaking the project.
- Trust: Open-source projects (like Linux or Python) have thousands of contributors. Without PRs, anyone could push malicious code. PRs act as a gatekeeper.
- History: Forks let you experiment without permission. If your changes are rejected, you still have your fork to build on. It’s like writing a fanfic—you can remix the story, but the original author doesn’t have to include your version in the canon.

Bonus: This is why GitHub’s "social coding" model works—it balances collaboration with control. The same idea powers Wikipedia’s edit reviews or even government policy drafts (e.g., public comment periods).