https://python.coderdojohasselt.be/en/sessions/git/14-git-best-practices/index.htmlYou can type Git commands. Your code is on GitHub. But there’s a difference between “using Git” and “using Git well.” This session is about the habits experienced developers apply every day. No new commands, just sharper rules. At the end you write commit messages you’ll still get something out of a year from now, and you work with a branching strategy that keeps your project tidy. What you’ll learn today How to write a commit message that says something Three simple rules for branching What git stash is and when to use it The pull-before-you-push rule Part 1: Commit messages that say something A bad commit message looks like this:Hugoenhttps://python.coderdojohasselt.be/en/sessions/git/14-git-best-practices/mentor-notes/index.htmlMon, 01 Jan 0001 00:00:00 +0000https://python.coderdojohasselt.be/en/sessions/git/14-git-best-practices/mentor-notes/index.htmlGoal 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) Time Activity 0:00 to 0:10 Recap of sessions 11 to 13: commits, branches, GitHub 0:10 to 0:30 Projector: bad vs. good commit messages 0:30 to 1:00 Working on your own: rewriting your own old commits (not with rebase; just make new commits with better messages) 1:00 to 1:15 Break 1:15 to 1:40 Projector: branching strategy, .gitignore, git stash 1:40 to 2:30 Working on your own: branches with prefixes, creating a .gitignore, practising git stash 2:30 to 2:45 Showcase: show your commit messages and branch structure 2:45 to 3:00 Cliffhanger, take-home 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.