Git is one of the few skills where the fear of doing damage stops people learning. So we start every workshop by making damage routine.

Break things in a repository that does not matter

The first exercise is deliberate: create a branch, edit the same line two different ways, merge them, and resolve the conflict. Then commit something you regret, and undo it.

Once a student has recovered from a self-inflicted mess, the tool stops feeling dangerous.

Teach the mental model, not the command list

Students who memorise commands stall the moment a command produces an unexpected message. The model is simpler than it looks:

• A commit is a snapshot with a parent.
• A branch is a movable label pointing at a commit.
• HEAD is where you are right now.
• Merging is combining histories; conflicts happen when the same line changed twice.

Everything else is bookkeeping on top of that.

Recovery is the topic people actually need

The commands we spend the most time on are the ones that undo things safely:

bashgit restore --staged file.txt   # unstage, keep changes
git revert HEAD                 # undo a pushed commit, safely
git reflog                      # find work you think you lost

git reflog in particular changes how people behave. Almost nothing in Git is truly unrecoverable, and knowing that makes students experiment.

Pull requests are the real skill

Writing code is only half of it. The other half is explaining a change so someone else can review it: a short description, why it was done this way, screenshots for interface changes, and how it was tested.

We give feedback on the description as carefully as on the diff. It is the same skill they will need in their first job.

What we avoid

We do not begin with rebasing, cherry-picking or conflict strategies under time pressure. Those are useful later, once the core is solid. Fundamentals practised until they are boring beat advanced commands demonstrated once.