The Terminal, Gently

Git is a program you talk to by typing, so before Git you need the place where typing happens. If you have never opened a terminal, this is the page that makes the rest of the book possible.

A terminal is a window where you type the name of a program and press Enter, and the program runs. That is the entire idea. Films have given it a reputation it does not deserve: nothing here is dangerous, and nothing you type in this book can damage anything outside the folder you are standing in.

Think of it as a file manager where you type the destination instead of clicking it. Same folders, same files, different steering wheel — and once you can steer, you can drive anything.

Opening it

On macOS, open the Terminal app (Spotlight, then type "terminal"). On Windows, the Git installer in the next topic brings Git Bash, which is the one to use for this book; Windows Terminal and PowerShell also work. On Linux you already know where yours is.

What appears is a mostly empty window with a line of text and a blinking cursor. That line is the prompt: the terminal saying it is ready and waiting.

Where am I?

Here is the fact that makes everything else make sense: a terminal is always sitting inside one folder. Commands act on that folder unless you say otherwise. When Chapter 2 tells Git to start tracking a project, what it really does is act on wherever you happen to be standing.

The command that tells you where that is:

pwd

It answers with a path, something like /Users/you/projects/sandpiper. The name is short for "print working directory", and you will type it more often than you expect — usually about four seconds after wondering why a command did not do what you meant.

Looking and moving

Three more commands and you can navigate anywhere. ls lists what is in the current folder. cd followed by a folder name steps into it. cd .. — with two dots — steps back out to the folder above.

ls
cd sandpiper
ls

One habit worth building immediately: press the Tab key after typing the first few letters of a name and the terminal completes it for you. It is the difference between comfort and a long afternoon of typos, and it also confirms the thing you are typing actually exists.

The shape of a command

Every command in this book has the shape in that diagram: the program, then which job you want it to do, then options that adjust the job, then whatever the job needs. git commit -m "Fix the meeting time" is four parts, not one incantation, and once you see the parts you can read commands you have never met.

Two small rules save a lot of pain. Anything containing a space goes inside quotes, or the terminal treats each word as a separate item. And the terminal is fussy about spelling in a way that people are not: Sandpiper and sandpiper may well be different names.

Reading an error instead of fearing it

Errors are how these programs talk. Here is one on purpose:

cd sandpper
cd: no such file or directory: sandpper

Read it as a sentence. The command was cd. The problem is "no such file or directory". The thing it could not find is sandpper, which is missing an i. Nothing is broken, nothing was changed, and the message contains the whole diagnosis.

The exact wording depends on which shell you are using, and the same three parts are always in it. On Windows, Git Bash puts them in a different order:

cd sandpper
bash: cd: sandpper: No such file or directory

Command, then the name it could not find, then the problem. Different order, same three pieces of information. Getting used to picking those pieces out of any error message is worth more than memorising one shell's phrasing.

That is the pattern for the rest of the book. Error messages from Git are longer, but they are built the same way, and the last line is almost always the useful one. Git very often prints the exact command it thinks you want next.

Silence means it worked

One last surprise. Most of these commands say nothing at all when they succeed. Run cd sandpiper correctly and the terminal simply gives you a fresh prompt. That is not a failure and it is not the terminal ignoring you — silence is the good outcome, and text is usually either an answer or a problem.