30Sep
2008

Tags: ,

When I first heard about Git a few months ago the first thing that popped in my mind was: "Why the hell would I ever want to learn a new version control system?" Subversion works perfectly fine, doesn't it? I resisted at first, but after a few weeks I came around and decided to take Git for a test drive. This is what I discovered:

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

Share and Enjoy:
  • Print
  • Digg
  • del.icio.us
  • Facebook
  • DZone
  • FSDaily
  • Reddit
  • Slashdot
  • StumbleUpon
  • Technorati
  • Twitter
  1. 3 Responses to “Getting it on with Git – Part 1”

  2. Nice article, I just heard about Git recently on Slashdot and this was a great intro. Does is work well on Windows? I hear it’s focused mostly on Unix/Linux.

    By Ninja on Oct 22, 2008

  3. I see now that you addressed my question in Part 2 :). Sorry, jumped the gun.

    By Ninja on Oct 22, 2008

  4. Thanks Ninja!

    By Justin Spradlin on Oct 22, 2008

Post a Comment