Now that we’re all set up with a GitHub repository, we need to be able to access it on our computer. We’re going to do three things in this tutorial. Clone the repo, make some changes, and push our changes to GitHub.
I’m doing this all in the OSX terminal, but the commands are identical in the Windows Command Prompt. It’s just that my OSX setup’s a little more visually appealing, with various exotic colors such as blue, red, and slightly different blue.
So hop into your terminal or command prompt, and create the directory in which you want your musiclist project to live. In my case that’s in my home directory, under a directory called web, with a directory name of musiclist. So I’m doing this:
mkdir -p ~/web/musiclist
Now we need to set up our directory to talk to GitHub. For that, we need the GitHub URL from which to clone the repository. You can find this by going to the top level page of the repository you created in GitHub, and clicking the green “Clone or Download” button in the upper right. Copy the URL and then switch back to your terminal.
Change directories to
~/web/ or wherever you’re storing your musiclist folder. Then type the following:
git clone [paste your URL here] musiclist
This will clone the repository at the URL you copy-pasted into the musiclist folder. Note that if you put anything in /musiclist at all, even a text file, git will complain about the directory not being empty and refuse to clone into it without additional command line options, so … don’t do that.
Hit enter, watch it clone, and then CD to musiclist. Now if you list the contents of the directory, you’ll see three things. A .git folder, the README.md file, and the .gitignore file. Don’t screw with that .git directory, because it’s what identifies this folder as a git repo and allows you to talk back and forth with GitHub (also it can badly mess up your version control, and trust me, I’m speaking from experience when I say that trying to untangle a messed-up repo is like being repeatedly kicked by a psychotic robot made out of steel and … lightning).
(now imagine it was strangling you with that …)
Let’s add a file. Specifically, let’s add a file called test.html – we’ll be removing this eventually, but it’ll work for now. Create the file by typing:
And then, if you followed our Sublime Text installation tutorial, you can type:
and it’ll open Sublime Text with that file in a tab. Let’s just put some quick html in here:
<html> <head> <title>Testing!</title> </head> <body> <h1>This is a Test</h1> <p> We just need something to commit to the GitHub repo. </p> </body> </html>
Woo! All right. That’s a web page worth keeping in a repository. Save that file, and switch back to your terminal. Real quick, open up the README.md with
And just add some text. I’ll go with:
This is a change to an existing file.
Save it, and switch to your terminal again. Now Let’s learn some git commands. We’re going to start with this one:
What that does is tell you the status of your repository. You’ll see that it’s showing you’ve changed one file, and added a new one. This is a really handy command once you get into significant development, since you can quickly get a sense for what files you’ve touched. It also allows you to commit only the files you want at any given time.
So, right, committing. Committing is not pushing code to your repository. It’s saving a snapshot of code on your local machine, which can then be pushed to your repo at your leisure. I very often commit several times before pushing up to GitHub, because it can be useful to save groups of files in bite-sized pieces, but there’s no real reason to push each of those pieces individually.
A good way to think of it is like shipping a package. Adding files is putting items into the box but leaving it untaped. You can easily remove items, add different items, etc. Committing is taping up the box. While it’s possible still to undo it, it’s a bigger project and something you’re less likely to need or want to do. Pushing your commits is like taking a bunch of taped boxes to Fedex and sending them to someone. It’s not a perfect analogy, but it’s close.
Anyway, let’s commit these changes. The first thing we need to do is “add” them, which we could individually by typing:
git add README.md git add test.html
… but that’s pretty annoying. So let’s do this instead:
git add -A
This means “add everything” and it’s useful when you have lots of changes, especially in files that are in subdirectories, which makes typing them all out a real pain. If we do
again, we'll see that these files are now ready to be committed. To do that, we type
git commit -m "first change"
-m lets us add a message to the commit. I try to go with useful message such as “adding an about page and styling it up.” Also cool: you can reference GitHub issue numbers and other GitHub data here, by typing something like “fixes issue #9 by keeping the user logged in on static pages” and the commit will be referenced on that issue’s page. Nice!
Once you’ve committed changes, you can push them to the GitHub repo whenever you want. Since this is the only set of changes we’re doing in this tutorial, let’s push them with:
Great. We’ve pushed those files to the master branch of our repository, and if you go and refresh the repo’s page on GitHub, you’ll see that our new file is there, and our README.md’s been updated.
You could make an art out of mastering GitHub, and I’m not going to be able to cover it entirely, but we’ll tackle a few more subjects in later videos. For now, it’s time to get our webserver installed. See you in the next episode: setting up Express.
Image copyright: videodoctor / 123RF Stock Photo