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 "jason@teamtreehouse.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. You do that with the cd command. I’m going to put my web site in the Sites/think_vitamin directory.

[~] $ cd Sites/think_vitamin
[~/Sites/think_vitamin] $

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 status command:

[~/Sites/think_vitamin master]$ git status
 
# On branch master
#
# Initial commit
#
# Changes to be committed:
#   (use "git rm --cached ..." 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 Changes

A 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 5: 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 ..." to update what will be committed)
#   (use "git checkout -- ..." 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 ..." 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 6: 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 ..." to update what will be committed)
#   (use "git checkout -- ..." 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 diff command:

[~/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 @@
-

Hello world

+

Hello world

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 7: 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 master:

[~/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 
Date:   Wed Feb 1 15:07:45 2012 -0500
 
    Make header font comic sans
 
commit bc8251b338b8ac4451888e1da482708df6264529
Author: Jason Seifer 
Date:   Wed Feb 1 10:16:41 2012 -0500
 
    Modify home page header
 
commit 542d5fab4c86d29a125a78b8a89366f70bdfaa9d
Author: Jason Seifer 
Date:   Wed Feb 1 10:10:01 2012 -0500
 
    Initial commit

Well Done!

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!

Treehouse

Our mission is to bring affordable Technology education to people everywhere, in order to help them achieve their dreams and change the world.

Comments

26 comments on “Git For Designers (Part 1)

  1. Definitely getting designers comfortable with git is a noble pursuit. Wouldn’t you significantly increase their odds of success by suggestion one of the better gui options rather than teaching command line?

    • That’s the exact reason why we chose to build something called LayerVault. (We actually launched on the stage of FOWA London last year. Hi guys!)

      It’s all about using the right tool for the right job. For our code, we use git/github. For our designs, we use LayerVault.

      • RELATED: I clicked to read this article thinking it was an interview with the good LayerVault peeps. The visual version browsing is pretty amazing stuff.  If you’re looking for version control for designers, I’d recommend checking it out before heading into Git.

    • Designers should not fear the command line. GUI git is nice and all… but getting to know tools that fellow developers use can be a nice way to be comfortable when collaborating and pairing. I am a designer and use the command line. I have used GUI tools for git as well… but have learned to love the simplicity of the Command Line UI. I think that there are times when a nice visualization comes in handy.. .like when doing larger commits or handling some merge conflicts.. gitx is nice for that… and when in a project, you can just type: gitx and move into a more visual git experience. I am not dissing your comment… just think that designers might want to learn that the command line is simple and effective. And can be really cool too.

    • I’m personally not a fan of the GUI options. Designers are super smart! If you show them how to use it they’ll get comfortable pretty quickly, even if there aren’t any pretty buttons :)

  2. Thanks for this article. I’m learning Git myself as a designer, but I make my life a little easier by using Git GUI whenever possible.

  3. I’m a huge fan of GIT and I definitely recommend it. I will only mention that for designers some good GUI would be the best choice. I personally use SmartGIT (free for non-commercial projects) and love it. I’m sure there are other nice tools too.

  4. You could make this a little clearer to designers by giving an overview of the structure of files when using GIT. For example, it’s important to make clear where the “working files” are, and what happens to them when you create a branch, and switch between a branch and the master, and then finally merge any changes. An overview of how GIT works and what happens in the .git folder would also be helpful.

    But I generally agree with the other commenters that a GUI tool is a better approach for designers. 

  5. Just a few nitpicks:

    Step 4 is repeated, the first step 4 contains a spelling error, and for some reason after that step for you went from using h2 to using h3 for headlines.

    You know, just throwing that out there.

    Also: “change to the directory containing the site you want to put in to git”.

    I’m pretty sure a significant number of people fell off at that point. Where would you suggest one goes to learn the basics of using the command line? (I’m talking about things like “ls”, “cd”, etc here).

    • Thanks a lot for point out the errors! I’ve fixed them and also added a note about how to change to the directory you’d like to work in.

      I’m not sure about a good place to learn command line basics, but that might make a good blog post in the future. Thanks!

  6. These tutorials are always great to learn new things if you’re new to this thing called ‘version control’. I’ve seen a few of these tutorials before and they always show the great stuff about version control, branching and they mention that: “… you can go back to a previous version, if you made mistakes to you’re files …” etc.

    To me, the number #1 feature of a ‘version control system’ is keeping ‘versions’ of files and directories. But they never show you how to actually revert or reverse merge a file (or entire working-copy) to a previous version. It would be nice if this major feature of a version-control system is
    explained in these kind of tutorials. It would make these tutorials
    complete.

    I’m an SVN guy, I looked at Git, it’s great and I’ll probably use it some day. And I can do a lot of Terminal stuff with SVN or Git. But yes, as someone mentioned before … designers are kind of scared of anything that has no ‘graphical user interface’ (GUI) and generally hate to do things by typing dull commands in a terminal window.

    This tutorials is great, don’t get me wrong. It gets (new) people exited about version-control and hope they want to learn more, and learn how to actually go back to previous versions. It’s not that hard to do or learn.

  7. I’m trying to learn Git at the moment and one of the problems I’ve been having is forgetting to use the -m flag for a commit message and getting thrown into VIM, which I don’t know how to use yet. That’s pretty off-putting, and has me looking for GUI options. 

    Another issue is the whole idea of using GIT to take a snapshot of your files as they are, when you can just as easily do that by duplicating their directory and experimenting on the copy. 

    I am keen to learn it though, because I would like to branch and merge, and I find that tutorials tend to be weakest in those areas. Branching and Merging too, as a concept, seem to beg for the visualizations offered by a GUI.

  8. Lots of minor erros in the article.

    Yeah.  As a Graphic Designer with a very strong technical background – Im still in favor of GUIs (as long as they function pretty much the same as using the command line).
    However – simply jumping into Git and having to systematically manually type in commands regularly to version out a project seems pointless if I can do the same (and much quicker) by simply copying the Project Folder and adjusting the notation.

    As a Mac user – I can set specfic parameters to Time Machine and use that backup system as a makeshift verson control.  There are equivilant options on the PC side for this as well.

    If your projects are housed on a decent server structure – this can again be implemented ‘on the fly’.

    But the point is – this is something that if implemented should be more seamless and behind the scenes. Otherwise creating more work for yourself is counter-productive.

    Unless you script the whole damned thing so that it does become an automatic process.

    But as a Desinger – typing out a half dozen lines of code everytime I want a divergent copy of a project is a waste.

  9. Great article. I enjoyed it having been vaguely familiar with git, I learned quite a bit.

     I think the best/fastest way to convince designers the virtues of version control is to simply ask if they have the following files laying around their hard drives:client_layout_mockup.psdclient_layout_mockup2.psdclient_layout_logo_mockup.psdclient_layout_logo_mockup_final.psdclient_layout_logo_mockup_final.zipclient_layout_logo_mockup_revisions.psdclient_layout_logo_mockup_revisions2.psd…. and so on.As a recovering designer, hearing that version control eliminated this cluster-eff file naming convention was enough to get me to use it. 

  10. A quick question, we have 3 commits now and if i want to go back to the “initial release” how can i do that?

  11. Well, all really works it?! If this variant works for me, I will refuse an old and difficult method. And besides thus my code can be reduced. Thanks for idea!

  12. What we want to do is merge or changes from the comic_sans branch

    Just a little typo, it should be merge ‘our’ changes, not merge ‘or’ changes