Vocabulary in context

The repo

The single most important noun in software. A repo (short for repository) is a folder of code under version control. It tracks every file, every change, every author. It lives on your laptop and is mirrored on a host (GitHub, GitLab, Bitbucket).

Why it matters: a repo is the source of truth. Not the file you happened to email yesterday. Not the version on Steve's laptop. The repo. When someone says "what's in main?" they mean "what's the canonical state on the default branch in the repo right now?"

Branches and commits

Two atoms of version control. A commit is a saved snapshot of changes with a message describing what changed. A branch is an independent line of work — a series of commits that diverges from another branch.

The pattern: you cut a branch off main, do some work (a commit, two commits, ten commits), and when it's ready you merge it back. While you're working, main stays untouched. Other people are doing the same thing on their own branches. Branches are cheap to create and cheap to throw away — that cheapness is the whole point.

BASHCopy
$ git checkout -b feat/inbox        # cut a new branch
$ # ... edit some files ...
$ git add .                          # stage what you changed
$ git commit -m "Add inbox view"     # commit with a message
$ git push origin feat/inbox         # send it up to GitHub

Pull requests — the dance of code review

You don't push directly to main. You push your branch and open a pull request (PR) — a proposal to merge it. The PR is where review happens: comments on specific lines, requested changes, approvals, automated checks.

Once the PR is approved and the checks are green, you merge it. The branch typically gets deleted. The change becomes part of main and (often) gets deployed automatically.

This sounds bureaucratic. It is. It exists because a single bad merge into main can take down a production site, leak secrets, corrupt data. The friction is the safety net.

Your tools — IDE, terminal, CLI

An IDE (Integrated Development Environment) is the editor you write code in, plus everything around it: file tree, terminal, debugger, git, search. VS Code is the dominant one. Cursor and Windsurf are AI-first IDEs built on top of VS Code's foundations.

The terminal is the text interface for typing commands at the operating system. Engineers spend a surprising amount of time here — sometimes more than in the editor itself. Same thing as "the command line" or "the shell."

A CLI (Command-Line Interface) is any tool you drive by typing. Git is a CLI. npm is a CLI. AWS, Stripe, Vercel, Cloudflare — they all have CLIs. Production tools usually have one because clicking through a UI doesn't scale.

Packages and dependencies

Almost no software is written from scratch. You assemble it from packages — reusable bundles of code published to a registry (npm for JavaScript, PyPI for Python, RubyGems for Ruby) that you install into your project.

The packages your project uses are its dependencies. They're listed in a manifest file: package.json for Node projects, requirements.txt or pyproject.toml for Python.

package.json (excerpt)Copy
{
  "name": "tasklane",
  "version": "0.1.0",
  "scripts": {
    "dev": "next dev",
    "build": "next build",
    "start": "next start"
  },
  "dependencies": {
    "next": "^14.2.0",
    "react": "^18.3.0",
    "@prisma/client": "^5.16.0"
  },
  "devDependencies": {
    "typescript": "^5.4.0",
    "tailwindcss": "^3.4.0"
  }
}

Two things to notice. First, scripts defines commands you can run with npm run <name>. npm run dev starts the dev server. Second, dependencies are needed at runtime; devDependencies are needed only while you're developing. Same idea, different lifecycle.

Framework vs. library

Two words used loosely, often interchangeably, but with a real distinction worth holding:

Library

You're in charge. You reach in and call its functions when you need them. React is a library — you import it, you use it where you choose.

Framework

It's in charge. You fill in pieces it'll invoke. Next.js is a framework — it dictates the file structure, the routing, the build process; you write code in the slots it provides.

The line is fuzzy. The useful intuition: a framework opinionates more, asks more of you up front, gives more out of the box. A library is à la carte.

Environments — dev, staging, production

The same code runs in different places. Each place is an environment:

Development (local)

Your laptop. Where you write and test changes. Connects to a local database or a dev-only one.

Staging

Mirrors production but isn't customer-facing. Where you smoke-test before going live. Sometimes called "preview" or "QA."

Production

The live environment users actually hit. Sacred. Breaking it has consequences. Often shortened to "prod."

Each environment has its own database, its own secrets, its own URL. The same code, the same logic — but pointing at different data and different keys.

Product vocabulary — the acronyms

You'll hear these in roadmap meetings, in PRDs, in pitch decks, on Twitter. Knowing what each means lets you read the room:

Repo shapes — monorepo vs. multiple repos

Two structures you'll meet:

Polyrepo (multiple repos)

One repo per project: frontend repo, backend repo, marketing-site repo. Clean boundaries, but cross-cutting changes touch many repos.

Monorepo (one repo)

Everything in one repo, in subfolders. Easier to refactor across boundaries. Tools like Turborepo and Nx exist to manage them. The choice has trade-offs that take experience to feel.

For a solo project or a small team, a single repo is almost always right. Monorepo or polyrepo as a question only matters once you have several projects that depend on each other.

Wrap-up