Your best project on GitHub, with a history a stranger can read

The situation

You have a project — any project, even a single-page site — that lives in a folder with copies named final, final2 and final-REAL. By the end of this lab it has a clean history, a README a non-coder can follow, a public home on GitHub with nothing sensitive in it, and you have rehearsed the whole team motion — branch, conflict, pull request — alone.

What you'll be able to show

• Commit in small, honest steps with messages a stranger can judge
• Recover from every common mistake without fear
• Publish a project with a README whose instructions actually work
• Rehearse branches, a deliberate conflict and a pull request

What you need

• git installed, and a GitHub account
• One real project of yours
• A second, empty folder for the clone test

Tasks

1. 1Init and three honest commits
   Inside the project, git init, configure your name and email, and make three commits: the initial one, then two real small changes, each with an imperative message that says what and why.
   A correct result: git log --oneline shows three commits whose messages a stranger could judge.
2. 2Two unrelated changes, two commits
   Make two unrelated changes (fix something small; add something small). Use git status and git diff to see both, then stage and commit them as two separate commits. Add a sensible .gitignore.
   A correct result: Two commits, each containing only its own change; a .gitignore that excludes secrets, dependencies and build output.
3. 3Recovery drills
   Deliberately: ruin a file and restore it; stage then unstage; amend a commit message; retrieve one file's version from two commits back; make a silly commit and git revert it. Note the command for each.
   A correct result: Five recoveries with their commands, and the log showing the revert.
4. 4Publish, README, clone test
   Push the project to a new GitHub repo. Write the three-paragraph README (what it is, how to run it, what it does not do). Inspect every file on the website as a stranger would — nothing sensitive. Then clone it into the empty folder and run it from the clone.
   A correct result: A public repo URL, a README, and the project running from a fresh clone.
5. 5Branch, conflict, pull request — alone
   Create a branch and commit a change to a specific line. Switch to main and commit a different change to the same line. Merge and resolve the conflict, keeping the best of both. Then push a branch and open, describe and merge a pull request on your own repo through the website.
   A correct result: A resolved conflict in the log, and a merged pull request on GitHub.
6. 6The audit and the card
   Audit your GitHub as a stranger: README quality, message quality, activity honesty, no secrets. Fix the weakest item. Write your personal git checklist card in your own words, and set a weekly reminder to push what you build.
   A correct result: The audit with one fix made, the card, and the reminder set.

What to hand in

The repo URL, the output of git log --oneline, the recovery notes, the merged pull request link, the audit with its fix, and the checklist card.

How it is marked