git-primer.txt

== What I'm Saying, Basically ==

What is "version control" or "revision control"?
Many of you are most likely already familiar with version control in some form. Just to start off though, I'd like to see a show of hands if you're still using FTP for the bulk of your updates.

Okay, cool. Hopefully by the end of this we will have fixed that.

Version control enhances collaboration and control over source code by allowing you to keep a rich history of all changes made by a single person, or thousands of developers. You can search for when a feature was first introduced, revert back to an older version, and a host of other things which even I admit I'm still only beginning to grasp.

So, what then, is git?
Git is a distributed version control system with an emphasis on speed. If you haven't started using git on any development projects yet, chances are you'll find yourself needing the basics soon enough. Due much in part to the growing popularity of the repository hosting service github which now hosts over 2 million repositories, git is quickly becoming known as (if not in fact already) the de facto version control heavyweight.

There's a number of really solid arguments as to why you should seriously take into consideration switching to Git if you're currently using another popular version control system like subversion.

The first point is that unlike subversion, git is a *distributed* version control system. To take the liberty of over simplifying this, if I may, distributed version control means that we're all on equal footing. In some ways, that's kind of the heart of what open source is, right? Instead of having a single hub (the repository) and many nodes, every developer can act as either a node or a hub because they keep a full copy of the repository themselves.

This change in paradigm is facilitated first by a change in terminology. To get the latest version of your repository instead of running [SLIDE] "svn checkout yoururl", you run "git clone yoururl." When you run git clone, there is essentially no extra information about a given project that the server has that you do not. You have the whole pie. I should mention that git still has a checkout command, but it functions a little bit differently. I'll get to that in a moment.

Despite the fact that when cloning git downloads everything including the entire project history, cloning is said to still be *almost* as fast as checkingout a single version of a project from subversion.

One of the benefits that should jump out at you about having an entire copy of a repository instead of just a single version is that you can do all of your development with or without a connection to the internet after your initial clone. If you find yourself needing to rollback to a certain commit "blob" (as it's known in git), you'll be able to do it instantly instead of needing to initiate yet another download from the remote repository, as you would need to in subversion. Because the repository is local after it's initial cloning, this makes everything including commits, diffs, logs, branches, merges, file annotation and more extremely fast. 

One might assume that because they're downloading the "whole pie" with git clone it might be a bigger download and thus alittle bit slower than a subversion checkout, and while that's sometimes true, the difference isn't substantial.

Even more important than speed, however, is that by having your repositories distributed you do not have a single point of failure. Since everyone that has cloned the project essentially has a full backup of the project data, losing the collaboration server is at very best a relatively minor inconvenience instead of a potentially catastrophic event. This is good news for those who fear the cloud.

With git, instead of needing to create a new folder for each branch you make all you have to do is type "git branch newbranchname" and "git checkout newbranch" to switch to it. From that point forward any changes you make and commit will remain there until you merge it back in to the master branch, if you decide to do so. To switch back to your master branch you just type "git checkout master" and all of your files and folders are back exactly where they started.

To bring your newbranchname feature back into the master branch you just type "git merge newbranchname" while in the master branch, which is the equivalent to the "trunk" you often find in subversion repositories.