Your machine

Getting a Unix shell, a package manager, Git and an editor working, and the words for the parts you are using.

Terminal, iTerm2 and zsh on macOS

Also called zsh, iTerm2

What: macOS ships Terminal; iTerm2 is a popular free alternative. The default shell is zsh, which runs nearly all Bash commands the same way. The built-in tools are BSD versions, not the GNU versions found on Linux.
Why: Knowing about BSD tools explains why some flags from Linux tutorials fail, such as sed -i needing an extra argument.

Watch out

Writing scripts in zsh-only syntax and then running them with Bash on a Linux server.

Xcode Command Line Tools

Also called Xcode, xcode-select

What: Apple's compilers, git, make and related developer tools, installed without the full Xcode app by running xcode-select --install.
Why: Homebrew and many packages compile code during installation and fail without them.

Watch out

Forgetting that a major macOS upgrade can break them; reinstall them first when git or builds suddenly fail.

Homebrew

Also called brew

What: The package manager for macOS (it also runs on Linux). It installs under /opt/homebrew on Apple silicon and /usr/local on Intel Macs.
Why: One source for command-line tools and many apps, which you can update, list and remove cleanly.

Shell

brew update && brew upgrade
brew install git jq tree gh
brew install --cask visual-studio-code
brew list
brew doctor

Watch out

Skipping the installer's final step that adds brew to your PATH, then getting "command not found".

Terminal, shell and prompt

Also called Bash, command line, CLI, shell, prompt

What: The terminal is the window. The shell, such as Bash or zsh, reads your commands, expands patterns and runs programs. The prompt is the text the shell prints while waiting, often showing user, host and folder.
Why: Knowing which is which tells you where a problem lives: a display issue is the terminal, a "command not found" is the shell and PATH.
Example: In ls -la ~/code, ls is the program, -la are options and ~/code is an argument.

Watch out

Copying the $ prompt sign from a tutorial along with the command.

System package manager

Also called package manager, apt, dnf, pacman, brew

What: The tool that installs, updates and removes software from trusted repositories: apt on Ubuntu and Debian, dnf on Fedora, pacman on Arch and Homebrew on macOS.
Why: Installing through it keeps every tool updatable and removable, and avoids random installers from download pages.

Shell

brew update && brew upgrade
brew install git jq tree
brew search ripgrep
brew uninstall tree

Watch out

Installing without updating the package list first and getting "unable to locate package".

man, --help and tldr

Also called manual page, man page

What: man cmd opens the full manual (search with /, quit with q), cmd --help prints a summary, and tldr cmd shows short practical examples.
Why: Looking things up in the terminal is faster than searching the web and is always right for the version you have installed.

Watch out

Running a pasted command you have not looked up, especially one with sudo, rm or a pipe into a shell.

Git configuration

Also called git config, .gitconfig

What: Settings stored in ~/.gitconfig for all repositories, or .git/config for one. Name and email are required before committing.
Why: The email links your commits to your GitHub profile, and sensible defaults save typing and surprises.

Shell

git config --global user.name "Sara Khan"
git config --global user.email "sara@example.com"
git config --global init.defaultBranch main
git config --global core.editor "code --wait"
git config --global pull.rebase false
git config --list --show-origin

Watch out

On Windows, configuring Git only on the Windows side while you commit from WSL, which has its own config.

VS Code and the code command

Also called VS Code, Visual Studio Code, code command, code ., Remote - WSL, Remote - SSH

What: Visual Studio Code is a free editor. The code command opens files and folders from the terminal; the WSL and Remote SSH extensions run VS Code's server where the files live.
Why: Opening projects from the terminal keeps you in the right folder, and remote extensions let you edit WSL or server files as if they were local.

Shell

# Command palette: Shell Command: Install 'code' in PATH
code .
code --wait msg.txt

Watch out

On Windows, opening a WSL project through a \\wsl$ path in plain VS Code instead of the WSL extension.

Go deeper