This is more narrative and concepts than helpful how-to, but if you stumbled upon this by accident hoping to find technical guidance, it seems only fair to direct you to some really good sources for that sort of thing early : )
http://www.viemu.com/vi-vim-cheat-sheet.gif – vi cheat sheet, if you use git bash, you’ll need this for merging
http://git-scm.com/documentation – a great source for starter guides
http://kylecordes.com/2008/04/30/git-windows-go/ – a good blog for starting out with msysgit for Windows.
Why Git?
The Open Spaces at DevLink confirmed for me that the cool kids had moved on from SVN and onto Git. More importantly, the cool kids were using GitHub, everything else quickly becoming passé. For a long time I was “in like” (love being too strong a word) with CodePlex because, hey, TFS commits are so simple that you can almost commit by accident : ) At any rate, without reading much first, I messed around a little with Git Bash, realized I should stop my impersonation of an illiterate developer and learn more first. After talking pestering the heck out of Evan Hoff at lunch one day, I learned this (and I read some too).
Git Is Decentralized Source Control
I’m still not sure I entirely grok why, but Git isn’t about a one true repository. It’s actually the opposite. Instead of one repository for the code, it seems Git encourages 1 repository per contributor to a project. Not only that but there’s a “staging” area (transparent to you mostly) that code gets added to pre-commit to your repository.
You Don’t Push, They Pull
If everyone has their own repository, they can have complete control over what does or doesn’t get added. This means if you want to contribute, you just make your repository accessible and the other repository owners will perform a pull operation from your repository. I think this is a really nice model for open source projects because it allows you to commit your changes, have them available to the community yet keep the original(s) pristine until the owner of the original(s) decide they like your codes.
Branch Like … The Wind?
The branching experience in Git is instant win. Not only does Git Bash include your current, active branch in the prompt you can branch and change your active branch very easily. But why is it easier/better/faster? Because your active branch is always in the same directory. Not only that, Git has something called stashes which are analogous to TFS shelvesets only cooler because I said so. The fact that Git magics branch code in and out of the same directory structure greatly reduces the branch management overhead.
There’s a Whole Lot of Forking Going On
It’s like I said to Evan during his attempts to explain Git to me initially, “I feel like a procedural developer trying to learn OOP”. The good news is that it’s not quite so drastic and that the more you use it, the more comfortable you get with it, the more natural it feels. The one thing I’m just now getting the hang of is the idea that with things like GitHub, you fork to collaborate rather than having multiple contributors on a single repository. It’s definitely an interesting change. At first I thought perhaps all the forking would make more work for repository managers, but the more I think about it, the more I convince myself that it’s probably not additional work at all. I’d definitely be interested in hearing from someone like James Gregory manages to know what’s going on (even at a high level) in the 60 Fluent NHibernate forks : )
I’m still trying to get my head around some of it but I’m definitely liking it the more I get the hang of it…
Tags: git, source control