Most people learn quickly why they need version control. Of the many version control systems out there, Git is one of the most popular.
Before you go any further, read Chapter 1 of the Git Book to learn about version control in general, a little bit of Git’s history, how to install and set up Git, what Git can do, and where to get help. Jumping right in without some of this background may lead to frustration down the road.
About these notes
Please understand these notes are only introductory, and that you need to know about, and use, the official git documentation. Please be aware of, and browse:
Again, read Chapter 1 of the book now. Maybe watch some of the videos too.
- The Git Home Page
- The Git Documentation Page. This page has links to a reference manual, an absolutely wonderful free online book, cheat sheets, and training videos.
Let’s get this distinction out of the way right now:
GitHub is the most popular of the cloud services, so you’ll want to “have a GitHub” even if you also use the other services. Sign up for an account if you don’t already have one. Log in and stay logged in.
OPTIONAL: Go to your
Settings and set up SSH access. Don’t know what that is? That’s fine; you can always do that later.
Let’s get set up with Git. After this exercise, you will be able to work with git on your own desktop or laptop.
gitis installed on your machine.
gitcommand from your native Windows Terminal.
gitin your terminal to see if it is already there or not. You should know by the output whether the program was successfully installed or not. If it was not, or you are not sure, ask the instructor or a TA for help.
$ git config --global user.name "Jane Doe" $ git config --global user.email "email@example.com" $ git config --global color.ui auto $ git config --global init.defaultBranch main
$ git config --global --list
Pay attention here
Chances are high that using the wrong way in the wrong context will lead to frustration, and the needed to blow away your project and start over.
You will either:
git initin it.
You need to do things the second way when using tools like
create-react-app, because they create new folders and populate them with a bunch of starter files.
Do not use
We’ll start with a little in-class exercise. After this exercise, you’ll have a GitHub account, and a single repository.
$ cd ~ $ mkdir my-projects $ cd my-projects
$ git clone <the link you copied>
$ cd story $ ls LICENSE README.md
git clone. It is now time for the one you will use most often:
$ git status On branch main Your branch is up to date with 'origin/main'. nothing to commit, working tree cleanTyping
git statusis something you will do again and again and again and again. But wait...doesn’t that output look scary? main? branch? origin? working tree? commit? Lots of technical stuff there, it seems. There is much to learn, but take heart for now: the phrases “up to date” and “nothing to commit” means we’re in a good place.
the way to go
If you created your workspace manually (without cloning), or
create-react-app made you a workspace, then great! You’ve come to the right place. Here’s a little exercise you can do to work through the process.
$ cd ~ $ mkdir web-projects $ cd web-projects $ npx create-react-app counter $ cd counter
$git remote add origin firstname.lastname@example.org:•••••/counter.git $git push -u origin main
The rest of these notes pick up the Story example above. If you did the little exercise in this section with create-react-app and you wish to follow along, you might want to go back and create the story repo. Or simply just read on.
It was a dark and stormy night.You can change it later, of course. Save the file. Now do
$ git status On branch main Your branch is up to date with 'origin/main'. Untracked files: (use "git addSo, we have an untracked file. Not all files in your workspace will need to be tracked by git; but for those that you want to track, you have to add them:
..." to include in what will be committed) story.txt nothing added to commit but untracked files present (use "git add" to track)
$ git add story.txt $ git status On branch main Your branch is up to date with 'origin/main'. Changes to be committed: (use "git reset HEADGreat, so we’ve added the file and git tells us two things: (1) that it is a change ready to commit, and (2) that if we want to unstage it, we can. So it sounds like what we’ve added it to is called the stage. Cool! Also, that as soon as we are happy with our changes, we can commit them.
..." to unstage) new file: story.txt
$ git commit -m 'Write first line of file' [main d484c4c] Write first line of file 1 file changed, 1 insertion(+) create mode 100644 story.txtYour response message will differ. In the response above, the value d484c4c is a unique identifier for the commit. You’ll hear people call it a hash. The point is, in git, every commit has a unique identifier. What does our status look like now?
$ git status On branch main Your branch is ahead of 'origin/main' by 1 commit. (use "git push" to publish your local commits) nothing to commit, working tree cleanWe have no uncommitted changes in our local workspace, but it appears that we’ve committed to a “local” place which is one commit ahead of something called origin/main. So pushing will publish the local commit. Let’s do it:
$ git push Enumerating objects: 4, done. Counting objects: 100% (4/4), done. Delta compression using up to 8 threads Compressing objects: 100% (3/3), done. Writing objects: 100% (3/3), 362 bytes | 362.00 KiB/s, done. Total 3 (delta 0), reused 0 (delta 0) To https://github.com/rtoal/story.git 448ddcd..d484c4c main -> mainOkay, lots of technical stuff there, but we didn’t get any errors! And if you do a
git statusnow, you’ll see everything looks good.
We saw so many new terms in that little exercise, and now we are ready to actually learn what they all mean. We’ll be using this picture:
So far we’ve seen the commands
push. We know the workspace is where we edit files on our local machine; the stage is where we hold the files we want to commit; our local repository is where we make commits on our local machine.
Real projects are worked on by many people. They each may make commits to their local repositories. At some point they will push the commits form their local repos to a shared remote repository. To get other people’s commits, you will pull them from a remote.
While true, what you just read barely scratches the surface of what is possible. For one thing, there is no notion of branches here. Remember how git was reporting something about “the branch main? We haven’t covered that yet.
The diagram shows that we can compare the contents of the files in our workspace with those in the stage and those in the local repository. This is a great thing to do frequently as you try to remember what you did recently—especially when you need to make some commits and you need to write an accurate commit message.
Finally, note that the diagram has a couple commands for blowing away your workspace. Only do this if the current code you are working on is a total mess. In reality, you probably won’t need to do this, because you’ll at some point learn about branches.
That might have been an overview of less than 1% of what Git can do, but it’s enough for trivial projects. What should you do next? Maybe continue reading the rest of the Git Book.
Wait wait there’s more!
You’ll definitely benefit from reading the Git Book and getting a lot of practice. Once you start getting the hang of things, cheat sheets become really useful. Here are a bunch. Some might be old, but the more you read, the better.
Here are a couple slide shows. The first is by Marco Berardini, which he created for the LMU Startup Class a few years ago:
This one is really old, from 2013. You might notices it references the
checkout command. At some point this overused command was split into