GitHub is Sexy

GitHub is an online Git repository hosting service that is freely available to anyone who wishes to share their Git managed projects. The service is very similar to SourceForge and Google Code Hosting, but because GitHub uses Git as its source control management system it offers a variety of advantages over other code hosting services.

To begin with, by using GitHub the barrier for working on and contributing to open source projects is significantly reduced. In traditional centralized models only certain developers are given commit rights to any given project repository. This creates a problem however for those developers who checkout the project and make changes. Those developers have no way of keeping track of their local changes and history unless they import the project into their own centralized repository. Doing this however means that the developer will lose the ability to easily synchronize their local project with the original project.

This problem goes away when using Git because all commits are local. You can checkout a project from GitHub, makes changes as you wish, and commit them to your local repository. This allows you to keep track of all of your changes and their history. If you want to synchronize with the original project's repository you simply need to issue a "pull" command to get the latest updates. As a bonus, if you come up with some feature that you think is particularly useful to the original project, you can ask the owner of that project to issue a "pull" request from your repository so your changes can be merged back into the master project.

Setting up your own remote Git repository is not that difficult, but GitHub adds a great web interface on top of Git that feels very much like a social networking site and serves as a platform for developers to share and contribute to each other's projects. A lot of big name open source projects (especially in the Ruby community) are hosted on GitHub including Rails, Merb, and Script.aculo.us so developers can feel confident that the guys at GitHub have their act together. GitHub also offers a variety of other features including private repositories (for a fee), a developer API, and integration with other services including Basecamp, Lighthouse, and Twitter.

Git in Practice

It's highly unlikely that a developer will be able to get their current project team to switch version control systems overnight, but with Git you don't have to. Git has powerful migration tools that can be used in conjunction with other version control systems, especially Subversion. Current Subversion users can use Git to manage the source code on their local machine while still staying in sync with their team's Subversion repository using a built in Git command called "git-svn". The git-svn command allows developers to "push" and "pull" commits to and from a centralized Subversion repository. This gives developers the power of local branching/merging capabilities using Git without forcing the technology on their team members. In fact, no one even needs to know that Git is being used.

Git, it's not for everyone

Git is a pretty incredible tool, but it is likely not going to be championed by all developers. To begin with, Git's learning curve can be a bit steep especially when compared with other version control tools. Developers who desire to give Git a shot should be very comfortable working with the command line because Git's visualization support leaves something to be desired.

Git was created by Linux kernel developer Linus Torvalds so it may not come as a huge surprise that Git support on Windows is a bit lackluster. I would guess that a majority of developers use Windows in some capacity so having a tool with weak Windows support is likely to hinder the adoption of that tool. Fortunately, there is a project called MSysgit which allows developers to use Git on their Windows machines. I've personally used this tool on my Windows XP laptop and find that it works pretty well.

Conclusion

Minor drawbacks aside, Git is a pretty amazing tool for source control management and will be the one that I use for my future projects. Its distributed nature, speed, and branching/merging capabilities make it a great tool for managing source code changes and revision history.

Distributed Source Code Management

Git is a distributed source code management tool which means that there is no centralized source code repository. This is a fundamental shift in the way source control is handled by systems like Subversion, CVS, and Perforce and is probably the most challenging concept to grasp (it certainly was for me) when first learning about Git. Version control using a centralized model is useful for things such as sharing code among developers, providing a history of changes to the code, and backing up data in a single location. However, since Git does not use a centralized repository, a few obvious questions are raised about the Git's workflow model. Questions like:

Where are code commits stored?

All code commits are stored on each developer's local machine. Everyone has a copy of the entire repository and all of its history.

How do developers share code?

Developers share code with Git by executing commands called "push" and "pull". Issuing a push command will push changes made in your repository to another developer's repository. Conversely, issuing a pull command will pull changes from another developer's repository into your repository. This may seem strange at first, but it actually ends up providing developers with a lot of collaborative power. For example, instead of checking code changes into a central repository for everyone to see, two or more developers can share code with one another directly in a controlled fashion by pushing and pulling changes to and from each of their repositories respectively.

How are backups handled in Git?

If all of my code commits are stored on my local machine and my hard drive fails, wouldn't I be in a lot of trouble? Not with Git. If you are working by yourself, regularly backing up your repository using rsync, Mozy, Time Capsule or some other backup system will allow you to completely restore all of your work. This is because Git stores all code revisions and history within each repository.

If you are working with other developers you simply need to clone their copy of the repository. In this sense, Git is actually incredibly fault-tolerant in that it provides geographically redundant archives of a repository because each repository is essentially a mirror of the entire project.

Finally, you could use one of the many publicly available Git repositories including GitHub and repo.or.cz.

Git is Blazing Fast

Since all commits, branching, and merging operations are local, Git is fast. Real fast. Unless you are pushing or pulling code there is no network to worry about. Increased speed means developers can be more productive because they don't have to spend time waiting for costly repository operations to take place across a network.

Git Makes Branching and Merging Easy

In a centralized version control system branching and merging can often times be a source of frustration for developers. All branches must live in the centralized repository and are likely viewable by other developers on the team. If enough developers decide to create branches on the centralized server the repository can quickly become bloated.

Git takes a different approach. Branching and merging in Git occur locally. This dramatically increases the speed in which branching and merging can take place. In addition, a single developer can create and destroy as many branches as they desire without having to worry about polluting a centralized repository. Experimental features can quickly and easily be tested by creating a branch from the current working copy's "master" branch. If the code produced in the branch proves worthy, it can be merged back into the "master" branch. If the code from the branch ends up being useless, the branch can simply be deleted and no one ever needs to know that it existed.

Part 1 Wrap Up

Sunday I'll post Part 2 of my "Getting it on with Git" series where I'll discuss GitHub, Git in practice, and why Git may not be for everyone. Be sure to check back then!

Useful Links

Official Git Site

Git Cheat sheet

Google Tech Talk on Git

Linus Torvalds on Git

GitMagic Book