Session 14: Coach notes

Goal of this session

At the end of this session a ninja can:

• Write commit messages with a title (max 72 characters, imperative mood, English) + an optional body.
• Explain why master always has to work.
• Organise branches with the feature/, bugfix/ and experiment/ prefixes.
• Use git stash and git stash pop to put half-finished work aside.
• Do git pull by default before git push.
• Maintain a good .gitignore for Python projects.

Preparation (30 min before the session)

• Have a repo with bad commits ready. Make a demo repo with a few bad commit messages (“fix”, “update”, “wip”). Use it as “before” material to show how unclear the history becomes.
• Print-ready .gitignore cheatsheet. The .gitignore example from the session is a good reference sheet. Print it out or put it on the board.
• Multi-line commit demo. Show how to make a multi-line commit message without an external editor.

Schedule (3 hours)

Common questions

“Do I have to write every commit message in English?” Yes. Code is English. Variables are English. Function names are English. Commit messages follow that same language. Exception: if you work with an entirely Dutch-speaking team and that’s the agreement. But for open source and portfolio: English.

“What if I make a mistake in my commit message?” You can change the message of your last commit with git commit --amend. This opens an editor. Change the message, save, close. Note: if you already pushed this commit to GitHub, you have to use git push --force. Only do that on branches you alone use, never on master or shared branches.

“When do I use git stash vs. a branch?” git stash is for short interruptions: “I’m busy, but I need to switch for 5 minutes.” A branch is for: “This is a separate piece of work that needs several commits.” Rule of thumb: if you’re away from your current work for more than 10 minutes, make a branch.

“How do I know whether master ‘works’?” Run your code. If it runs without errors and the basic functionality does what it should, it works. Test this before every merge into master. If you merge a feature branch and something breaks on master, you have to fix that before you carry on with anything else.

Hints for Stretch and Expert

Stretch: git commit --amend: Change your last commit message without making a new commit. Only use it locally, not after pushing (unless with --force).

Expert: interactive rebase: git rebase -i HEAD~3 lets you reorder, combine or rename the last 3 commits. Powerful, but don’t use it on shared branches. This is Git’s “time machine on steroids”.

Cliffhanger script

“Commit messages, branches, .gitignore: that’s your toolbox. But there’s one more step between your feature branch and master. In every team, at every company, your code has to pass a review before it’s accepted. A pull request. You ask: ‘Can this go in?’ Someone else looks at it, gives feedback, and only then does your code go to master. Next time: how do you make a pull request, and how do you review someone else’s?”

Practical pitfalls

1. Commit messages in the past tense. “Added feature” is a very common mistake. It feels natural because you just did it. But Git itself describes commits in the present tense: Merge, not Merged. Train ninjas to type “Add”, not “Added”.

2. Commits that are too big. Ninjas often want to “commit everything at once”: all the work from the whole session. Encourage a commit every 15 minutes. Suggest: “Commit what you have now, then you can keep experimenting afterwards.”

3. Forgetting to commit .gitignore. .gitignore itself does have to go into Git. Otherwise other people who clone your repo have no ignore rules. This is a common beginner mistake: the file exists locally but was never git added and committed.