Git For Designers (Part 1)
Hi designers! I’m not a designer. Sorry. I’m a developer. I can barely tell when things look good or not. This week I learned that there are different ampersands out there (thanks, Allison!). But that’s not why I’m writing today. We all have to work together. Professionally, one way we do that is by using version control. A version control system tracks changes to your code. There are a lot of different version control systems out there. Today we’ll be talking about git. Specifically, as it relates to designers making web sites.
Why Use Version Control?
You might be wondering why you should use version control, even for a site you’ll never collaborate with anyone on. This is a valid question. I can best illustrate the answer with a scenario you may have encountered in the past. Let’s say you’re in the middle of making a site and want to try something crazy with the css. Maybe you want to do a bit of an experiment and make everything strange shades of yellow and red. You don’t know if you’re going to keep the work when you finish it. Since it’s an experiment, it would probably be a good idea to not mess up your working version of the site.
At this point, you might be thinking of creating a copy of the site and making your changes on the copy. Maybe you’re sure that you’re going to use this work and you’re going to crank through. Maybe it doesn’t work out, though. Wouldn’t it be nice if you could take a snapshot of your site now, do your experiment, and not have to worry about whether you mess things up? That’s exactly what version control is for!
Step 1: Install and Configure Git
In order to start working with git, though, we need to install it. Git is fairly easy to install. If you’re using Windows, GitHub has an excellent set up guide to get git installed on Windows. They also have great guides for Mac OS X and linux. If you don’t already have git installed, follow those guides and come on back here.
Once you have git installed, you have to tell it who you are. This is done using the
config command. Open Terminal and type in the following:
$ git config --global user.name "Jason Seifer" $ git config --global user.email "email@example.com"
Step 2: Initialize a repository
We’re going to initialize a git repository now. A repository is just a directory with one or more files we want to track the changes of, in this case our web site. Open up terminal (or command prompt on Windows) and change to the directory containing the site you want to put in to git. Once you’re in there, type the following:
[~/Sites/think_vitamin] $ git init
Assuming you have correctly installed git, you should see the following:
Initialized empty Git repository in /Users/jason/Sites/think_vitamin/.git/
This is git telling you that thinks are working and that the path it gave you is now a repository. If you don’t see that output, go back to step 1 and verify that everything was correctly installed.
Step 3: Add Your Files
Now that we have initialized our git repository, we have to tell git what files we want to add to the repository. In order to do this, we use the
add command. The
add command takes either a single file or a path. The
add command takes the changes you’ve made and adds them to something in git called the staging area. The staging area is kind of like a waiting room for git. It lets you tell git what changes you’re going to add to the main index.
Since we are already in the directory with our web site, we’ll tell it to add the path of the current directory:
[~/Sites/think_vitamin] $ git add .
At this point, you won’t see any output. My example is just an
index.html file. In order to see what git is about to stage, you can use the
[~/Sites/think_vitamin master]$ git status # On branch master # # Initial commit # # Changes to be committed: # (use "git rm --cached <file>..." to unstage) # # new file: index.html #
The first line of the output says "
On branch master". In git, a branch is just a pointer to something called a
commit (explained in the next section). Since this is our first commit, git lets us know that on the second line of output where it says
Initial commit. Next, git says there are changes to be committed. My
index.html file is there since it’s the only thing I have in the directory right now. This is good!
Step 4: Commit Your Chages
commit in git is a pointer to a series of changes that you have told git you want to track with the
add command. When you commit your changes, git writes them to the index. This is git’s way of saying "this is what the repository looked like at this point in time." So let’s commit our changes:
[~/Sites/think_vitamin]$ git commit -m "Initial commit" [master (root-commit) 542d5fa] Initial commit 1 files changed, 1 insertions(+), 0 deletions(-) create mode 100644 index.html
Here we use the
commit command to tell git to commit our changes to the repository. The
-m argument told git that we want to give the commit a message. My message here was "Initial commit" because this was the first commit to the repository. As you make changes, you can be much more descriptive. This is helpful when working on larger teams. Time Pope has a great article on writing good commit messages if you’d like any pointers.
The important thing about commits is that, once you have committed changes, you can always go back to how your repository was at the point in time of that commit. How cool is that? That means that you’re now free to make horrible changes to your site. Wnat to see how Comic Sans looks for all the headers? Go for it! You can always go back.
Step 4: Make some changes
Now that things are committed, you can feel free to make some changes to your code. In my example web page, I made changes to the header of the page. Now we can run
git status again to see what happened:
[~/Sites/think_vitamin]$ git status # On branch master # Changes not staged for commit: # (use "git add <file>..." to update what will be committed) # (use "git checkout -- <file>..." to discard changes in working directory) # # modified: index.html # no changes added to commit (use "git add" and/or "git commit -a")
Now we’ll add the file we just changed:
[~/Sites/think_vitamin]$ git add index.html 1.9.3 [~/Sites/think_vitamin]$ git status # On branch master # Changes to be committed: # (use "git reset HEAD <file>..." to unstage) # # modified: index.html #
Finally, we’ll commit the change:
[~/Sites/think_vitamin]$ git commit -m "Modify home page header" [master bc8251b] Modify home page header 1 files changed, 1 insertions(+), 1 deletions(-)
Great! We just made our first two commits. Our co-workers will love us for writing a descriptive message along with the second commit, too, although they might also still be mad for taking the last cup of coffee.
Step 5: Make a branch
Remember earlier when we were talking about making experimental changes that you may want to keep? That’ what branches are for! Branches let you easily separate your work. You can have two branches going at the same time with different work. Branches are great for experimentation with something that you’re not sure you’re going to keep.
Let’s say we wanted to change the font on all headers to Comic Sans. You’re not sure how this is going to look (bad) but your client really wants you to give it a try anyway. Let’s create a branch to do that just in case we want to switch back. In git terms, we call this process creating a branch. We do that by checking out the branch and passing a flag to git saying that we want to create it:
[~/Sites/think_vitamin]$ git checkout -b comic_sans Switched to a new branch 'comic_sans'
Now that we’re on our
comic_sans branch, we are free to make changes and commit them. This won’t affect anything on our
master branch until later. Let’s make our changes:
[~/Sites/think_vitamin]$ git status # On branch comic_sans # Changes not staged for commit: # (use "git add <file>..." to update what will be committed) # (use "git checkout -- <file>..." to discard changes in working directory) # # modified: index.html # no changes added to commit (use "git add" and/or "git commit -a")
Git also let’s us see what changed in between what we’re about to stage with the
[~/Sites/think_vitamin]$ git diff diff --git a/index.html b/index.html index 159202e..266d025 100644 --- a/index.html +++ b/index.html @@ -1 +1 @@ -<h1>Hello world</h1> +<h1 style="font-face: Comic Sans">Hello world</h1>
We can also add and commit the change with one command by using the
-a flag when committing:
[~/Sites/think_vitamin]$ git commit -am "Make header font comic sans" [comic_sans 94af8b2] Make header font comic sans 1 files changed, 1 insertions(+), 1 deletions(-)
Now we’ve committed to the
comic_sans branch. Sweet!
Step 6: Merge your changes
Our client is now happy with the header changes. Our experimental branch we created now needs the changes to make their way back in to our main branch. We do this through a process called merging. What we want to do is
merge or changes from the
comic_sans branch back in to the
master branch. First, we have to go to the branch we want to merge to. We do that by checking out. This time, we won’t use the
-b parameter since we’re not creating the branch:
[~/Sites/think_vitamin]$ git checkout master Switched to branch 'master'
Now we use the
merge command to get our changes from the
comic_sans branch in to
[~/Sites/think_vitamin]$ git merge comic_sans Updating bc8251b..94af8b2 Fast-forward index.html | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)
Boom! Now we have all of our changes in to git. If we want to see what these changes were, we can use th
log command to get a nice display of times, dates, and authors:
[~/Sites/think_vitamin]$ git log commit 94af8b2e976ba11755f7483bc761ea2b9a747e0a Author: Jason Seifer <firstname.lastname@example.org> Date: Wed Feb 1 15:07:45 2012 -0500 Make header font comic sans commit bc8251b338b8ac4451888e1da482708df6264529 Author: Jason Seifer <email@example.com> Date: Wed Feb 1 10:16:41 2012 -0500 Modify home page header commit 542d5fab4c86d29a125a78b8a89366f70bdfaa9d Author: Jason Seifer <firstname.lastname@example.org> Date: Wed Feb 1 10:10:01 2012 -0500 Initial commit
In this article we learned how to install git, create a repository, change branches, and commit changes to our code. In the next article in this series, we’ll learn about removing files, going back to different commits, and pushing up to GitHub and working with other people. Stay tuned!
- A New Year, A New Responsive Dribbble Portfolio – Part 1 of 2 What better way to start off the new year then...
- Looking for Web Designers to beta test new system Reply to: email@example.com We are looking for web designers to...
- Web designers, what to look for in a CMS There are a whole bunch of CMSes out there ranging...
- Immediate part-time position for a social media coordinator (DELRAY BEACH) Reply to: firstname.lastname@example.org Responsible for implementing all aspects of website...
- What’s new for designers – January 2012 The January edition of what’s new for web designers and...