Breaking Free of TFS with Git (Part I) - The Case for Git Chadwell.Jeffrey
What is Git? "Git" is a version control system, similar to TFS. It shares several capabilities with TFS, such as branching, merging and labeling. It was originally written by Linus Torvalds in 2005 to handle the Linux source code. Since then, its use has spread and it is now one of the major version control systems used by open-source projects. What makes Git different? Even though Git shares a lot of functionality with TFS, it has one very important difference. TFS is a centralized version control system, meaning that there is only one copy of the "official repository." All of the file versions, the check in notes, the branches, etc. only exist in one place. Git, on the other hand, is a distributed version control system. In other words, every developer working with a Git repository has an entire copy of the repository, including all of the file version, all of the check in notes, all of the branches, etc. (In practice, there is usually one copy that's considered the "official repository," but it's not necessary to set it up that way. And each of the developers still has his or her own complete copy of the repository.) Okay, so TFS is centralized and Git is distributed. What advantages are there to a distributed model? Here are three: It offers redundancy. Since every developer has a complete copy of the repository, it's a lot easier to reconstruct the "official repository" should it somehow become corrupted. It makes distributed development a lot easier. It's no big deal if you have a team distributed over multiple locales, since each team member has his or her own copy of the repository, and since it's fairly easy to keep all of the copies in sync. It scales up nicely. With a centralized repository, each new developer means another person accessing the central repository for version control-related operation. This is minimized with a distributed repository. The only time a developer has to interact with a remote repository is whenever either copy of the repository needs to be updated. Otherwise, the developer can work independently. But my project uses TFS. Why would I even try to use Git? Have you ever worked on a feature that was so large or complex, it took several days to complete? And during those several days, did you check your code in regularly, or did you wait until it was all complete so you didn't break the build? During that time that the code wasn't under TFS control, did you ever worry that you might lose your work and have to start from scratch? If you're like most people, you didn't check your code in until it was done, and you probably worried about losing your work and having to start from scratch. So how would Git help with this? Before you started your work, you could create a Git repository to hold your "work in progress" until it was ready to check into TFS. That way, you'd have multiple checkpoints you could go back to in case you messed something up along the way. And once you were finished, you could check the final results into TFS. Now, let's change that scenario a little bit. Instead of working on one large feature, you're working on several features. How does Git help with this? With Git, it's very easy to create, use and destroy branches. In fact, that is a major part of the Git way of doing things. So you could create a branch for each of the features you're working on (and possibly share those branches with others who are working on the same feature), work on the features independently, merge them back into your master branch when finished, then delete the branches. And since you control the branches, you always know what feature each one corresponds to. I'm sold. Where do I find Git? That depends on the operating system you're using: Mac OSX: The easiest way to get it for OSX is to install homebrew, then use it to get Git. Linux: This is probably the easiest one. Just use the package manager for whichever Linux distro you're running to get Git. Microsoft Windows: You have a couple of choices here: Download and install msysgit (Git for Windows). For the most part, you should accept the default options when you install it. However, on the "Select Components" screen, you should make sure both "Git Bash Here" and "Git GUI Here" are selected. On the "Configuring the line ending conversions" screen, you should make sure that "Checkout Windows-style, commit Unix-style line endings" button is selected. (This is the one I use.) Download cygwin and use Git from there. Cygwin doesn't install Git by default, so you'll need to make sure the Git package is selected during installation. Git is command-line oriented, and it's better if you learn to use Git this way, but there are a few GUI front ends you may want to check out if you're not ready to give up your GUI access: Github (a public Git repository for open-source projects) has some GUI front ends for Mac and for Windows. Atlassian also has front end called SourceTree for both Mac and Windows. There's also one other product called Git Extensions that's just for Windows. If you install this one, it'll add a "Git" menu item to Visual Studio so that you can access Git Extensions from there. What's next? In my next posts, I'll go over some of the more important Git commands and try to give you a feel for the Git way of doing things.