Phase 1: Git for Real Work · ~30 minutes · git

Git for Experiment Tracking

"I'll just remember which version produced this result" survives about a week. The commit hash is the only thing that actually remembers for you.

Hiring signal: Can answer 'which exact code produced this result' with certainty, months later, for any real run

What you will learn

Use commit hashes to pin exactly which version of code produced a given output
Use tags to mark a specific, meaningful commit for easy future reference
Explain why committing before every real run matters, specifically for reproducibility
Decide whether a tag, a branch, or a plain commit is the right tool for a given situation

Introduction

Type: Learn Languages: Git, Python Prerequisites: Lesson 03 (Commit Hygiene and Code Review) Time: ~30 minutes

Objective

Learning objectives

Use commit hashes to pin exactly which version of code produced a given output
Use tags to mark a specific, meaningful commit for easy future reference
Explain why committing before every real run matters, specifically for reproducibility
Decide whether a tag, a branch, or a plain commit is the right tool for a given situation

What you're building

A script run_experiment.py that:

Uses subprocess to get the current commit's short hash
Produces some real output (any real computation — even a trivial one) saved to a file named using that hash, following this lesson's results_<hash>.json convention
Run it at least twice, after making a real code change and a real commit in between, and confirm the two output filenames genuinely differ, matching the two different commits
Tag one of the two resulting commits with a meaningful name, and show git show <tag> --format="%H %s" -s confirming it points to the exact right commit
Write experiment_notes.txt explaining, using your own two real runs, why committing before running (not after) was essential for the filenames to be trustworthy

You need to permanently mark the exact commit that produced your best model result so far, for easy reference in a report six months from now, while continuing to actively develop new experiments afterward. What's the right tool?

This is exactly the table above, applied to a concrete case. A branch is the wrong tool specifically because branches are meant to move forward — continuing to develop would either require a separate, unused branch frozen in place (confusing) or the reference would drift as new commits land. A tag is built for precisely this: a permanent, human-readable name pointing at one unchanging commit, unaffected by any development that happens afterward on any branch. 'Remembering the date' is exactly the fragile plan this lesson opened by warning against.

Unlock the full lesson

You've read the first 2 sections. The rest of this lesson covers The Problem, Check Yourself, Key Terms & Next — plus a hands-on lab, quiz, and project artifact.

Create a free account to unlock Phase 0 and Phase 1 of every course — no credit card.