git seems to be everywhere these days doesn’t it. Everyone is using it, and looking for any excuse to blog today, I wanted to share both my early experiences with it, and the new Microsoft git plugin for VS2012.
Initial thoughts on git
Pretty much like everyone else, I imagine. Branching is much easier to do than with other source control systems that I’ve used – I’m talking TFS, SVN (and I suppose SourceSafe as well). There are many reasons for this I think – the biggest one is the fact that when you pull down code, you pull down the entire repository i.e. all history of the repository. This means that you can do things like rollbacks, checkins, branches and merges all locally – when you’re happy with your changes as an entire piece of work you can “push” the lot in one go to your remote repository (remote repository = TFS / SVN-style central source control server, although with git it doesn’t quite work like that).
It also encourages more frequent checkins since you’re doing things locally, so part of the “mental block” of checking in centrally is removed. You can do things like perform multiple local check ins, and then before pushing to the remote repository, convert those many check-ins into one check-in.
Because branches are much easier to control in git, you may find yourself doing things like feature branches more often. Oh, and there is no support for a “single check out” mode like you have with TFS – hopefully those days are beyond all of us!
git also performs quickly – check-ins happen pretty much instantly as they are local, and you can instantly switch back to an older revision of code with a single command – no complicated rolling back and so on. In fact, it’s so easy to do you might be surprised by it at first – you rollback or switch branches, and VS instantly says that files have been changed and updates.
This is all very nice, although I have also struggled with some aspects of git – firstly it blends concepts like merging and check-ins, so there’s a slight learning curve there, as well as introducing the idea of “rebasing” – which essentially is the merging of two branches into one so that they appear as though they were a single set of ordered check-ins. Secondly, I’ve had one or two issues when I’ve somehow completely trashed my local repository, forcing me to completely clean the repository and “start over”. Once I lost a couple of hours’ work – not much fun.
Overall, having used git, I must say that I do like the features it offers and the possibilities for helping teams of developers improve their day-to-day processes. It’s lightweight to set up, powerful, and fully embraces the “offline” mode of working rather than the “if-your-network connection-is-slow-then-VS-will-run-like-a-dog” way that TFS operates, which I nowadays find very frustrating.
This is where things go a little awry. On the Windows platform, git has several options for managing your code: –
- Command Line. This is how you talk to git under the bonnet. Many developers use this for their source control; personally I prefer something a little more accessible and easy-to-learn, but you can obviously do anything from here. There are several different variants, like command line, powershell etc. but to me they are all basically the same thing.
- GitHub For Windows. This is GitHub’s version of a git source control front end. It’s a fine tool to use for basic operations, i.e. push and pull from remote repositories, check in, rollback etc. It also offers branching and merging, but if there’s any conflicts you’ll just get a “something went wrong!” sort of message. It worked fine for me for single person projects, but for anything more, you might struggle.
- Git Extensions. This is a suite of tools including some Visual Studio integration points, as well as a GUI front-end over the command line like GFW, except this actually supports merge conflicts (via diff tools like KDiff etc.). It has some decent docs and support, so is well worth checking out.
- Git Source Control Provider. This is a free, third-party VS source control provider that integrates pretty well with VS. It doesn’t support branching etc. (at least, I couldn’t find that) so you’ll need another tool to do that – but it does have context menu options in solution explorer to help you out.
- Visual Studio Tools for git. This is still in preview, but is another VSSC provider, so it integrates with solution explorer etc. It also allows branching, integrates with the in-built VS2012 merge tool, and has decent support for viewing history etc. Somewhat annoyingly, it won’t automatically mark added files into a check-in – you have to explicitly do that.
There are simply too many options here for a complete newbie to know which one does what and when to use one or the other. Only the last one comes with a built-in diff tool (although Git Extensions does offer to install KDiff I believe). What you want is a one-stop shop for git really, or at most a couple of installs – one for the core git libraries etc. and another for the UI plugin.
Having used all of these over the past few weeks, I’m still struggling for the “sweet spot” tool. I think any VS dev using git on a daily basis will want VS Tools for git, as it makes 80% of what you will do a doddle i.e. pulling latest changes, checking in locally, pushing to remotes, branching and merging. You can do all that directly in VS. However, you’ll still probably want Git extensions for other, less commonly used tasks. And underneath all of that sits the command line tools.
In practical terms, I struggled initially to do some fairly basic operations like resolving merge conflicts, simply because I couldn’t figure out how to wire up a diff tool. Eventually after faffing with Git Extensions and installing a couple of diff tools I did manage it. Thankfully now VST for Git does make that easier.
I still think part of the work will be for devs that are experienced in TFS and SVN to come around to a different way of source control, but in order to do that, the tools need to be more streamlined and accessible. Those two source control systems have mature UIs – git just needs a bit more work on this front to lower the barrier to entry even more.