Git is a distributed version control system (DVCS) used for software development. What does that mean? Fundamentally, Git tracks changes made to code by identifying changes with a alphanumerical ID. Each new version of code has a unique ID, so changes can be identified throughout the entire development process. This is particularly useful when multiple developers are working on a single project; they can collaborate on pieces of code and know who made what changes. But it’s also great if you are working on a personal project on your local computer and need to manage the versions of code that you develop.
The fact that Git is ‘distributed’ makes all of this possible. Whereas some VCS’s require all developers to log into a central server, Git users can make independent changes and later, Git will take care of figuring out what changes conflict and merge the code. So how can you use this powerful tool for yourself? Well it’s quite easy to set up. Just follow these steps.
NOTE: If you only plan on using Git locally, look out for points in this tutorial that you can skip.
Getting Started – GitHub and SSH keys
I’m assuming you’ve already downloaded and installed Git for your computer. If not, go ahead and do that.
NOTE: Skip the next couple of steps if you only want to work locally.
Then go to GitHub and create a new user account. I would advise you use an email address already associated with your professional life – this will help others find your work more easily. GitHub is just a web hosted interface for managing your git repositories. Don’t worry about what that means, we’ll go over it later.
Then generate public SSH keys for your computer. SSH keys are just a secure way for your computer to talk to GitHub without asking you for a password every single time you want to make changes to a project. GitHub already has great tutorial on doing this, so just follow it step by step.
Create a local repository
Now you’re ready to create a repository, or ‘repo’, on your computer. A repository is just a data structure that Git uses to track changes made to your code. Think of it as a storage space for your project. For now, we’ll create a repository in our home directory. If you open ‘Terminal’, by default you should already be in your home directory. But let’s just make sure by typing the following.
$ cd ~
Then we’ll make a directory to test practice in and then move into it.
$ mkdir practice $ cd practice
Now comes the fun part. We’ll initialize a Git repository. We just initialize a git repository using
git init. This step will create a hidden subdirectory in your directory called ‘.git’. This directory is in charge of keeping track of all of the logs and ‘commits’ (or changes) that you’ve made while working.
Since the purpose of Git is to track changes made in a repository, we should make some changes. A common first change is to create a Readme file with the text ‘Hello World’. Finally, we’ll check the status of our repository. You’ll notice that the output from
git status tells us that our Readme is currently untracked. Now, what we’re going to do is ‘stage’ the files and then ‘commit’ them so Git tracks them.
$ git init Initialized empty Git repository in /Users/tim/practice/.git/ $ echo 'Hello World' > Readme $ git status On branch master Initial commit Untracked files: (use "git add ..." to include in what will be committed) Readme nothing added to commit but untracked files present (use "git add" to track)
On more thing, when you run
git status , you might notice that the output tells us that we’re on ‘branch master’. We’ll cover branching in a later post, but just keep in mind that initializing a Git repository automatically puts you on the master branch.
Modify > Stage > Commit > Repeat…
After making some changes, you need to ‘commit’ the change that you make. In a sense, every commit you make is a snapshot of the new things you have added/modified in your project. So, the Git workflow is to (1) modify your files, (2) stage (prepare) them, and (3) commit the files to Git.
The two-step process to commit changes (stage > commit) is an important feature. It allows you to clearly identify and choose which files are tracked. So perhaps you’re working on two different files and you feel confident that you’re finished working on one of them, but the other needs more revision. Well, in Git, you can stage just the finished file and commit it and continue working on the other. This is the easy part!
$ git add Readme $ git commit -m 'Added Readme' $ git status [master (root-commit) eb89f56] Added Readme 1 file changed, 1 insertion(+) create mode 100644 Readme
See? All we had to do was add the modified file to the staging area and then commit it. The
-m allows us to add a message so we can keep track of exactly what we did with each commit. If you forget to add this, terminal will ask you to add a message manually.
Publishing your repository to a remote
NOTE: Skip this whole section if you only want to work locally.
Now, we’re going to publish your local repository to a remote one on GitHub. Log in to your account, and on the to right corner, click the + and create a new repository. You can name it whatever you want, but it’s best practice to keep the same name as your local repository to avoid confusion. So we’ll call it ‘practice,’ give it a brief description, and make sure it’s Public. Whatever you do, DON’T initialize the repository with a Readme. Remember, we already have our own! On the next page, select the SSH button and then click the clipboard icon to copy the link.
Finally, we’ll push your local commit to the remote repository. First, we’ll try to connect to the GitHub servers using your SSH keys, which you should have already set up. The next step is a bit more complicated.
git remote add origin URL adds a remote repository for your local one to communicate with. The convention is to name this remote ‘origin.’ This will not rename your ‘practice’ repository in GitHub to ‘origin,’ but it’s just the way your local repository keeps track of the remote. So if that’s confusing, let me repeat – you called the remote repository ‘practice’ in GitHub, but your computer needs a name for it as well and the convention is ‘origin.’ Finally, make sure to paste the URL that you copied from GitHub, which is the path for the remote repository that Git is adding.
Now that we’ve added a remote, we can push our local commits to the remote. Essentially, this means that our remote repository is a synchronized copy of our local one. Remember how I talked about the power of distributed revision control? This is the crux piece of that system – now your collaborators can visit your GitHub page and see the changes you’ve made to a project.
The last step of this process is to
git push -u origin master. This tells our computer to push all the commits that we made locally onto our remote repository.
-u tells the computer to automatically synchronize our local repository with our remote repository so the next time we
git push, we don’t have to specify that the changes are going to origin master. ‘origin master’ is simply the master branch of the origin repository. Remember we have a local master branch? Well origin master is just the remote copy of our master branch.
See…it’s all making sense, right? Your local and remote repositories are just copies of each other. Your local has a master branch, so your remote should too. And while you see your remote called ‘practice’ on GitHub, your computer internally calls it ‘origin’. Anytime you want to update the changes you made on your local repository, you just have to
git push them to the remote.
$ ssh -T email@example.com Hi timsjpark! You've successfully authenticated, but GitHub does not provide shell access. $ git remote add origin firstname.lastname@example.org:timsjpark/practice.git $ git push -u origin master Counting objects: 3, done. Writing objects: 100% (3/3), 221 bytes | 0 bytes/s, done. Total 3 (delta 0), reused 0 (delta 0) To email@example.com:timsjpark/practice.git * [new branch] master -> master Branch master set up to track remote branch master from origin.
Don’t worry if your code doesn’t look exactly the same. Obviously, your username through GitHub will be different. Did it work? Now, refresh your practice repository on your web browser. The changes you made locally also appear on GitHub, so you should be able to see your Readme. Pretty cool, huh?! Try making more changes to your Readme, adding files, etc. and see if you can push them to your remote.
NOTE: After you do your initial
git push -u origin master, Git will remember to push the changes in your local master branch to the origin master branch. So if you practice making more changes, staging, and then committing them, the next line of code you write is just
Good luck, and stay tuned for more information about how to use Git to manage your projects!