In this post, I’m going to discuss how to create a GitHub repo and upload (or “push”) it to GitHub, a popular service for hosting Git repositories.
What is revision control and why do I need it?
The concept of revision control is a system which tracks changes to files. In programming, that is usually program code, but documents and text files can also be tracked. Using revision control will give the following benefits:
- You will know what was changed, when it was changed, and who changed it
- Multiple people can collaborate on a project without fear of overwriting each others’ changes.
- Protection against accidentally deleting a critical file. (revision history is usually read-only)
In GitHub, we store revisions in “repositories” or “repos” for short. As of this writing, the #1 service for storing Git repositories is GitHub. They offer free hosting for Git repositories.
Before you start
Make sure you have a copy of Git. If in doubt, go to the official Git website and download a copy.
Also, if you’re on OS/X or UNIX, make sure your editor is set to use nano. Vi/vim is rather intimidating for new users, while nano is much easier to get started with. Just type this on the command line:
export EDITOR=nano
If you want these changes to be persistent, they can go into $HOME/.profile, but that’s beyond the scope of this post.
Creating the Repo
Creating the repo is fairly straightforward–create a directory, change to it, and run “git init”:
$ mkdir git-101
$ cd git-101
$ git init
Initialized empty Git repository in /Users/doug/git-101/.git/
Checking In Our First File
Let’s create a file, and add it to the Git Staging Area:
$ echo "hello world" > hello.txt
$ git add hello.txt
$ git status
# On branch master
#
# Initial commit
#
# Changes to be committed:
# (use "git rm --cached <file>..." to unstage)
#
# new file: hello.txt
#
The file isn’t in the Git repository yet! Right now, the file is in the “staging area”. Decoupling the staging and the committing processes in Git is a powerful concept–it lets you structure your commits the way you want them, not the way the revision control software thinks they should be. It is in fact possible to remove a file from the staging area, or update it with a new copy of the staging area, all before the commit happens.
Sidenote: git status
I will be typing “git status” a lot in this post. Git status is probably the most frequent command you’ll use in Git. It tells you the current state of the git repository, including things such as:
- Files added to the staging area
- Files removed from the repo (listed in the staging area accordingly)
- Files which have been changed since the last commit
- Files which Git does not know about
- Files which have conflicts
Committing your changes
Now it’s time to commit our changes with the git commit command:
$ git commit
[master (root-commit) 57e6451] Added hello.txt
1 file changed, 1 insertion(+)
create mode 100644 hello.txt
What’s not shown is after I typed “git commit”, nano opened up and prompted me to write a comment for the commit. In Git, comments are mandatory for every commit and just plain good practice anyway, so I recommend writing meaningful comments for each commit.
I can now use git status to verify that no files are outstanding in Git:
$ git status
# On branch master
nothing to commit, working directory clean
I can also use git log to display the entire commit log, which at this point only contains one commit:
$ git log
commit 57e64510aa20c907a9c2b195fdf356a75a482d84
Author: Douglas Muth <dmuth@dmuth.org>
Date: Tue Nov 26 22:27:32 2013 -0500
Added hello.txt
Finally, there is git show, which shows the comment for the last commit, along with what was changed by that commit:
$ git show
commit 57e64510aa20c907a9c2b195fdf356a75a482d84
Author: Douglas Muth <dmuth@dmuth.org>
Date: Tue Nov 26 22:27:32 2013 -0500
Added hello.txt
diff --git a/hello.txt b/hello.txt
new file mode 100644
index 0000000..3b18e51
--- /dev/null
+++ b/hello.txt
@@ -0,0 +1 @@
+hello world
Creating a repo on GitHub
Now I need to share my amazing repository with the rest of the Internet. To do that, I’ll need to create a repository on GitHub and push my changes there. Since the look and feel of GitHub can change (as it would for any web app), I won’t cover how to create a repo in GitHub here. (There is great documentation on GitHub’s website..)
Once your repository is created, you’ll need to push your changes to it. First, create a remote:
$ git remote add origin git@github.com:dmuth/git-101.git
$ git remote -v
origin git@github.com:dmuth/git-101.git (fetch)
origin git@github.com:dmuth/git-101.git (push)
There’s two important concepts in the above commands. The first is a concept of a remote. In Git, remotes are pointers to git repositories on other parts of the same system or (as in the example above) on different systems entirely. Once a remote is set, you no longer have to worry about typing in the complete URL every time you push or pull from a repo. And as a matter of convention, the remote origin is used by default if no remote is specified in a push or pull operation.
After your remote is set, push your changes up:
$ git push -u origin master
Counting objects: 3, done.
Writing objects: 100% (3/3), 225 bytes, done.
Total 3 (delta 0), reused 0 (delta 0)
To git@github.com:dmuth/git-101.git
* [new branch] master -> master
Branch master set up to track remote branch master from origin.
Congratulations, your changes have been pushed to GitHub. Upon going to the project change (https://github.com/dmuth/git-101 for this one…), you’ll see your changes reflected there.
If you enjoyed this post, you might want to see my related post: Git 101: How to Handle Merge Conflicts.
For Further Reading
If you’d like to learn more about Git, the website GitReady is an excellent resource for learning all of the different features that Git has to offer.
Enjoy!