Git sessions :: CoderDojo Python & Pygame

Session 11: Git: Your code's history book

Mon, 01 Jan 0001 00:00:00 +0000

Imagine: you work on your game for three hours. You add a cool new weapon. But… now the rest of your game doesn’t work anymore. And you no longer know what exactly you changed. Three hours of work gone. Git is the solution. Git remembers every version of your files. Like an endless “undo” button that never forgets what you did. In this session you install Git, you make your first repository and you record what you do for good: step by step, version by version. And the fun part: Git doesn’t only work for code. Also for notes, school reports and stories.

Session 12: Git Branches: Parallel universes for your code

Mon, 01 Jan 0001 00:00:00 +0000

Last session you learned to make commits: snapshots of your code on one timeline. Everything neatly one after the other. But what if you want to try out a new idea? Adding a laser gun to your game, for example. You don’t know whether it will work. You don’t want to break your working code. That is what branches are for. A branch is a copy of your code where you can experiment freely. Your main code (the master branch) stays safe. If your experiment works, you paste it back into master. Doesn’t it work? You throw the branch away. Your master branch never noticed a thing.

Session 13: GitHub: Your code online, for everyone

Mon, 01 Jan 0001 00:00:00 +0000

Until now all your code lives on your laptop. Handy for you, but nobody else can get to it. And if your laptop crashes, you lose everything. GitHub is a website where you put Git repositories online. It is a backup, a portfolio, and a collaboration platform in one. Today you put your code on GitHub. At the end of this session anyone with an internet connection can look at your projects, and you at theirs.

Session 14: Git Best Practices: Write commits you'll still understand later

Mon, 01 Jan 0001 00:00:00 +0000

You 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:

Session 15: Pull Requests: Your project's front door

Mon, 01 Jan 0001 00:00:00 +0000

You built a feature on a branch. Good commit messages, tidy work. Now you want to get your code into master. You could do git merge and be done. But in a team that doesn’t work. Someone else has to look at your code first: check for mistakes, for style, for things you missed. That is a pull request. A pull request (PR) is a request: “Bring my changes in.” You open it on GitHub. Your teammates look at your code and give feedback. You change things. Only when everyone is happy does the code go to master.

Session 16: Markdown: Write notes that look like the web

Mon, 01 Jan 0001 00:00:00 +0000

You might know HTML from the internet:

,
, . But for notes and documentation HTML is far too much typing. That’s what Markdown is for. Markdown is a mini-language you write in plain text. It looks readable without having to convert it first. And with one push of a button it becomes neat HTML: headings, lists, links, tables. In this session you learn the whole basis of Markdown. At the end you write notes that look professional, on GitHub, in Obsidian, or in any other program that understands Markdown.