Every developer tool you'll ever use speaks the same language. Learn the grammar once and you can read any command ever written.
You'll hear these three terms thrown around interchangeably, but they're slightly different things:
The window on your screen. It's just the display — like a TV. Also called a terminal emulator because it simulates the hardware terminals of the 70s. iTerm2, Windows Terminal, Hyper — all terminals.
The program running inside that terminal. It reads what you type and actually runs things. bash, zsh, fish, and PowerShell are all shells.
The line where you type — and loosely, the whole text-based way of controlling a computer. "CLI" means Command Line Interface. As opposed to a GUI (Graphical User Interface — buttons, windows, mice).
$ or >). It means "I'm ready, type something." Everything after it is what you type.
Almost every CLI command you'll ever run follows the exact same structure. Learn this and you can read — and guess — commands you've never seen before.
Everything is separated by spaces. The order matters: command first, then subcommand, then the rest (usually). That's the whole syntax.
One thing you'll notice immediately: flags sometimes start with one dash (-m) and sometimes two (--message). The rule is simple: one dash = shorthand, one letter. Two dashes = full word. They're the same flag, just two ways to write it. The short version is faster to type; the long version is easier to read at a glance — especially in scripts that other people have to understand later. Most flags offer both.
Modern CLI tools are organized like a toolbox with compartments. You have one top-level command — the tool's name — and inside it live all the specific actions as subcommands. You'll also hear them called verbs or just sub-commands.
git is the namespace; the subcommands are the verbs.
This pattern is everywhere — it's basically an industry standard for any serious tool:
Notice that git pull and docker pull both use pull. Different tools, same verb. CLI designers try to use conventional, intuitive words so you can guess subcommands before you even look them up.
The rule for spotting a flag: it starts with a dash. That's it. One dash or two — here's the difference:
Single dash + single letter. Fast to type. Often called a short option. You can usually chain several together: -abc means -a -b -c.
Double dash + full word. Self-documenting — anyone reading your command knows exactly what it means. Preferred in scripts and documentation.
Most flags have both forms — they're identical. -m and --message in git do the exact same thing. Short is for speed, long is for clarity.
--message needs a value after it (the message text). But --verbose is a pure on/off switch — you either include it or you don't. The second kind is often called a boolean flag or a switch.
-- (double dash alone) is a convention meaning "everything after this is an argument, not a flag." Mostly used to avoid ambiguity. You'll see it occasionally — just know what it is.An argument (also called a positional argument) is a plain value — no dashes — that tells the command what to work with. A filename, a URL, a branch name, a number. It's called positional because the order you write them in matters.
Flags modify how. Arguments say what. Together they give the command everything it needs.
Git is the version control system almost every developer uses. It's also a textbook example of CLI design — clean subcommands, consistent flags, and good defaults. Let's decode the most common commands:
. is an argument meaning "everything in this folder." Stage all changed files.-m is short for --message. The text in quotes is the value for that flag.-u (set upstream) only needed the first time. origin = the remote's nickname, main = the branch.Every well-built CLI tool documents itself. You never need to Google a flag if you know these:
--help after any subcommand to get help specifically for that action.man is a command itself — short for "manual." It opens the full documentation. Press q to quit. Not on Windows by default, but universal on Mac/Linux.A well-formatted help output always shows the same things:
Read the usage line like this: square brackets [like this] = optional. Angle brackets <like this> = required value goes here. Ellipsis ... = you can repeat it.
These ~10 commands cover 90% of daily git usage. Everything else is edge cases.
git) is the subject. The subcommand (commit) is the verb. The argument (filename) is the object. The flags (--message) are the adverbs. Read it like English, left to right.