Lab 23 · Set Up Git and Make Your First Repository
🎯 Objective
Go from zero to a working Git repository with a real history: commits you can explain, a branch you created and merged, and the confidence to undo a mistake safely.
🧩 Skills You Will Practice
- Git installation and configuration
- git init / status / add / commit
- Reading git log
- Branching and merging with git switch and git merge
🧰 What You Need
- A computer with internet for the one-time Git download
- A terminal (Terminal, Command Prompt, or the VS Code integrated terminal)
- A plain text editor
- The Git Basics lesson open for reference
📋 Step-by-Step Tasks
- Install Git from the official git-scm.com website using the default options. Open a terminal and run git --version — write down the version it prints. If the command is not found, restart the terminal and try again before anything else.
- Configure your identity exactly as real projects require: git config --global user.name with your real name, and git config --global user.email with your email. Verify both with git config --global --list. Every commit you ever make carries this identity.
- Create the project: make a folder named my-first-repo, move into it, and run git init. Run git status and read the whole output — Git is telling you the branch name and that there is nothing to commit yet. Find the hidden .git folder and understand: it is the repository memory, never edit it by hand.
- Create README.md with a project title and one line describing the project. Run git status (the file is untracked), then git add README.md, then git status again (the file is now staged). Commit it: git commit -m "Add README with project title". Three states — untracked, staged, committed — observed with your own eyes.
- Practise the rhythm twice more: add a file notes.txt with two lines and commit it with the message "Add study notes file". Then edit notes.txt, run git diff to read exactly what changed line by line, stage it and commit "Expand study notes with Git commands list". Never commit before reading your own diff.
- View your history with git log --oneline. You should see three clean commits. Pick the middle commit, note its short ID, and use git show with that ID to see exactly what that snapshot changed.
- Create a branch for an experiment: git switch -c feature/about. On this branch, add about.txt describing the project and commit it. Run git log --oneline on the branch, then git switch main and run it again — the about commit exists only on the branch. This isolation is the entire point of branching.
- Merge the work home: while on main, run git merge feature/about. Confirm about.txt now exists on main and git log --oneline shows the full story. Delete the finished branch with git branch -d feature/about.
- Make one deliberate, safe mistake and recover: edit README.md badly, do NOT commit, then run git restore README.md and confirm the file returned to its committed state. Note in your lab journal which recovery you used and why it only works because the bad edit was never committed.
✅ Expected Result / Deliverable
A my-first-repo folder containing: Git correctly installed and configured with your identity, a repository with at least 4 commits with clear messages, one branch that was created, committed on, merged into main and deleted, a git log --oneline screenshot or copy as proof, and one recovered mistake documented in your journal.
⚠️ Common Mistakes
- Skipping the identity configuration, then wondering why commits fail or show a stranger name
- Committing without running git status and git diff first
- Writing messages like update or changes that future-you cannot understand
- Trying to merge while still ON the feature branch instead of switching to main first
- Panicking at a restore or reset — check git status and git log before running any recovery command
Work only on your own files and your own repositories — this lab needs nothing belonging to anyone else. Never commit passwords, API keys, private documents or other people files into any repository: treat every commit as permanent and, once shared online, effectively public. If you later push this repo to GitHub, push only practice content you are happy for the world to see.