Update on experiences of using Git


I’ve been using Git now for a few months almost exclusively. When I last blogged on it I’d been using it for but a few weeks. Since then I’ve come to the conclusion that it should be the de-facto choice for source control. This might be obvious to those of you that use Git on a regular basis, but there are obviously many people out there using other source control systems in the .NET world – I would guess primarily TFS and Subversion.

There are, to me, two main benefits to Git. Firstly, it’s incredibly lightweight to start using. There’s no requirement for using a source control server, so you can easily start using it for local projects. It’s also extremely quick – check-ins are virtually instant, whilst you can seamlessly switch between different revisions of code without any network connectivity instantly.

It’s also very powerful, with excellent branching and merging features; I’ve started using branching for features much more now, thanks to the ease of use in git and the aforementioned ability to quickly jump around the source tree. In TFS, getting an “older version” of code means checking out that version of code using a rarely-used dialog, or in SVN finding the particular version of code first, download that version to a separate folder etc. etc… In Git, with e.g. Git Extensions, all I do is visually look down the tree, see the version I want to look at, and open that revision. It’s no surprise that the overall TFS suite now supports Git for source control and VS has started to get some support for it as well.

Online source control repositories such as GitHub (free for public projects) and BitBucket (free for small projects) mean you can get up and running with a central repository to collaborate with others almost instantly.

Whilst on the subject of tooling – I’ve been using GitExtensions more and more and found it powerful and much easier to use than faffing with the command line.

There is indeed a learning curve for doing more than just basic check-in / get latest version of code – primarily around the ability to instantly move from one revision of code to another in the same physical folder – but once you “get” git, you’ll not look back.

In conclusion, if you’re using TFS or Subversion, I would seriously recommend looking at moving to Git for new projects – the productivity gain you can get from improving your release process e.g. Release branches, hot fixes etc. will make it worthwhile immediately in addition to the day-to-day developer gains.

Better git integration for VS 2012


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.

Tooling

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.

Conclusion

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.