Session 11: Coach notes

Goal of this session

At the end of this session a ninja can:

• Explain what version control is and why you use it.
• Install Git on their own laptop and set up git config.
• Create a repository with git init.
• Add files with git add and commit with git commit -m.
• Use git status, git diff, git log --oneline and git show to inspect changes.
• Create a .gitignore file and understand why it exists.

What is not expected: branches, GitHub, pull requests. Those come in sessions 12 to 15.

Preparation (30 min before the session)

• Check Git Bash on the Windows laptops. Many Windows laptops don’t have Git. Make sure the installers are ready on a USB stick, or share the download link (git-scm.com). Installing takes ~5 minutes.
• Estimate the terminal anxiety. Many ninjas have never opened a terminal. The first 15 minutes go to explanation: what is a terminal, how do you type commands, what does Enter do.
• Walk through the session yourself. Make a repo, commit a few files, do a git diff, a git log. Make sure you go through the steps without mistakes so you can help ninjas.
• Projector ready for terminal demos. Put the terminal on a large font (Ctrl+Plus in most terminals). Ninjas must be able to read commands from where they are sitting.

⚠️ Risk: the terminal is new to many

For many ninjas (especially 10 to 12 year olds) the terminal is completely new. The command-line interface is not visual, and error messages are in English.

Mitigations:

• Demo everything on the projector first. Type every command and explain what happens. Don’t let them start on their own before you have demonstrated the first two steps.
• Print the cheatsheet or write it on the board. The most used commands (git status, git add, git commit, git log) must stay visible.
• Typos are normal. Explain that the terminal is extremely precise: git Status (capital letter) doesn’t work, git status (lower case letters) does. One space too many or too few can give an error.
• git commit without -m opens an editor. If a ninja types git commit without -m, Vim or Nano opens. Teach them: Escape, then :q! and Enter to escape. Then again with -m.

Schedule (3 hours)

Common questions

“Do I have to git add every file separately?” Yes, in the beginning you do. Later you can use git add . to add all changed files at once. But first learn the check with separate files, that way you avoid accidentally committing things that don’t belong in Git.

“What if I accidentally commit a password?” Don’t panic. If it is local (not yet sent to GitHub) you can fix it. If you have already pushed it to GitHub: change the password immediately. Removing a commit from the GitHub history is nearly impossible. This is exactly why we use .gitignore.

“Git says ‘fatal: not a git repository’” You are not in the right folder. Use cd to go to your project folder. Check with ls whether you see the .git folder (it is hidden, so ls -a to see it).

“What is the difference between git add and git commit?” git add = “I want to keep these changes.” git commit = “Keep them now, with this label.” You can git add several times and then do one git commit that packs everything together. The staging area is your shopping basket: you put things in it with add, and at the checkout (commit) you pay for everything at once.

Hints for Stretch and Expert

Give hints, not full commands.

Stretch: several files at once: If you have changed three files, you can git add them one by one, or all at once with git add . (dot = current folder + everything in it).

Expert: back in time with git checkout: git checkout <commit-hash> -- <filename> restores one file to how it was in that commit. The rest of your project stays as it is. Handy when you have messed up one file.

Cliffhanger script

Read this to the group at the end of the session:

“Now you have one line of commits. Everything neatly one after the other. But what if you want to try out a new idea without breaking your working code? What if two people work on the same project at the same time? Next time we split our code into parallel universes. That’s called branches. Bring your laptop, we’re going time travelling.”

Why this session, now?

Until now ninjas worked on projects on one computer, with one version. If something broke, there was no way back (except “Ctrl+Z until yesterday”).

This session introduces the basic infrastructure that professional developers use every day. It is not a Python session, it is a tool session. The goal is not that they master Git perfectly, but that they:

1. Understand that version control exists.
2. Know the basic terminology (repo, commit, staging, log).
3. Can start a repo themselves and make commits.

That gives them a foundation for sessions 12 to 15, and for every programming job they do after this.

Important: Don’t force perfection. As long as a ninja can do git init, git add, git commit and understands git status, the session is a success.