A quick introduction to Git

Will Little

At this point in our app development tutorial series we're going to take a moment to introduce Git, a version control system (VCS) that developers use to (1) collaborate with others, (2) ensure every line of code ever written on a project is saved, and (3) hook into automated testing and deployment work flows to make their jobs easier.

[Author's note: I wrote the first couple dozen tutorials in this series a few years ago and I'm in the process of updating the content to reflect the evolution of best practices in the industry. Please comment if you see anything I missed that should be updated. Thanks!]

The key concept to understand about Git — and VCSs in general — is that files are stored in a repository and incremental changes to lines of code made within those files are bundled by developers into commits that are saved (committed) into the repository. These commits can be viewed in retrospect, reverted if there are mistakes, etc..

The standard analogy that drives much of the lingo with VCSs is a tree with atrunk and branches. The trunk is the default “branch” where commits are placed, and often it makes sense to work on a section of code in a new branch to avoid disrupting production or testing workflows.

Why Git vs. others?

While there are plenty of VCSs to choose from (Subversion, Mercurial, CVS, etc…), about five years ago there was a major shift in the Rails developer community from Subversion to Git. In the comments of the Rails blog post that announced the shift, Tim Dysinger wrote:

1 — Git is fast. Others are not. 2 — Git has been in use for years on big projects. It's not new or “unstable” 3 — Git is efficient — it's storage format is awesome 4 — Git has native in-place branch switching 5 — Git's auto merging is awesome

This is a great summary — and thankfully for those using Git as their first VCS experience, these benefits are available right out of the gate.

Later in this tutorial series we'll be diving into cloning, merging, pushing, fetching, committing, reverting, and other actions common for developers when working with Git. It's best to learn these when working with your own code — and like most things — you'll be Googling often to get yourself out of jams. Our overall goal is to help give you a framework to understand so you know what questions to ask at the right time.

For now, try git.

- — -

In our next post we'll introduce a meta-level JavaScript language called CoffeeScript that helps developers do more with less code. Previous post: Ruby on Rails intro.