You’ve run into it before. You fire up a new project, write some code, leave, come back, and a week or two later decide the approach was all wrong. Code becomes a mess. We try one thing, then another, go back, try again, break things, experiment, wash rinse and repeat. You work on it for a few more days, and realize you were almost right the first time, and now you want to go back. What do you do?
This talk will focus on using GIT as a local SCM (Source Code Management) tool to help alleviate some of the problems we as developers face on a day to day basis in various situations. No cost, no server, no hosting, local versioning, undo forever.
Sanity is a good thing.
And so begins my talk on Git at the first SoCal CodeCamp of 2011.
I know most of you have run into one of the following situations before.
- Your on a large project, and you hate checking in because you might break the build.
- You work on small personal projects (Your in a programming class and have assignments to do) and setting up and or using subversion sounds like a complete waste of time, yet you wish you could never close visual studio so you could ctrl+z back to wherever you wanted.
Bear in mind, almost everything I talk about today can be replicated in some fashion by most of the Version Control Systems out there already. Regardless, my goal is to give you something you can take home today and use tonight to help relieve some stress from pain points you may never even knew existed because you were so used to it. Even just to take the ideas and apply them to your current situation and workflow.
Git was created in 2005 back when the Linux kernel lost their licensing for BitKeeper, and something was needed to replace it besides patches and tarballs. Linus, finding no good versioning system out there, created his own and released it to the community a few months later calling it git. It has several unique features:
- Distributed (which means every repository is a full copy of the entire repository)
- Efficient handling of large projects (Git is SUPER fast)
- Cryptographic authentication of history
- Snapshots entire tree’s instead of individual files
College Dev Story
Sweet. What does this mean for you? Ok, you’re a college student again. You have an project you already thought you completed but find out there’s a new requirement that require a bunch of changes to your code. You think you know what you need to do. If your like me (because this actually happened to me) you pull out the project, maybe make a copy of it, and start partying on the code to meet the new requirement. Two days later, you wish you could go back one day ago, because you introduced some code and made some refactors that are definitely not going the way you wanted. Trouble is, the last copy of your code (if you actually made the copy) was two days ago when you started. Fail.
If your also like me, you also find it a paint to set something up, I really don’t have any desire to install subversion, make a free account somewhere (or God forbid, setup my own server, configure the dns so I can access it offsite, deal with checkout / checkins) because its a school project. Who CARES about a small project when the setup to version it is a pain? So here’s where I wish I knew about something like Git, for this simple feature: I can version my files locally, without a server, without a network, without the version control system interfering with however I would like to edit my code. (Subversion adds a bunch of .svn directories, TFS makes all your files read only (Try saving a file with notepad, it sucks)) Creating a new repository with Git takes less than a second, doesn’t touch any of my files, and when I commit, it tracks all my changes by the cryptographic hash of the content (No more worrying about if my change accidentally got missed).
It would have made it much easier to track my assignments, all of them, even the little scratchpad apps I created to test things and experiment.
Enterprise Sized Dev Story
Now, the other story. In this story you’re a developer on a large project. Say there’s about 30 people working on the same project, broken up into 3-4 teams, each working on a different portion of the application, using a centralized version control solution like subversion or tfs. Everything is fine and dandy until someone checks in something that breaks the project. 29 developers get latest, hit ctrl+f5 in visual studio, and the build fails. So, management gets involved, and now there’s a build server, and a checkin policy that the project has to build using something like the build tools with VS team edition or something like Cruise Control. This goes well for a while until people start realizing that as the systems interact that functions that they thought were stable are suddenly being used by other people and returning values they didn’t expect. So e-mails fly, and now the build server has unit tests and a build validation with unit that must pass.
There’s nothing inherently wrong with having a central server to store all your code, nor is having unit tests or build validation. However, to you and me as developers, it does present a difficulty. How do I develop something without breaking anything while I’m building it? I get stuck between a rock and a hard place. On one hand, the code I’m working on is in an unstable state, some of the unit tests don’t pass, and I’ve been working on said feature for about 2 days. I can’t check-in my code because it’s unstable, but I also don’t want to lose the history of what I’ve been working on.
Enter Git once again. Remember what I said earlier about Git having both cryptographic authentication of history and that it snapshots the entire state of the tree? Well, here’s what this means: I can use Git on top of an existing version control system like SVN or TFS, without affecting what they do for source control, and still keep a history of changes, and backups of those changes either somewhere on my computer, an external drive, or a network drive. And that cryptographic history thing? All it means is that it hashes the contents of the file. It could care less if TFS changes the read only state or about checkouts or checkins, because git is tracking it by what has actually changed.
Hopefully, this enough to get you on your feet and get you started, if you want to get started and play with it (which I’d highly recommend) this post I’ve written earlier should get you up and running with Git, Git Extensions (a UI layer for Git) and Visual Studio.
Another resource I’d highly recommend is ProGit, a book that is also fully online that digs into the details of Git: