ai-ledger

20b — Git Explained Using Accounting Terms

~4 min read · Part 2 of 6 in Version Control for Accountants in the AI Era

PythonMuse LLC Series launch · 2026

Git Explained Using Accounting Terms

You Already Understand Git. You Just Don’t Know It Yet.

Accountants hear the word “Git” and the brain immediately serves up:

Take a breath.

Git is not software engineering.

Git is structured change tracking — and accountants invented structured change tracking. We just call it different things.

The Translation Table

Git Concept What Accountants Already Call It
Repository A workpaper folder
Commit A journal entry
Commit message The JE explanation / memo
Git log / history The audit trail
Branch A scenario / draft version of the budget
Main (or master) branch The official ledger everyone trusts — the version that’s “live”
Merge Posting the approved entry to the final ledger (the main branch)
Pull request The review-and-approval workflow
Revert A correcting entry, made as a new commit that preserves history — and like any other change, it typically goes through its own review and approval before it’s accepted
Tag A closed reporting period
.gitignore Files you intentionally leave out of the folder
Diff The “track changes” view between two workpapers

Read that table twice. Every Git concept is already part of how you work.

The only thing Git adds is consistency — it stops humans from forgetting to write the memo.

Push, Pull, and Main

Three words worth knowing on their own — the accounting analogy gets looser here.

Main and merge already showed up in the table above with a fairly clean accounting parallel. Push and pull are looser — but the analogy still holds well enough to be useful, and the mechanics matter enough that they’re worth spelling out directly rather than only through analogy:

Git Word What It Actually Means Closest Accounting Parallel
main (or master) The official, current version everyone treats as live. The final ledger, as above.
Push Sending your committed changes up to the shared repository. Submitting your completed workpaper for review.
Pull Bringing someone else’s changes into yours, or into main. A reviewer incorporating an approved submission into the official file.

A bit more on the mechanics: a push can be one commit at a time, or a batch of several commits sent up together once you’re ready. And pull is literally what happens when a reviewer accepts a pull request — they’re pulling your branch’s changes into main.

Here’s what that looks like when more than one person is working at once:

Branches merging into main

main runs down the middle as the official version. Two people can branch off it at the same time — Susan drafting a scenario, you drafting another — and neither blocks the other. When a branch is ready, its pull request asks the approver to pull those changes into main. The approver can see every branch waiting for review, and can merge each one independently as long as they don’t conflict with each other.

Compare that to editing the same file together in Excel Online or SharePoint: multiple people can edit at once, but there’s no automatic record of who changed what and why — only what someone happens to type into a comment or a version note. Article 20d covers that comparison in full.

“But Accountants Already Use Primitive Version Control”

Of course we do. Look at how we name files when we’re trying to be careful:

That’s all version control. It’s just manual, fragile, and impossible to audit.

Git is what happens when you stop doing it by hand:

A Commit, Translated

Here’s what a commit looks like conceptually (no terminal needed):

👤  Author:  Svetlana Toohey
🕓  Date:    2026-04-30 16:12
📝  Message: "Updated depreciation formula to reflect ASC 842 transition adjustment"
📂  Files changed:  depreciation_formula.py, journal_entries.csv

Now translate it into accounting language:

JE-2026-0412 — Posted by S. Toohey on 4/30/2026 at 4:12 PM. Updated depreciation per ASC 842 transition. Supporting workpapers: depreciation_schedule, JE detail.

Same shape. Same level of evidence. Same audit-friendly format.

The only difference: you didn’t have to remember to write it down.

A Note on File Types

📎 Why the example above uses .py, not .xlsx.

Git can technically track an Excel file or a PDF — it just can’t tell you what changed inside them. Those are binary formats, so Git only sees “this file is different now,” not a line-by-line diff.

That’s why this series is really about version-controlling the scripts and logic that produce the spreadsheet — not the spreadsheet itself. The .xlsx your CFO opens, or the PDF you send to the auditor, is an output. The formula, script, or query that built it is the thing you actually want a diff, a history, and a review trail for.

A Framework, Not a Tool

Same reminder as always → see the hub’s A Framework, Not a Tool. Every concept above (commit, branch, PR, tag) exists in GitHub, Azure DevOps Repos, and AWS CodeCommit with nearly identical names. Pick the one your company already pays for. We use GitHub in this series because the UI is the friendliest for non-engineers.

The Fear Drop

Most accountants who get scared off Git get scared by the terminal.

But here’s the truth: you can do 95% of what’s in this series without ever opening a command line. VS Code, GitHub Desktop, and the GitHub website have buttons for everything we’ll cover:

The terminal is optional. The mindset is not.

What’s Next

You now have the vocabulary. In Article 20c — How Finance Teams Should Structure AI Repositories, we turn that analogy into an actual folder structure your team can adopt next Monday.

Next in the Series

→ Article 20c — How Finance Teams Should Structure AI Repositories

A note on how this article was made. This article started with me. The accounting/Git analogies came out of years of explaining to colleagues why “save-as-with-a-date” was almost-but-not-quite version control. GitHub Copilot (Claude Sonnet 5.5 and Opus 4.7) then built the final article and all visual concepts — working from my direction and feedback at each step. I reviewed every output, pushed back on things I didn’t like, and made all final content decisions. That process — bringing your own experience, using AI to build and iterate, and staying in the editorial seat throughout — is exactly what this series is about.

By Svetlana Toohey

© 2026 PythonMuse LLC. Content licensed under CC BY-NC-SA 4.0; code licensed under MIT.

This site is open source. Improve this page.