Open by lowering the room temperature. This is not a Git class. It is a one-hour loop where people keep judgment while the agent handles mechanics.
Your first pull request, no commands required.
One small contribution. One real pull request. The learner keeps judgment while the agent handles the Git mechanics in the open.
- 01BranchMain stays clean.
- 02Edit + diffReview happens here.
- 03MergeMain changes after approval.
Nothing the agent does is final until you look at it.
This is the trust contract for the room. The agent can move quickly because the learner has a review point before anything ships.
- 01IntentYou say what should change.
- 02ProposalThe agent edits on a branch and shows its work.
- 03ReviewYou read the diff before approval.
- 04MergeMain changes only after the yes.
GitHub is shared work, proposed changes, and a record.
The nouns are less scary when each one has a job.
What GitHub actually is
A team changing shared work on purpose, and keeping a record of every change.
Your idea travels through safety checks.
Fork, branch, commit, push, PR, merge. Each stop protects the shared version until the change is reviewed.
From your idea to the team's yes
Each stop is a safety check for the team, not a test for you.
- 1 Fork
forkTake your own copy to work in. - 2 Clone
git clonePull that copy down to your machine. - 3 Branch
git switch -cIsolate your idea from everyone else. - 4 Edit
change a fileMake the actual change. - 5 Commit
git commit -mSave it with a message that explains why. - 6 Push
git pushSend your branch back up to GitHub. - 7 Pull request
open PRPut the change up for review. - 8 Merge
mergeThe team agrees, and it ships.
One room. One assistant. Your judgment.
VS Code keeps the file, request, diff, and pull request close enough that the learner can keep their bearings.
Where you work, and who does the typing
Two things make this possible. You don't have to be an expert in either one.
You → Copilot, inside VS Code → the work, on GitHub
The workflow is a conversation with checkpoints.
The agent handles Git. The learner keeps the decision. That division of labor is the whole point.
You keep the intent. The agent runs the mechanics.
- You State the intent Plain language. What you want, not which command.
- Agent Plans the steps Branch, edit, commit, push, open a PR.
- Agent Does the work Runs the mechanics so you do not memorize them.
- Agent Shows its work The diff and each move, labeled as it goes.
- You Review & approve You keep the judgment. Nothing ships unseen.
SayIn the practice repo, add my name, Thor Draper, to Contributors.md in alphabetical order on a new branch called add-thor-draper, commit it with a clear message, and open a pull request.
GetA branch, one edited line, a labeled commit, and an open PR.
SayShow me the diff of what you just changed before we push anything.
GetThe exact before-and-after, so nothing ships unseen.
SayExplain in plain language what a branch is and why we made one before editing.
GetThe concept, tied to the action you just watched.
Read the diff before you approve.
A plus sign and one green line are enough evidence to decide whether the work matches the request.
What a diff looks like
- Alex Rivera - Maria Chen+- Thor Draper - Uma Patel - Wei Zhang
When the agent is wrong, narrow the request.
A small mistake is useful here. It proves the learner can correct the outcome without grabbing for commands.
+ Thor Draper Alex Rivera Maria Chen Uma Patel Alex Rivera Maria Chen + Thor Draper Uma Patel The sequence matters because it becomes reusable.
Once the learner can name the stops without help, Git has stopped being a wall.
Everything you just did, in order
Each step ties the idea to something you can see, then something you do.
- 1 Get your bearings WeAccounts in, Copilot on, same repo. Name what GitHub is for.
- 2 The safety rule WeNothing ships unseen. Name the workflow before using it.
- 3 One shared example WeOne contribution, agent narrating. Main stays untouched on screen.
- 4 Your first contribution YouNarrow prompt, predictable outcome. Ask, inspect, adjust.
- 5 Read the diff, merge it YouReview the change, approve, merge, delete the branch.
- 6 Say it back YouExplain a branch in your own words before the next challenge gets heavier.
What's a branch, and why did we make one?
If they can answer that without jargon, the session worked.
What you leave able to do, and how you'll know
- › Explain what GitHub is for: a team changing shared work on purpose, with a record.
- › Name the reason behind each step — branch, commit, pull request, merge.
- › State an intent precisely enough that an agent does what you meant.
- › Read a diff and approve a change instead of taking it on faith.
- ✓ You have a merged pull request with your name on it.
- ✓ You can explain, in your own words, why we branched before editing.
- ✓ You wrote a narrow prompt and got the outcome you expected.
- ✓ You read the diff before approving, so the judgment stayed yours.