Introduction to the Terminal
Ok since we are all doing this on the terminal and may not all be familiar with what that is, I thought I’d do a brief overview of enough of the terminal such that you can use Git.
I will say it’s a generally pretty important skill to pick up though and can recommend further resources for working with the terminal if folks want. The grammar of a shell allows you to combine existing tools into powerful pipelines and handle large volumes of data automatically. Sequences of commands can be written into a script (including from within Python scripts!), improving the reproducibility of workflows.
I wanted to make sure that you all knew the difference between “the shell”, “terminal”, and “command line” as well:
- Terminal: text input/output environment
- Command line: interface where user types a command
These two are used pretty synonymously nowadays, but have some subtle historical differences that don’t matter for our purposes but are generally interesting from a ‘history of computing’ standpoint. I’m gonna use them synonymously for today, in any event.
- Shell: command-line interpreter that allows users to interact with the system on a low level
Today are going to be using the Bourne Again SHell — so-called because it’s derived from a shell written by Stephen Bourne — used in macOS and Linux (Unix-based systems), and available via some programs in Windows (like the “Git Bash” program for our Windows users here!). This is shortened to BASH and that’s what I’ll be saying throughout the workshop.
Everyone please open a terminal window! As a reminder:
- On macOS, search for “terminal” in spotlight search. You should see it come up immediately. Click it to launch.
- On Windows, you will be using the Git Bash for this workshop, which comes with an installation of Git. So Windows folks: after you install Git, search for “Git Bash” in the start menu.
- On Linux, search for “console” in your search. You should see it come up immediately. Click it to launch.
When the shell is first opened, you are presented with a prompt, indicating that the shell is waiting for input. It usually uses a
$ as the prompt but might use something else depending on your system.
Let’s first get an idea of where we are in the system by listing out the contents of whatever directory we’re in right now:
$ ls -F
You might see folders like
Photos, or specific files like
vickyIsGreat.txt. You might see NOTHING or if you’re on Windows, you might be really weirdly nested in a series of folders you didn’t even know existed (this happens with the Git Bash, because paths are hard?). The
ls command prints the names of the files and directories in the current directory.
You might have noticed that I put the
ls. This is what’s known as a flag – an option that we can pass to the command that lets us do additional work that is useful. The
-F here basically adds markers to the output of
ls – so it does things like put a
/ to indicate a directory, or
* to indicate an executable.
Let’s add what’s called an parameter to our
ls command now. These change the behavior of our command. A command can be called with more than one option and more than one argument but doesn’t always require either.
$ ls -s ~/Downloads
-S will sort the files and directories by size. If you want to see all the options available for
ls, you can by adding the
ls --help. I assume that I can pretty much add
--help to any command and have it give back the help page, and it’s probably a good assumption for you to make too. The shell interprets the
~ character to mean “the current user’s home directory” and only works if it’s the first character in the path, it’s a very helpful shortcut IME.
We’ll see some more flags and options with Git, so if you don’t get the concept, please say something now and I will explain it again.
Configure Git with the Terminal
Before being able to use Git at all on your computer for fun stuff, you first need to configure Git with your name and email address. In a project, everyone needs to see what exactly other collaborators have been doing. In a version control system like Git, this is done through minimum two commands run in the Terminal.
In your terminal window, type:
$ git config --global user.name 'Your Name'
And substitute ‘Your Name’ for your given name and your family name. Hit enter when after you’ve typed the full line. Nothing should output, that’s fine. Next, type the following:
$ git config --global user.email 'firstname.lastname@example.org'
email@example.com with your email address, preferably the one you use with your GitHub account (so your commits are verified). Nothing should output after this, that’s fine. Next, we’ll need to tell Git which text editor we favor in case we ever need to deal with merge conflicts.
$ git config --global core.editor "vim"
Substituting ‘vim’ for your favorite plain text editor. This could be simply Notepad (Windows) or TextWrangler (Mac), but NOT Microsoft Word, LibreOffice Writer, or other rich text editors. We need it to be as plain as can be!
And one more thing before we stop configuring Git is to set it so that our local program, Git, has our main branch named the same as in GitHub, literally “main”. We do that with this:
$ git config --global init.defaultBranch main
At any point in the process, you can double check everything you’ve just put in with:
$ git config --list
This should output something like this:
vicky@cagliostro:~$ git config --list user.name=Vicky Steeves firstname.lastname@example.org core.editor=vim init.defaultbranch=main
Sometimes Windows and macOS add in their own configurations, so if your list is longer than this, don’t worry about it. Click the green ✅ if you have configured Git or the red ❌ if you need help (and feel free to chat each other to help one another!) .
Always remember that if you forget a
git command at any point, you can access the list of commands by using
-h flag and access the Git manual by using
$ git -h $ git --help
If there is a wall of text and you get panicky, just hit
Q and it will quit out of the manual!