Git Tutorial

Git is a piece of software that manages changes in a project over time. Software like Git is commonly known as "version control" tools.

I’m willing to bet you’ve saved files with names like this before:

I know I have. These types of files tend to accrue when you want to keep track of the progress of something you’re writing over time, or if you want to “save your place” in case you need to backtrack later. With Git, you don’t need to resort to these barbaric tactics.

Likewise, have you ever had a conversation like this? [conversation between people with merge overwrite] All your work just went down the drain because some moron was working on the same file as you.

Git in its natural state is… a little scary. [screenshot of git log] Fortunately, the people at GitHub have developed a much friendlier face to Git called GitHub Desktop. GitHub Desktop is designed to give you all the powerful features that Git offers, without requiring you to learn the somewhat arcane commands that raw Git uses. You can download GitHub Desktop for Mac, Windows, or Linux here. I’ll be using GitHub Desktop to explain the features of Git to you.

To use Git, you’ll need to be familiar with a few basic concepts: committing, pushing, merging, and branching.

Committing is the act of saving the entirety of your project in a given state. It’s the equivalent of making one of those “FINAL copy”-type offshoot files I mentioned above. With Git, you only see the latest version of your file at any time and can treat it just like any other file. All your history is invisibly stored in the Git repository and can be recalled at any point¹.

You can commit your project at any time by doing

#INSERT COMMIT TUTORIAL

When you want to share your work with other people on your team², you’ll push it to a different machine, usually a central server like GitHub’s³. Once you've pushed your commits to a server, other people can pull those changes down to their own computer.

#INSERT PUSHING/PULLING TUTORIAL

If you and another member of your team have been editing the same file, Git will merge the two files when one of you pulls in the other's changes. Most of the time, Git is smart enough to do the right thing and merge the two files together without issue. If both you and the other team member have changed the same parts of the same file, though, you might get a merge conflict. That's Git's way of telling you that it needs help figuring out which changes you really want to keep. Despite the antagonistic name, a merge conflict isn't anything to be worried about; merging a file instead of destroying work you've done is exactly what Git is designed to do.

#INSERT MERGE CONFLICT TUTORIAL

Sometimes you'll find yourself wanting to spend some time working on an offshoot of the project without messing up what people are doing to the main part. For example, perhaps you're adding a new commenting system to your website, but want to let the rest of your team continue to edit pages until the new system is ready. This is where Git's branches come in handy. A Git branch allows you to peel off your work into a separate area without affecting the main branch (usually called "master"). When your branch is finished, you can easily merge it back into the master branch.

#INSERT BRANCHING TUTORIAL

Now that you know a few basic Git concepts, it's time to walk through how a typical project might use Git.

##Footnotes

1: How it actually does this is a complicated discussion that I won’t go into here. Mainly because I don’t know how it works myself.

2: Or make it available somewhere else just in case your computer explodes.

3: Let me take an aside here to "teach the controversy". Some people believe using a centralized Git server goes against the decentralized design of Git. These people are idiots.