GitHub for Accountants

Git is the engine: the system that tracks every version of every file. GitHub is the website where we all store and share that work. You don't have to touch a command line to use it: GitHub Desktop is a free app that does everything below with buttons. If “terminal” or “coding” is what scares you off, you can skip both.

The single most useful reframe: GitHub is a shared engagement folder with a perfect audit trail and a built-in “propose a change” button. Nothing you do is ever lost. Every change is signed and dated. You can always roll back.

Repository (“repo”)

one project folder. Everything below happens inside a repo.

Organization (“org”)

our shared team account. Everyone's projects live under it, instead of scattered across personal accounts.

README

the front-page instructions on every project: what it is, what it does, how to use it. First thing to read, first thing you write when you share something.

Main

the official, current, everyone-trusts-it version. Like the final signed workpaper, versus your working drafts.

Star

bookmarking a project so you can find it again.

Watch

turning on notifications for a project so you know when it changes. (Following a person is different from watching a project.)

This is the part that matters most. The whole “improve someone's build” cycle is five words:

Fork

make your own copy of someone's project so you can tinker without touching their original.

Branch

a parallel workspace within a project for trying a change safely. (Fork = your own copy of the whole thing; branch = a side-lane inside one copy.)

Commit

save a snapshot of your change with a short memo explaining what you did. Think documented adjusting entry: the change plus the “why.”

Pull request (PR)

the big one. You saying: "here’s an improvement I made to your project, want to merge it in?" It’s how features get upgraded without anyone stepping on anyone.

Merge

accepting a pull request and folding the improvement into the main version.

The repeatable pattern: fork or branch, make your change, commit, open a pull request, someone reviews and merges. Understand that one sentence and you understand 80% of GitHub.

Review / approve

looking over someone's pull request before it gets merged. Your natural instinct as reviewers.

Merge conflict

two people changed the same line differently, so GitHub stops and asks you to reconcile it. Less scary than it sounds: it’s a "these two entries hit the same account, which is right?" moment.

Issue

a note attached to a project: a bug ("this breaks when…"), a request ("could it also do…"), or a to-do. Your shared running list per project.

Sync / pull

grabbing everyone else's latest changes so your copy isn't stale. The habit that prevents most conflicts.

These are a slightly different kind of term than the ones above. Fork, branch, and commit are literal GitHub buttons. Prod and dev describe where a running version lives, and deploying usually happens on whatever's actually powering the tool (in our stack, Cloudflare), not inside GitHub. Don't go hunting for a “deploy” button in GitHub; it isn't there.

Prod (production)

the live version real people are actually using. The return you filed; the tool a client relies on right now. You don't experiment here.

Dev (development)

the working version where you build and break things safely. The scratch copy, the draft workpaper. Nobody's depending on it, so you can try wild stuff and fix it before it goes live.

Staging

a dress-rehearsal copy set up to look exactly like prod, for final checks before going live. (Live / sandbox / dress rehearsal = prod / dev / staging.)

Environment

the umbrella word. "Prod environment" vs. "dev environment" just means the live setup vs. the sandbox.

Deploy

the act of pushing a version out so it’s actually running. "Deploy to prod" = make it live for everyone. It’s why people say "don’t deploy on a Friday": if it breaks, you’re fixing it over the weekend.

Ship

casual slang for "release it / make it live." "I shipped the update" = it’s out.

Rollback

undo a deploy and snap back to the last working version when something goes wrong. Your safety net.

The point of keeping prod and dev separate: you experiment in dev, and only push to prod once it works. It's a discipline you already have, you just call it “don't edit the original.”

Gist

a quick way to share a single snippet or prompt without making a whole project.

Push

sending your committed changes up to GitHub. (The counterpart to pull.)