Posted 02.16.2015

Getting your Git On: A Beginner’s Guide to Git

What is git anyway? Short answer: version control. Long answer: Think of it as having unlimited undos on your code. Or better yet, if you’re collaborating with another developer, it allows you to both work on the same project without overwriting each other’s code. Awesome!

This has saved my butt on more than one occasion. I’ve vowed to always use source control, regardless of how big or small the project is.


So, now that you’re interested in git, where do you begin? To get started, you’ll need to install git on your local machine (don’t worry, I’ll explain). Eventually, you’ll want to use an online service to store your code, like GitHub, BitBucket, or Beanstalk. (more on that below, too)

Installing git Locally


I use a Mac, so unfortunately, I can only speak to that. However, if you’re using another operating system try looking here.

The easiest way to to install Git on your Mac (if you’re on Mavericks or older) is to install the XCode Command Line Tools. This is as simple as trying to run git from the Terminal.


Remember, when you’re working in the Command Line, the dollar sign ($) is the prompt and signifies a new line. No need to copy it.

$ git

If you don’t have git installed already, it will prompt you to do so.

If you want a more up to date version, or would rather run the binary installer, you can grab that here.

The first thing you’ll want to do is configure your git settings.

$ git config --global "John Doe"
$ git config --global "[email protected]"
$ git config --global color.ui auto

Git is typically run from the Terminal. However, as a designer, I tend to be a little leary of the Termianal. Granted I’ve gotten more comfortable, but I still prefer a GUI (Graphical User Interface) when I can get one.

I think the easiest thing to do is learn the vocabulary. Then, it doesn’t matter whether it’s the Terminal or GUI, the same concepts apply no matter what.

Learning the vocabulary


Here’s a cheat sheet you can print out and keep handy.

Let’s walk through this as you would for a real project.

You’ll want to create a folder on your computer for your project. In my user folder, I have a folder called Code. Then, a subfolder called GIT. I keep all my project folders there.

Code > Git folder structure

If you’re trying to do everything from the command line, these commands create a new folder and then navigates inside:

$ mkdir new_project
$ cd new_project

Let’s initiatize our git repository. (All your git projects are called repositories.)

$ git init

So what does initializing really do? It creates an empty repository in a hidden folder, .git.


If you ever wanted to remove the repository, all you’d need to do is delete that .git subdirectory:

$ git rm -rf .git

Notice, I said empty. It did not add the current content within your folder. You have to tell it to do that yourself.

All the content within your project folder is considered the working copy. Once you get to a place where you want to save those files, you’ll stage your changes and then commit them to your local repository.

The advantage here is not all of the files you’ve modified since your last commit have to be staged and committed.


Let’s get an overview of everything that has changed since we last committed:

git status

git status

Git will put your changes into three main categories:

  • Changes not staged for commit
  • Changes to be committed
  • Untracked files


You can add all these changes by using:

git add .

If you don’t want to add the changes you’ve made, but cherry pick files, you can list them out:

git add assets/dist/css/main.css assets/dist/js/production.js


If we removed a file, we’d need to confirm that too:

git rm something.html


Now, let’s commit our updates:

git commit -m "Initial commit"

The first commit, I usually title as “Initial commit” but as you continue to make changes and commit your code, you’ll want these messages to be meaningful. This will make it easier for you (or your teammates) to understand the changes you made later down the road.

Your message should include information like, “What was the motivation for the change? How does this differ from the previous version?”

If you need a longer commit message than 50 characters, you can leave out the “-m” parameter and Git will open an editor application for you to write a longer message.

Here are a few guidelines from Tower’s eBook, Learn Version Control with Git:

  1. Related Changes A commit should only contain changes from a single topic. Don’t mix up contents from different topics. This will make it harder to understand what happened.
  2. Completed Work Never commit something that is half-done. If you need to save your current work temporarily in something like a clipboard, you can use Git’s “Stash” feature. But don’t eternalize it in a commit.
  3. Tested Work You shouldn’t commit code that you think is working. Test it well — and before you commit it to the repository.
  4. Short and Descriptive Messages A good commit also needs a good message.


If you want to review a history of all the commits that have been made to a project:

git log

You’ll see a list in chronological order, beginning with the newest item.

git log

If there are more items than what can be displayed on one page, you’ll see a : at the bottom of the screen. You can go to the next page by hitting the <SPACE> key and quit with “q”.

You’ll notice from the log, every commit has:

  • Commit Hash This is that crazy long string of letters and numbers (i.e. aa093b890c78e9d0869a3f267b2530cf2cbeb83f)
  • Author Name and Email Remember when we set our name and email address within the git configurations above? This is where it gets used.
  • Date
  • Commit Message


Now that we’ve made a bunch of commits, let’s publish (or push) them online. First we need to tell Git where our remote repository is.

There’s several services you can use, three of the most popular ones are:

I go into a little more detail on each service’s features below.

Regardless of the service you use, when you create a repository, they will give you an SSH address and HTTPS address.

You can use either:

$ git remote add origin [email protected]:ahhacreative/git_blog_post.git


$ git remote add origin https://[email protected]/ahhacreative/git_blog_post.git

In this case, we named our remote repository “origin.” This is the default within Git. However, I could just as easily name it something else. I usually name mine based on where the remote repository is. This makes it easy within Tower (my GUI of choice) to tell where it’s being saved:

Git Remotes on Tower

From the command line:

$ git remote add BITBUCKET [email protected]:ahhacreative/git_blog_post.git

You can see a list of all your remotes:

git remote -v

git remotes

You’ll notice there are two URLs listed (fetch and push). One is for read access (fetch) and the other is for write (push). Uusally, the two URLs are the same, but you could use different URLs for security and performance issues.


Now, we need to push our code up to our remote:

$ git push origin master

Hopefully, some of these things are starting to look familiar. origin is the name of the remote repository and master is the name of our branch. (We haven’t talked about branching yet. It’s OK, just trust me for now, but it’s coming.)

git push

Let’s pause for a moment. I just want to take a moment to point out: you’re more than halfway there! It wasn’t that hard, was it?! You know everything you need to know to save, commit, and publish your files online! There’s still more topics to cover, but you already know the basics. That’s worth celebrating!


OK. So far, we’ve just published our changes online. But, what if we’re collaborating with another developer? They’re publishing their changes too. How do we pull down there code?

First you may want to see what you’re pulling:

$ git fetch origin
$ git log origin/master

If you want to integrate these changes into your local working copy:

$ git pull

If you have multiple remotes and branches, you may need to specify:

$ git pull origin master


OK, so let’s (finally) talk about branching.

When you’re coding, there are usually several different contexts or “topics” you’re working with:

  • features
  • bug fixes
  • experiments

In the real world, these all happen simultaneously. You’re trying to fix a bug while a teammate is working on the new about page design.

If branching didn’t exist, how would you integrate some of these changes, but not all of them? You need to post the code for the bug fix, but your teammate isn’t ready to launch the new about page. You find out the new “members only” code you’ve been working on is going in a different direction, but you’ve already integrated that code in with everything else. How do you separate it out?

no git branches


You can create a branch to handle each of these topics. It stays separate from all the other contexts. When you make changes, they only apply to the current active branch.

git branching

Your current branch can be referred to as the active branch, checked out branch, or HEAD branch. They all mean the same thing.

Whenever you run git status, it will tell you what branch you’re currently on.

current branch by running git status


You may have noticed from my screenshots, that my Terminal shows me what branch I’m in and changes color based on whether I’ve there are uncommitted files or not.

git inside iTerms2 and oh my zsh

I’m running Oh My Zsh within iTerm2. I have more details in a blog post.

To create a new branch:

$ git branch feature/about-page


I like to name my branches my contexts. So, you’ll notice, I prepended my branch name (about-page) with “feature.” This is nice because within Tower, it treats these contexts as folders:

branches within Tower

We’ve created a branch, but it’s still not our current branch. To change branches, you’ll need to checkout:

$ git checkout -b feature/about-page

To view a list of all our branches:

$ git branch -v

The -v (verbose) flag, provides more information, than just git branch.

git list branches

Now, that you know how to create and change branches. What happens when you’re ready to commit that code to your main (master) branch?

First, you’ll want to navigate to your master branch. Then, merge in your new branch:

$ git checkout master
$ git merge feature/about-page

Once a branch is merged and deployed, you no longer need it. To delete a local branch:

$ git branch -d feature/about-page 


Remember when we talked about not committing half done work? How do you get around that?

Stashing. explains it well:

Think of the Stash as a clipboard on steroids: it takes all the changes in your working copy and saves them for you on a new clipboard. You’re left with a clean working copy, i.e. you have no more local changes.

To stash your local changes:

$ git stash

To see an overview of all your current stashes:

$ git stash list

The most recent Stashes will always be listed first.

When you want to apply a Stash, you can run:

$ git stash pop

This will pull the latest Stash and clear it from your clipboard. Or

$ git stash apply <StashName>

This pulls the specified Stash, but unlike pop, it remains saved. To delete it, you’ll need to run git stash drop <StashName>


These things are all great, but what if you’re not starting from scratch? What if you’re joining a project that already exists?

Then, you’ll want to use clone.

$ git clone https://[email protected]/ahhacreative/git_blog_post.git

This will automatically set the remote to the “origin.” Anytime you pull, it will grab any updates made to the repository.

Sometimes, you’ll want to grab the code from a repository, but start with a clean history. To do so, simply add the flag --bare:

$ git clone --bare https://[email protected]/ahhacreative/git_blog_post.git


There will be times when you don’t want to put all your code within your repository. For example, if you’re using bower, you probably don’t want the bower_components folder. Or, if you’re running grunt or gulp, you don’t need node_modules. A teammate only needs to run bower init or npm install to get those files. Committing them would only bloat your repository.

You can create a file called .gitignore and list all the files or folders to exclude. For example, here’s my .gitignore file for a WordPress project:

Remote Repositories

There are several services that you can use to host your remote repositories.



GitHub is probably the most popular. If you make your repositories public, then you can create an unlimited number of repositories for free. You start paying when you create private repositories.

GitHub also has an excellent issue tracker built in among several other great resources.

Even if you don’t plan on paying for a GitHub account, I would highly recommend signing up for an account anyway. GitHub has practically become a standard for developers. Meaning, if you’re applying for a programming job, your potential employer could ask to see examples on GitHub.



I actually store all my code on BitBucket. BitBucket does everything that GitHub does, but is missing the community that surrounds GitHub.

For me, the decision came down to $$. GitHub’s business model revolves around the number of private repositories you create. BitBucket’s bases its pricing tiers on the number of users. As long as you have under 5 users, it’s free.

As a one-woman web shop, I was easily in the top tier with GitHub. But, with BitBucket, I can have as many free private repositories as I want. That’s a no brainer.


Beanstalk App

BeanStalk is another great service. Like GitHub, you’re paying based on the number of repositories you use.

It’s missing a lot of the features that the other two services provide, but the biggest benefit it has is built in deployment. Meaning, you can push changes to your repository and it will automatically send those updates to your server via FTP (or however you specify). That’s almost enough to make me switch.

In the meantime, I’m using instead. It’s made by the same company (WildBit) that makes Beanstalk. allows you to deploy commits from BitBucket or GitHub. Pricing is based on the number of repositories you’ve connected.

The Apps

OK, now that you know the correct terminology, I want to introduce a few GUIs:


Tower App

I use Tower. IMHO, it’s the best. Just from glancing at the screenshot, you can see the buttons along the top for most of the vocabulary terms covered in this post. If you want a little more information, check out this screencast (from the Tower app team):


GitHub on Mac

GitHub has their own GUI. Unlike Tower, it’s free. I’ve downlaoded it, but I rarely use it since I have Tower.

At the end of the day, it’s whatever you’re the most comfortable with. They all accomplish the same thing. My thing is don’t let the tools get in the way of making cool stuff.

Additional Resources

Granted, we’ve covered the basics, it should be enough to get you up and going. However, if you want to dig a little deeper, here are a few additional resources to check out:

Posted 01.16.2015

The Mistakes I Made in Building a Web App

A few years ago, I started been building a web app. I designed it. Coded it. It’s been a long process, mainly because it’s been just me, pushing pixels and stealing a line of code here, a line of code there. It was a long process because it included a lot of learning…the hard way. I’ve made a few (major) mistakes.

I didn’t show people early or often.

As a perfectionist, I’m very protective about my work. I don’t let people see what I’m working on until I’m ready. I want them to see the best version of what I have, best foot forward. –No need for them to give input on something that’s half baked.

The problem with that mentality, though, is I took the project down roads that I never should have gone down. I worked with blinders on. What I did made sense to me. I put my engineer hat on. I thought about the back end and the code and the logic and forgot about the people that would actually be using the system. When I finally did show people, they would (quickly) find problems.

“Why doesn’t it do this? What do I now?”

“Isn’t that obvious?”

“Well, no.”

I should have showed people early and often. I should have talked to the people that would be using the system and find out what they really needed instead of giving them what I thought they wanted.

Two of the best books out on interface design is Rocket Surgery Made Easy and Don’t Make Me Think, both by Steve Krug.

Rocket Surgery Made Easy by Steve Krug
Don't Make Me Think by Steve Krug

In Rocket Science Made Easy, he talks about corporations that will pay thousands of dollars to have experts analyze their sites. When, really, all you need is Joe Smoe end user. He’s your target audience anyway (not the expert). Simply watch Joe use your site. You’ll learn so much by simply paying attention to where he clicks. Where’s the first place he goes for information? Does he immediately know the purpose of your site? Does the navigation make sense? Joe’s not short on opinions, you just have to be willing to ask and be humble enough to hear what he has to say.

I never gave people a reason to need the system.

When we got ready to beta test, I was invited to a leadership meeting to introduce this new tool I had created. “Here it is! My web app will make your life so much easier. Look at this bell here and that whistle there. Isn’t this great? I’m doing you a favor.”

After that meeting, I kept hearing, “This is great. I’m sure it’s useful, but my pen and paper method worked just fine.”


I could dismiss it. They’re older. They just don’t understand technology. But, is that a fair assessment?

How does my web app make their life better? The administration understood. They knew it would dramatically cut down on data entry, emails, reminders, and processes. But, I failed to communicate that to Joe Smoe. There was disconnect between their need and my app.

So, how do I close that gap? You tell a story. A good story always has a problem. Then, it works toward a solution. My end user may not know what the problem is. I have to define that for them. Then, hopefully, my product, my web app is their solution. I need them to buy into the system, otherwise it will never get used. It will fail before it even has a chance.

I didn’t mimic a system they already knew.

After a month of testing, I had a beta user that believed in my product. He had a background in Internet Technology and was willing to sit down for coffee and walk through my app, discussing points for improvement.

One of the first things he did was pull out a folder with a print out. “This is the system we know. Flawed? Maybe, but we’re used to it.” Then, he pulled up my web application. The two looked nothing alike. — which is fine, except for one thing. It didn’t give my users a frame of reference. They needed something to go off.

Let’s look at Apple as an example of doing it right. Address Book in the OS Lion looked just like an address book I could pick up at Office Max.

Address Book on my Mac

Notepad on my iPad originally looked just a yellow legal pad.

Notepad on the iPad

Why? Because these are systems I’m familiar with. There’s something about translating the physical world to the digital that gives the user a sense of comfort. I know how it works in the physical world, therefore those metaphors must carry over.

These lessons are hard when you’ve put in time and energy. But, now I know.

What are some lessons you’ve learned the hard way in web development?

39 Things to do to Guarantee a Perfect Site Launch

Many times, when people get ready to launch a site, they’re so excited about going live and calling the product finished, that they don’t do an adequate job of making sure the site is really and truly complete. It’s easy to do. I’m guilty. You’re ready to share what you’ve been working on for weeks, months even. But, skipping these steps doesn’t provide the quality that your clients need.

Over the years, I’ve compiled a launch checklist of items that help guarantee a perfect site launch. This list ensures I’ve dotted the final i and crossed the final t.

  1. No spelling errors
  2. Content is consistent (capitalization, tense / sense of writing, reocurring and common phrases)
  3. Content has been placed consistently
  4. No test content
  5. Page and content formatting has been tested
  6. Print stylesheets exist and tested
  7. Meta data has been included and is appropriate
  8. Setup accounts on Google Webmaster Tools and Bing Webmaster Tools
  9. Sitemap.xml created and submitted to Google and Bing.
  10. For redesigns, make sure old / existing URLs are redirected to relevant new URLs, if the URL scheme is changing.
  11. Images have appropriate ALT text
  12. Page titles are appropriate and SEO friendly
  13. Create metadata descriptions for important pages.
  14. Favicon has been created and displays correctly
  15. Footer includes copyright and a link to the site creator
  16. HTML has passed validation (W3C Validator)
  17. Check for canonical domain issues (e.g. variations in links to should be reduced to a single consistent style)
  18. CSS has passed validation (W3C CSS Validator)
  19. JavaScript is error free (JSLint)
  20. Minify/compress static (JavaScript/HTML/CSS) files
  21. No broken links, internal and external (W3C Link Checker
  22. Check for hard coded links to the staging server
  23. Displays and functions correctly in various browsers (BrowserShots or Litmus)
    • IE7
    • IE8
    • IE9
    • Firefox (Mac + PC)
    • Chrome (Mac + PC)
    • Safari (Mac + PC)
    • Opera (Mac + PC)
  24. Tested at 1024 x 768 Resolution
  25. Tested at larger resolutions
  26. Tested on iPad
  27. Tested on iPhone
  28. Forms have been tested and processed correctly
  29. Required fields have been tested
  30. Forms send to the correct recipient(s)
  31. Check internal search functionality (including relevance of results)
  32. Web statistics package installed and operational (Google Analytics, Clickly, Mint, or StatCounter)
  33. 404 page exists and informative
  34. Full web site build documentation (including platform definition, inventory log, and user, operator, systems, and administrative manuals)
  35. Use robots.txt where necessary
  36. Site backups scheduled
  37. Check and implement caching where necessary
  38. Check download time review and browser compatability: (Google’s Page Speed and Pingdom)
  39. RSS set up (FeedBurner)

Additional Resources / References

The list that I’ve creaed has come from my own personal experience as well as others:

Have I missed anything? Are there other things that you do before launching a site?