cover


Getting Your Git On: A Beginner's Guide to Git


Updated: March 31, 2020

What is git anyway? Short answer: version control. Long answer: Think of it as having unlimited undoes 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. As a result, I’ve vowed to always use source control, regardless of how big or small the project is.

Somethiing

Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.

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.

💡
Note
Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.

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 user.name "John Doe"
$ git config --global user.email "john@doe.org"
$ 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 Terminal. 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.

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 initialize 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.

++ NOTE ++ 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.

Status

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

git status

Git will put your changes into three main categories:

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

Add

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

Remove

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

git rm something.html

Commit

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 commit message longer 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.

Log

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

Remote

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 git@bitbucket.org:ahhacreative/git_blog_post.git

OR

$ git remote add origin https://ahhacreative@bitbucket.org/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:

tower remote

http://selfteach.me/wp-content/uploads/2016/06/tower_remote.png

$ git remote add BITBUCKET git@bitbucket.org:ahhacreative/git_blog_post.git

You can see a list of all your remotes:

$ git remote -v

git remote

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

push

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.)


Comments