Learn to love Git. Part one: The basics.

❤ Yes, you can learn to love Git. ❤

If you’re a designer (or anyone, really) who wants to learn how to use Git to better collaborate on projects with your developers, you’re in the right spot. If you have no idea what Git is, and are curious, just read a bit further and I’ll explain it as best I can.

Git is a complicated system, and can seem overwhelming at first. There are a lot of commands and concepts that take a little practice and time to wrap your head around. But the essentials of Git are relatively straightforward.

In this series of articles I’m going to walk through the basics of Git-based collaboration, with a goal of giving you just enough to be dangerous and some tips and pointers to continue on learning Git.

While most of what I’m going to be talking about will apply no matter what your set up, I’m working on the OSX El Capitan (10.11). And while I’ll try to be as agnostic as possible, much of what I walk through here will be in that context.

This tutorial covers some fairly complicated concepts, and while I’m trying to do that in a straightforward way, there are bound to be some bits that are harder to grasp. Feel free to ask questions via inline comments here, and if you get stuck, don’t worry, just try googling a solution.

It’s also a fairly opinionated article. But it’s one I think reflects some of the most common ways designers would use Git to collaborate.

Expect 30 minutes to an hour to get through each part. Most of part one is set up and install time, and once that’s done it becomes less time-consuming and much more fun.

What is Git?

Well, in a nutshell, it’s an open source version control system that was created to help people collaborate with code. Of course it’s more complicated than that, but that describes the basics.

What is version control?

It’s a convenient and powerful way to safely make changes to something (with Git, this something is most commonly code of some kind) without worrying that you, or someone else working with you, might break something.

For example, let’s say you’re editing a bunch of documents with others. Version control allows you to do that safely, without fear of your changes overwriting someone else’s. In addition, it offers you a history (and backups) of those changes, just in case you need to restore back to an earlier state.

What makes Git awesome?

Git, as opposed to most version control systems, takes a much more comprehensive view of the data it’s tracking. Scott Chacon and Ben Straub, do a great job of explaining the value as a “stream of snapshots” in their book Pro Git:

…Git thinks of its data more like a set of snapshots of a miniature filesystem. Every time you commit, or save the state of your project in Git, it basically takes a picture of what all your files look like at that moment and stores a reference to that snapshot. To be efficient, if files have not changed, Git doesn’t store the file again, just a link to the previous identical file it has already stored. Git thinks about its data more like a stream of snapshots.

How can I collaborate with Git?

Git can be used as a simple single-player version control system, but it’s most powerful when used with others. Through concepts like “forking” and “branching” you, and your collaborators, will be able to work on the same project, even in the same file, without any fear of writing over each other’s work.

So that’s the gist of it. Git allows for safe collaboration on code and lots of other things. It’s core to the work of many developers, but it can help anyone working with developers to collaborate.

Of course, knowing what it is and how it works are two different things. It’s probably a bit easier to show you how Git works than it is to explain all the details up front.

Let’s give it a shot.

Most tutorials I’ve seen walk you through creating a project from scratch. In this one, I’ll cover what I think is a more common situation: collaborating on an existing project.

Before we get into it, you’ll need to set a few things up.

Prerequisites: Git, Terminal and CLI

The first thing you’ll need to do, if you haven’t already, is install Git. There are several ways to do that, depending on what operating system you’re running. This might be the hardest part. Expect to spend some time getting it going.

Because everyone has a different starting point, and there are a variety of ways to get Git installed and a variety of things that can go wrong, I’ll refer you to the comprehensive online Git book to get Git installed. I think the best way for OSX is to make sure you have the latest version of OSX on your machine and then install Xcode.

Once you’ve got Git installed and working, come on back.

You’ll be interacting with Git via Terminal, an OSX application you’ve got on your machine. Terminal allows you to interface with Git via the Command Line Interface, or CLI. Essentially, you’ll be typing Git commands directly into Terminal.

Note: you may be curious why you’d want to learn Git via the command line interface and not some kind of graphical interface. The short answer is that it’s actually easier to grasp the core concepts. There are many other ways to interface with Git, but they’re really geared to more complicated interactions. Plus, the command line isn’t nearly as scary as you might think, and its focused nature can help when learning complex concepts. If learning the command line is something your interested in, check out this guide for designers or this great tutorial from Codecademy. If you want to really go deep, try this great command line crash course.

For now, don’t worry too much about mastering the CLI. I’ll walk you through what you need to do, and it should be as simple as typing commands into Terminal.

To give you an idea of how Terminal works, let’s do a bit of Git configuration with “git config”.

1. Open up Terminal
2. Type the following, adding in your own name and email, then hitting return after each line:

git config --global user.name "whatever name you want"
git config --global user.email "your chosen email address"

You have now configured Git with your name and email. To see what that looks like, and to practice another Git command in Terminal, type the following:

git config --list

You should see something like the following although you may see a lot more. Don’t worry if yours looks different. One of the fun things about Terminal is you can customize the hell out of it.

Git config in Terminal

Now you’ve got Git installed and configured. It’s time to get some “code” to collaborate on. This is where things get interesting.

Another prerequisite: Bitbucket

To show you how Git collaboration works, we’ll need to have a project to collaborate on. It just so happens that I’ve got a good one, but to access it you’ll need to create a Bitbucket account.

What’s Bitbucket? It’s a cloud-based service that allows developers to share their projects with others. It’s also the product I work on every day.

It’s services like Bitbucket that make Git really powerful. You can host, for lack of a better word, your code or project on Bitbucket and then share it out with other people all over the world. For example, the team I work on has folks literally across the globe, all collaborating on multiple projects. It’s pretty amazing when you think about it.

Bitbucket is free and it only takes a few minutes to create an account. Head on over to Bitbucket and create an account with the same email you used to configure Git. Make sure you verify your email. Once that’s done, come on back here and we’ll get you a project to collaborate on.

Forking and cloning a repository.

Don’t worry, I’m going to show you how Git works without you having to dive into code. Along the way I’ll point out some of the benefits and terms, and answer some common questions. We’ll start by forking and then cloning a repository.

You’re probably asking yourself, “What the heck is a repository? And why would I want to fork and clone it?”

A repository (or repo, for short), is a collection of files. It’s the most basic piece of version control with Git. You can think of it as a folder or database containing files with settings and meta-data (like version history, information about what’s changed within the files, etc.) about those files.

There are generally two types of repositories: local repositories and remote repositories. Local repos are simple repositories stored on your machine, while remote repos are those stored on a network or in the cloud. Bitbucket, for example, hosts remote repositories for teams to work on together.

Forking is the process of taking an existing remote repository, in this case a public repository that I own, and making a remote copy of it that you own. You don’t always have to fork a repo to work on it, in many cases you’ll either own your own repo, or be a part of a repo owned by a team. For the purposes of this tutorial, however, you’ll need to fork my repo first.

Cloning (using the command “git clone”) is simply making a copy of remote repo files on your local machine. It’s the first step in getting ready to collaborate on an existing repo.

Let’s do it! Remember I mentioned I was going to show you how Git works without code? How do you feel about recipes?

I’ve got a public project of my own that we can use. All you need to do is fork my repository and then clone it to your machine.

Here’s what you need to do to fork a copy of my project:

1. Log in to Bitbucket and go here: https://bitbucket.org/keithrobinson/the-mason-jar2
2. In the left hand nav you’ll see an item labeled “Fork” — go ahead and click that.
3. You’ll see a screen that looks like the following. Don’t worry about any of those settings, just click the “Fork repository” button and a copy of my project will be added to your Bitbucket. Because you forked it, it’s now yours, and you can do whatever you like with it.

This is what forking a repo in Bitbucket looks like.

Ok, now that you’ve got your own copy of my project you’ll need to clone it — or pull it down from the cloud — to your local machine.

To get that going, open up Terminal and type the following:

mkdir Projects
cd Projects

The first Terminal command (mkdir or “make directory”) will create a “Projects” directory for you. We’ll clone your remote repo from Bitbucket into that directory. The second command (cd or “change directory”) will place you into that Projects directory. Now type the following, replacing “USERNAME” with your Bitbucket username:

git clone https://USERNAME@bitbucket.org/USERNAME/the-mason-jar2.git

Now you’ve got a copy of my project, in a new directory under Projects called “the-mason-jar2”. Simply run the “cd” Terminal command to get into that directory:

cd the-mason-jar2

And you’re in your local version of the project. Awesome. You should see something like this:

You’re in the-mason-jar2 directory!

Let’s run another command (ls or “list”) in Terminal to list the contents of the repository.

ls

You should see a README.md and a folder called “recipes”. The only files contained within are simple recipes in plain text/Markdown format. (Don’t worry if you don’t know Markdown, it’s just a markup language that turns plain text into HTML. It’s easy to learn, easy to read, and mostly straightforward, but if you want to know more, you can start here.)

It’s in this folder where we’ll be doing our work. To do that we’ll need to learn about some other Git concepts: pulling (part of keeping things in sync), making changes, staging, and then committing those changes.

I’ll be covering these aspects in more detail in part two. It’s a lot to take in, so if you’re not ready for more, feel free to ask questions in line here, or leave comments. See you soon.

Did you enjoy this post? Want more of the same? Consider following Designing Atlassian.