I have run Git and GitHub workshops at LBEF a few times now, alongside Muna Bhattarai and Suraj Bhattarai. Every session has found a gap in my own understanding, and always in the same way: a student asks why, and I discover my answer is a habit rather than a model.
Git looks simple on slides
The slide version is four commands. Add, commit, push, pull. Everybody nods.
Then thirty people work on one repository at the same time, and the slide version stops being sufficient within about fifteen minutes. Somebody commits to main. Somebody else pulls and gets a conflict they did not cause. Somebody force-pushes and removes an hour of a neighbour's work. None of this is in the slides, and all of it is what Git actually is.
The best decision we made was putting everyone on a shared repository early, so branches, pull requests, reviews, merges and conflicts happened for real. A conflict you caused yourself teaches more in five minutes than a diagram does in an hour.
The question I could not answer well
A student asked what the difference between git fetch and git pull is, and why anyone would use fetch if pull does more.
I knew the mechanical answer. fetch updates remote-tracking refs; pull is fetch followed by a merge or rebase. I said that, and the student's face made it clear the answer had explained nothing.
The answer that landed was about what you can inspect. fetch brings the remote's state into your repository without touching your working tree, so you can look at what changed before deciding what to do about it. pull decides for you. If you want to see whether someone rewrote the branch you are on before your working tree changes underneath you, you fetch.
I had used fetch that way for years without being able to articulate why. That is the gap teaching finds.
Conflicts are the whole thing
Beginners treat a merge conflict as an error state. It is the opposite: it is Git declining to guess.
Reframing it as "two people changed the same lines and Git will not decide which is right" moves it from failure to decision. And it makes conflict markers readable rather than frightening, because you know what each side is: this is what your branch says, this is what theirs says, pick or combine.
The students who understood this stopped being afraid of branching. The ones who did not kept working on main to avoid conflicts, which produces a worse version of the same problem with no markers to help.
Commit messages are for strangers
The hardest habit to instil, and the one with the longest payoff.
"fix", "update", "changes", "final", "final2". Everybody writes them, including me under pressure. The reframing that worked: you are writing to someone who has to change this code in eight months and has no context, and there is a good chance that person is you.
A subject line that says what changed and why beats a perfectly formatted one that says nothing. We did not teach a convention. We taught the audience.
What I would change
More time on undo. Students are far more anxious about breaking something irreversibly than about any concept, and that anxiety is what makes them avoid branching and force-pushing and everything else worth learning.
Teaching git reflog early would address the anxiety directly. Almost nothing in Git is actually lost, and knowing that is what gives a beginner permission to experiment. We covered it at the end, when everyone was tired. It belongs near the beginning.
Why this is in a DevOps portfolio
Because version control is the substrate under everything else I work on. GitOps is a claim that Git is the source of truth for cluster state. That claim is only as strong as the team's fluency with Git.
An organisation whose engineers are afraid of branches will not run a functioning GitOps workflow, no matter which reconciler it installs. The workshop and the infrastructure work are closer together than they look.