If GitHub is the shared drive for code, Git is the change-tracking system underneath. It’s what makes edits reviewable and reversible instead of a mystery.
Think about a shared document with track changes on. You see what changed, who changed it, and why the final version differs from the old one. If two people edit the same paragraph, you resolve the conflict instead of guessing. Git brings that to a whole project folder: it tracks changes across a repository, lets people work on separate lines, saves snapshots, and merges them back. Git isn’t the same as GitHub. Git is the tool for tracking versions; GitHub is a hosted place where Git repositories live and teams review work. You can use one without the other.
How it shows up
The unit you hear most is a commit, a saved snapshot with a message answering “what changed and why?” Good commits make work easy to review; bad ones turn history into mush. You’ll also hear branch, a separate line of work: instead of changing the main version directly, you branch, make and test changes there, then ask to merge them back through a pull request. For agents, Git creates accountability. If Codex edits five files, Git shows exactly what changed. If two agents touch the same file, Git surfaces the conflict instead of hiding it.
Why you care
That’s why we care about version control for skills and shared work: a skill file may just be markdown, but once a team depends on it, changes need a record you can review and roll back. You don’t need to memorize commands. You need the mental model: Git is the ledger of the work, the reviewable history of every change.