Git: track your work

This is the complete birth of a repository: turn a plain folder into one Git watches, identify yourself, create a file, and make your first commit (your first saved snapshot). Run these lines top to bottom in a fresh folder.

1. git init creates a hidden .git folder — that's what turns an ordinary directory into a Git repository. You only do this once per project.
2. The two git config commands set the name and email Git stamps onto every commit, so history records who made each change.
3. echo "# Project" > README.md creates a file (this is shell, not Git). Then git status shows it as untracked — Git can see the file but isn't following it yet.
4. git add README.md stages it (working dir → staging), and git commit -m "Add README" saves that snapshot with a message. git log --oneline then lists your commits, one per line.

What the output means: git log --oneline prints a single line: a short commit ID (a sha) followed by your message Add README — proof the snapshot is saved in history.

Try this: Run git status again right after the commit. It now says "nothing to commit, working tree clean" — meaning all three areas match and there's nothing waiting to be saved.

This is the loop you'll repeat hundreds of times a day: edit → stage → commit. Once a repo exists (from the previous lab), real work is just running these three steps over and over as you make progress.

1. echo "print('hi')" > app.py creates/edits a file — this is the edit step, happening in your working directory.
2. git add app.py stages that change. The comment mentions git add -p: an interactive mode that lets you stage parts of a file (called "hunks") when one file has several unrelated edits.
3. git commit -m "Add entrypoint" saves the staged change as a snapshot with a clear message.
4. git log --oneline --stat shows history plus, for each commit, which files changed and by how many lines — a quick way to see the size of each change.

Try this: Edit app.py again but don't stage it, then run git status. You'll see it listed under "Changes not staged for commit" — the working dir and staging no longer match until you git add again.

These are your read-only commands for understanding a repo's past — none of them change anything, so they're safe to run any time you're confused about what happened or who changed what.

1. git log --oneline --graph --all draws history as a compact text diagram, including branches — a quick visual overview of how commits connect.
2. git show HEAD displays the most recent commit in full, including its exact diff. HEAD is Git's word for "the commit you're currently on".
3. git diff shows edits you've made but not yet staged; git diff --staged shows what's staged and ready to commit. Comparing the two tells you exactly which changes are in which area.
4. git blame app.py annotates every line of a file with the commit, author, and date that last changed it — invaluable when you need to know why a line exists.

Try this: Run git diff, then git add the file, then git diff again. The second time it shows nothing — because the change moved to staging, and plain git diff only reports the working-dir-vs-staging gap.

A .gitignore file is a plain list of things Git should pretend it can't see. Without it, you'd accidentally commit generated files, caches, and — most dangerously — secrets. Each line is one pattern to ignore.

1. .venv/ and __pycache__/ (the trailing / means "a folder") skip your virtual environment and Python's compiled cache — big, machine-specific, and pointless to share.
2. *.pyc uses * as a wildcard: ignore every file ending in .pyc. Same idea for *.log.
3. .env is the important one — it holds secrets/API keys. The comment shouts NEVER commit it, because a committed secret is exposed forever (see the warning below the code).
4. .DS_Store, dist/, and build/ are OS clutter and build output — regenerated automatically, so they don't belong in history.

Try this: Create a file called secret.env, add the line .env to .gitignore, then run git status. If the pattern matches, the file simply won't appear in the list of things to commit — Git is ignoring it.

This Python program answers a real release question — "what changed since last time?" — by reading Git from code instead of by hand. It builds a tiny throwaway repo, adds a few commits, then groups their messages into a changelog. It runs anywhere because it creates its own repo in a temp folder.

1. repo = Path(tempfile.mkdtemp()) makes a brand-new empty folder, and the git(*a) helper runs any Git command inside that folder (cwd=repo) and hands back its text output. This is how Python "talks to" Git — by running the same commands you'd type.
2. The for msg in [...] loop creates four commits, each with a conventional message like feat: login or fix: null check — a type, a colon, then a description.
3. git("log", "--pretty=format:%s") asks Git for just the subject line of each commit. .split(":")[0] pulls the type (feat/fix/chore) and groups.setdefault(kind, []).append(...) files each message under its type.
4. The final loop prints a section header (## feat) and a bullet per message — a finished, human-readable changelog.

What the output means: A grouped changelog: a ## feat section listing login and logout, a ## fix section with null check, and a ## chore section with bump deps — assembled entirely from the commit messages.

Try this: Add "docs: readme" to the list of messages. It won't appear in the output yet — because the last loop only prints feat, fix, and chore. Add "docs" to that tuple to include it.

This computes the next version number automatically from your commits. Versions look like MAJOR.MINOR.PATCH (e.g. 1.4.2): a bug-fix bumps the last number, a new feature bumps the middle, and a breaking change bumps the first and resets the rest. This is exactly how professional release tools decide the version.

1. major, minor, patch = map(int, current.split(".")) splits "1.4.2" into the three numbers 1, 4, 2 so we can do math on them.
2. bump starts at "patch" (the smallest change) and only ever gets bigger as the loop scans commits: a feat raises it to "minor", and the word BREAKING raises it all the way to "major" and stops early with break.
3. The three if bump == ... lines at the end build the new version string: major resets minor and patch to 0 (2.0.0); minor resets only patch (1.5.0); otherwise just add one to patch (1.4.3).
4. The three print(...) calls test it on sample commit lists, with the expected answer in the comment beside each.

What the output means: Three version numbers, one per test: 1.4.3 (only a fix), 1.5.0 (a feat present), and 2.0.0 (a BREAKING change wins over everything).

Try this: Call next_version("2.9.9", ["feat: x"]) and predict the answer before running: a feat bumps minor and resets patch, so you should get 2.10.0 (note 9 becomes 10, not carrying over — versions aren't decimals).

So far everything lived only on your computer. These commands connect your local repo to a remote — a hosted copy on GitHub — so you can back it up and share it. A remote is just another copy of the same repo that lives on a server.

1. git remote add origin git@github.com:you/proj.git tells your repo where the GitHub copy lives and nicknames it origin (the conventional name for "the main remote").
2. git branch -M main renames your current branch to main — the standard name for the primary line of work.
3. git push -u origin main uploads your commits and, thanks to -u, remembers the link so that afterwards a bare git push (upload) and git pull (download others' commits) just work with no extra arguments.
4. git clone git@github.com:you/other.git is the reverse: it downloads a whole existing repo from GitHub onto your machine — how you start working on someone else's project.

Try this: Think of push and pull as sync: push sends your local commits up to GitHub, pull brings teammates' commits down. Nothing on the remote changes until you push.

A hook is a script Git runs automatically at a certain moment — here, right after you write a commit message. This one checks the message follows the team's convention and rejects the commit if it doesn't, so bad messages never reach history in the first place.

1. PATTERN = re.compile(r"^(feat|fix|docs|refactor|test|chore)(\(.+\))?: .{1,72}$") is a regular expression — a pattern for text. In plain English it demands: one of those approved types, an optional (scope), then : and a description of 1–72 characters.
2. valid(message) takes the first line of the message (.splitlines()[0]) and returns True only if it matches the pattern — bool(PATTERN.match(first)).
3. The for loop feeds four sample messages through valid and prints OK or REJECT for each, so you can see the rule in action.
4. The final comment shows the real hook: in an actual .git/hooks/commit-msg file it would sys.exit(0) to allow the commit or sys.exit(1) to block it — a non-zero exit is how a hook says "no".

What the output means: Four lines: feat: add login and fix(auth): handle null token pass (OK), while fixed stuff and wip fail (REJECT) because they don't start with an approved type and colon.

Try this: Add "docs: update readme" to the list — it passes. Then try "feat add login" (no colon) — it's rejected, because the pattern requires the : separator.