We’re big fans of Git and GitHub, and have been using it for the last two years to collaborate on code internally, audit each other’s code through commit comments, and integrate better with our developer friends. But getting into the flow with Git wasn’t as dreamy as you may expect when you hear one of us advocate for its use.
Git is a great system for collaborating on and backing up code, but most of the people who use it are hardcore developers creating and running applications, plugins, and open source scripts for others. It’s incredible the amount of things we’ve seen our friends do with Git, but we’re ultimately designers and don’t need to blame/tag/cherry pick files, or push to any crazy sources like Heroku.
Hearing our Ruby on Rails friends talk about and drool over Git and try to get us into it while moving at 100mph was scary to say the least.
Every time I open up Terminal.app (or any command-line source I’m using), there’s a suspended, bittersweet moment between opening the program and getting to work. On the one hand, I feel like I’m a 1337 hacker; on the other hand, I get super confused about why .DS_Store files are making my life more difficult than it needs to be. But once I get into a flow with Git and understand the process, things run smoothly.
We tried using GUIs like GitHub for Mac, Tower, GitBox, and the like, but we’ve had some pretty raunchy experiences with them that forced us to use command line anyways. Certain things with branches are more difficult to do from applications, and every once in a while merging becomes a pain and requires extra steps in Terminal. In short, the GUIs just didn’t serve our needs.
So we prefer to use Terminal. That said, we’re huge fans of GitHub and support them proudly. They have great people, stellar uptime, and are continually improving their product like no other—not to mention they give a LOT back to the community, which is important to us.
We’re not going to tell you that using Git with Terminal will help you get laid or become a billionaire… but it will definitely make collaborating on code and working with development teams a whole lot easier.
Editor’s note: This article is written for Mac users.
Git !== GitHub
Git is a version control system that allows teams to work on the same code. Think about working in FTP with even one or two people on the same code – if someone saves a file after someone else while working on the same code, you’ll lose code that you may have saved.
Git allows us to work on the same code together by “pushing” and “pulling” from “repos”, and it automagically merges our “commits” (don’t worry, we’ll be explaining these terms a bit more in a second) so that none of our work is lost.
GitHub is a service that stores the repos on servers that we can use. There are other Git servers and services that you can use, but what you need to know right now is that GitHub is the service that stores our files, and Git is the control system we use to interact with that service.
Git > SVN?
We’ve used SVN before and it does a lot of things really well, but we also didn’t get the hang of certain other things (we honestly ultimately started using it because Beanstalk and Versions.app have the most drool-worthy interfaces around). If you’re choosing between Git and SVN, I’d look at what other people on your team/the team you’re collaborating with use so that you can integrate with them properly.
Also, the lovely folk at ThinkVitamin have a great article on why you should switch from Subversion to Git.
Before we get started
There are a few pieces of terminology we need to explain before we move forward:
- Terminal is a native Mac app that allows you to interact with systems via command line.
- We save changes with Git in “commits”. For example, you may have added a few lines to an HTML file and a CSS file. A commit would say “alright, these two files have been changed, and here’s what’s been changed in them”.
- Commits are saved in a “repo” on a “branch”
- A repo is the project you’re working on, sort of like a folder on your computer that you’d normally have for any given project.
- A branch is a working version of any given repo. Think of a normal site and the changes it goes through while features are added – having different branches for these features allows you to work on different versions of the same site without affecting the main set of code while you’re testing and working on other things.
We first need to make sure Git is installed on our computers. (An easy way of figuring this out is by opening Terminal.app in your Utilities on Mac and type in git help and hit enter. If it returns an error, you still need to install Git on your computer!)
If you don’t have it installed, you should go ahead and install it now, and set up your SSH keys (GitHub has a great article on all of this that I highly recommend).
Command lines were the first computer interfaces, and simulate most actions you perform on a computer on a daily basis. The first thing you want to get comfortable with is changing your directory to get to where you want to be.
Switching Between Directories
When you launch Terminal, you’ll see a line load that says your computer’s name, and your username (which is the “root” of where Terminal usually loads, similar to the place you get directed to when you open a new window in Finder). For me, this is what shows up:
Now, just to show you the basics of moving around in Terminal, type in ls and hit enter. It should list all of the files and folders inside the directory you’re in. Now what we want to do is move into another directory just to try it out. Since you’re more than likely in your root for your user on a Mac, let’s try moving into our “Documents” folder. To do that, you’d run:
You should notice now that that first line has now changed to something like:
If we ran the command ls now, we’d see Terminal return a list of all the files and folders inside the Documents/ folder. Perfect! Now, let’s move back to our root and we’ll create a folder that we’re going to have all our repos in.
Pro tip: When writing in file or folder names, you can hit the TAB key on your keyboard to automatically complete the name of what you’re spelling.
Doing this is simple, and if you even know a basic amount of CSS you’ll be able to do this with easy. To move back a directory, we do:
Now that first line should be back to what it used to be. So let’s create a directory. All you have to run is:
Where “mkdir” is short for “make directory” and “Red” is the new folder’s name. But, whoops, I actually want the folder to be named Blue, so let’s rename that folder by running:
mv Red/ Blue
If we ls again, we’ll see that worked the way we wanted it to. Say we wanted to remove that directory we just created, we could run:
Simple, right? Now you know the basics of moving around in Terminal. Good job so far, now we can start talking about getting your Git on!
Copying (“Cloning”) a Repo
Alright. By this point, you should have Git installed and your SSH keys setup. Now, say someone has already started a repo and has files in it for us – what we’ll want to do is find the repo online, and do the following basic steps to bring it over onto our computer:
- Get into the directory you want to have the repo in. The repo will have all of it’s files contained within a folder when you copy it over in the next step, so keep that in mind. I personally have a folder called “The Phuse” that has all active repos in it just to keep things organized.
- Clone that repo. Once you’ve created that repo, at the top there will be a URL that you can copy that looks like this:
All you have to do is copy that URL and clone it using Git. Here’s what it looks like:
git clone email@example.com:thephuse/360Ship.git
Once you hit enter after putting in this command, Terminal will show it’s way of downloading everything and stop when it’s done.
Simple, am I right?
Starting a New Repo
In this step, we’re starting fresh with a repo that hasen’t been created yet. Now what we’re going to do is go onto GitHub (or whatever you’ve decided to use) and create a repo. When you create a repo with GitHub, it actually tells you right away what to do, but here are the steps you’ll want to go through:
- Create a directory. Sweet, we already know how to do this! All we have to do is mkdir RepoName and we’re golden. (Make sure you’re in the directory you want it to be created in using the cd command we learned earlier!)
- Initialize Git. Now that we have a folder locally for our project, we’ll want to tell our computer that it’s a Git repo by running an easy Git command to initialize itself within the folder. All we have to do for this is run: git init
- Add GitHub as a remote origin. This is fancytalk that basically means we’re telling the newly created local Git repo where we want it to update online. To find out where this is, we go to our repo online and look for the SSH key at the top of the page that looks something like this:
Once we’ve got that, we want to add it as the remote origin by running this command:
git remote add origin firstname.lastname@example.org:thephuse/360Ship.git
And we’re all set!
Editor’s note: GitHub usually likes you to create a ReadMe file off the bat that describes what the repo is for and any notes about it, but we’re skipping that for sake of simplicity.
The Basics of Using Git
There are only a handful of basic commands you’ll be using with Git to update your files locally, and updating the remote origin’s files (e.g. the files on GitHub). We’ll go through the standard order of things we do in Git 99% of the time when we’re working on files.
To pull down files/changes from GitHub, the first thing we want to do is make sure that the files we have locally are up to date. Once we’re in the right directory locally in Terminal for the repo we’re working on, we’ll want to run a quick command to “pull” down the files or any updates that were made since the last time we were working on the project. To do this, we run:
If Terminal tells us that “All files are up to date.” we’re golden, otherwise you might want to take note of what files were edited for you own personal knowledge so you’re not surprised when you go into the jQuery file and it’s got a bunch of extra functions that weren’t there before.
Work as you normally would
Now that you’ve made sure you’re up to date, work on whatever you were planning on working on as you normally would, and you can minimize Terminal in the background.
Commit changes you’ve made
Now that you’re done working, you’ll want to make sure you update all the files on your remote. Again, commits are bundles of changes that have been made. Think of it like updates you get on applications. To create a commit, you need to first choose what files to include in the commit.
First, check what files have been changed by running:
Now that you know what files have been changed, you may want to create different commits with different files that were changed based on what you did. To do this, you’ll run:
git add filename
Where “filename” is the file that you’d like to add to the commit. If you want all the files you changed to be added to the commit, you can run:
git add .
When you’ve added all the files you’d like to be pushed up in a commit, you can now tell Git that all the files you’ve added can be put into a commit. This is done by saying:
git commit -m “Brief description of changes”
All commits have messages attached to them that are helpful for later when you’re looking at commits you’ve made. I highly recommend you keep these as orgasmall and nized as possible just in case you need to revert back to older versions of what you’re doing later. You can create as many commits as you want in a single push up. Usually what we do is create a bunch of local commits for different features we added and push them all at once when we’re done working for the day or when we need someone to take a look.
Pro tip: The best way we’ve found to name commits is by saying what the commit does. For example, if you’re fixing a dastardly IE6 bug, you could have a commit message that says “Fixes Internet Explorer 6 floating issue”, or “Adds an IE6 PNG transparency fix”.
Once you don’t have anything more to do, you’re going to want to push all your changes up to GitHub by doing:
There may be an error saying you need to pull first which means while you were working, someone else pushed some files up and you need to pull them down. 90% of the time both people won’t be working on the exact same lines of code, so the pull will automatically merge files, but if you happened to have worked on the same lines then you will need to manually fix any merge errors (don’t worry, Git will tell you where those problems are and will leave messages in your code to help you out as well).
That’s all you need to do for the basic setup of Git. Now people you work with can collaborate easier with you without having to worry about getting their files messed up, and people can see awesome differential messages online of things that have changed in files across commits!
The folks at GitHub have an awesome article on how to get set up with GitHub Pages. We use Pages and we highly recommend it. Check it out here!
Simple, right? Git is a powerful tool that can change your workflow and make your life and the lives of your developer friends easier.
If there’s something we’ve missed, or there’s something you’d like to add to this walkthrough, leave it in the comments or send us an email, and we’ll update this document right away.
[Codercat illustration via The Creation of An Octocat]