Console and Git for Beginners (pt 1)
As a designer who uses Git and Terminal on a regular basis, it pains me to talk to other front-end web developers that aren’t even aware such wonderful things exist. I could go into the many ways that Git has helped me become a better coder and designer, not to mention how many times it’s saved my ass. As far as I’m concerned it’s the best version control out there right now and more designers need to get on board using it.
GUI vs Console
There are plenty of apps and plugins out there for Git. These are great for learning and for looking at diffs that come up, seeing what’s in the queue to be committed, etc. Let’s face it though—you’re not going to be a killer web designer if you use a wysiwyg for all of your coding, just as you will not be a pro with Git unless you use a terminal or console to work with it.
What is Terminal?
“A terminal window allows the user access to a text terminal and all its applications such as command line interfaces (CLI) and text user interface applications.”1 How it relates to your Git repositories is that it becomes the hub of your project. You’ll be running everything locally through it. For example, I’ll usually have a tab open for Git, a tab for running the project, a tab for Sass, a tab for Coffeescript, etc. etc.
Most operating systems already come with a default terminal application. I’m on a Mac so I just use “Terminal” but if you’re on something different here’s a big ol’ long list of terminal applications you can peruse through.
Terminal Basics
Let’s just get down a few basic commands in Terminal that will help you out when you’re using Git.
First off, it helps to know where you are right now. Whenever you’re in the terminal, you are currently in a directory somewhere on your computer. To see which directory it is, just type:
pwd |
Good start! Now, to CHANGE where you are, you can use the following command:
cd [some directory] |
Example:
cd websites/new_project |
But, this only lets you go deeper into the directory structure. If you want to back out of the directory that you’re in, you can use this to move up to the current directory’s parent:
cd .. |
In order to see what’s available in the current directory you’re in, you can use this command:
ls |
Running Processes
Depending on what your project is built on, you can use Terminal to start your projects and keeping them running in the background. At 12 Spokes we concentrate on projects built with Ruby on Rails, so a lot of times I’ll open up a tab, navigate with “cd” to the project I’m working on, and then run…
rails s |
… to start the server for that app.
This idea carries through to libraries like Sass that involve having processes running that perform updates or other actions whenever you make a change. So if I’m using sass or scss on a project all I have to do is open up a tab in Terminal and type:
sass --watch /scss_folder_path:/css_folder_path |
And then sass will sit and wait for me to make changes, compiling them into normal css files as I go. Now, this is just the bare minimum line to get sass working. It comes with a lot of options built in for how you wish your css to output so I definitely recommend going and taking a look over at the documentation.
Git & Github
Why Use Git?
Here’s a list of just /some/ of the reasons to use Git:
- Keep track of changes
- Roll back to previous versions/commits of your site (VERY IMPORTANT)
- Easy collaboration with more people
- Again, Version Control (HUGE WIN)
Git-ing Down to Business
Now that we have some basic console knowledge down, let’s start doing some Git stuff.
Note: I’m going to assume you have Git installed on your computer. If you don’t, check out the Git page for information on installing Git.
At 12 Spokes, we use Git version control on all of our projects and GitHub for all of our project collaboration. If you don’t use GitHub, I highly recommend it. I’ll be basing a lot of this tutorial around it (though it’s not absolutely needed). If you don’t know what it is, go check it out (no pun intended).
Cloning a Repo
A repository (or ‘repo’) is where all of your project is stored. So to get started, let’s clone a repo from GitHub.
- First, get to the folder on your local machine where you want to keep all of your projects
cd /Projects
- Once there, we want to go to GitHub and copy the path to our git repo, which should look something like this:
git@github.com:12spokes/tandem.git
- Back in Terminal, type in:
git clone git@github.com:12spokes/tandem.git
- Complete! You should see it create the folder for your new repo and download all the stuff that’s inside it. Congrats—you now have a git repo of your very own!
(PS: if you don’t have any repos that you can clone down to your machine, you can just create a new one for yourself by going to the directory where you want it to exist and typing:
git init
and then you’re ready to start making changes!)
Commits
Just like other version control systems, Git is built upon the idea that you make changes and then commit those changes. Think of a commit as a type of milestone or a marker; it’s a collection of file changes, additions, and deletions that you’ve decided to group together because they’re all focused on the same thing. We use these commits not only to see what’s been done, but also as points to roll back on. For example, if we’re working on a site and commit some new changes but realize that something isn’t working we can roll back the website to the previous commit when things were working. Get it? Good. Now let’s do it.
- Get to the repo you want to work with
cd /path/to/repo
- Open up your project in a text editor and make some changes. Save those.
- Go back to Terminal and type in:
git statusYou should see those files that you changed listed
- Right now they’re on an ‘unstaging’ side of Git. One of the best things about commits is that you can choose what you want to commit, so you can logically group things together that are related to one another. For the sake of the tutorial we’re going to go with everything though. So we want to:
git add -A
This will ‘add’ all of those changes to staging, and make them ready to commit.
- To commit, type in:
git commit… to just commit everything, OR (preferably)
git commit -m 'This is a message saying what I changed'
… add ‘- m’ to the end of it to add on a message describing what you did in that commit. I HIGHLY recommend adding a message, because if you leave this project for a while and come back and need to find something you’re going to be very grateful for those notes.
- You’re done! Congrats! You made your first Git commit.
Push-me Pull-you
If you’re using something such as GitHub to store your git project outside of your local machine you’re going to want to get friendly with pushing and pulling.
It’s good practice to pull down any changes from the remote repo first (say, for instance, if more than one person is working on the project). Pulling both gets the changes from the remote repository and then merges them with the copy of the repo on your local machine. To do this (get to your project directory) and type:
git pull |
Now that we’re up to date, let’s say we’ve made changes, committed those changes and are ready to push back up. It’s as easy as…
git push |
This will push any commits that you’ve completed.
Conclusion (for now)
That’s it! You’ve tackled your first Git project! It wasn’t as hard as you thought it would be, huh?
If you’re ready for more, stay tuned for Part 2 of the article where we get more in depth with more awesome Git abilities; such as, Forking and Branching and Stashing!! Oh my!
Protips:
- On a mac you can drag and drop a folder you want to use after typing in ‘cd’
- Soon as you start typing the name of a folder you can quickly finish out the name by pressing ‘tab’
- Commit frequently! If you find you’re at a good stopping point it’s a good habit to commit those changes.
- Sometimes it might be nice to look at what changes were made in your commits or before you commit. GitX has a nice interface for seeing these differences.