GIT for Subversion users on Windows
A visual tutorial for the rest of us
Introduction
Motivations for using GIT
For 10+ years, we've had a central repository for our main corporate product, using Subversion. (The past before that is shrouded in indecency). Initially, it was a revelation. Today, we've all come used to it: it still works great, but that is it. There was little momentum internally in changing it: you know the saying never change a running system.
However, me and some of my colleagues are constantly travelling to customer sites: and that often means working offline, without access to the central SVN repository. Now, that doesn't sound too bad, and anybody that has been using SVN for some time will have been in that scenario at one point or the other; but really if you think about it there are three related problems with this:
- M1: No going back: I run into this embarrasingly often. I change code, compile, change some more, needs more changes, run off and get into a hacking frenzy and before the end of the day I have changed so much code (and so much still to go) that I realize this is never going to work, giving me two really bad choices: throw away everything, or not meet tomorrows deadline.
- M2: No file history: say a file has changed from the last time you saw it and you look at it in amazement, wondering how on earth one of your colleagues could have come up with that convoluted piece of something, whatever it is: you don't see the history of the problem, you don't see the developers comments on what she did and so on.
- M3: Not committing often enough: actually, I cannot commit ever when I am offline.
If you think about it, these scenarios completely defeat the original purpose of having a SCM in the first place:
- M1: No going back: Your SCM was supposed to allow you to revert changes to a known state
- M2: No file history: Your SCM was supposed to show you the history of all changes to a file
- M3: Not committing often enough: Your SCM was supposed to help you in keeping changes minimal and being able to logically group them
Actually, it is much worse than that. Even if you go to the office each and every day and work exclusively online, you will run into M3: Not commiting often enough. Because on Subversion the tendency is to commit only when you have checked the code yourself, proven that it works. Mostly you do it in big increments: especially if the code is interconnected. But you cannot just commit small changes because chances are it could break other peoples build, and people don't like that. So really, on Subversion you commit more when you have to, not when you should.
For this reason also M1 and M2 bite you in online mode: there is no history, so there is no log file, so you either commit all your changes or none (well, mostly).
GIT promises to change all that, and we'll see below how it does this.
Motivations for writing this tutorial
It took me a long time to "get it", and it was quite a bit frustrating getting into "git". Now, of course I have a vested interest in saying this, given that I am just writing yet another tutorial, but let me maybe spill out my reasons more clearly. There seem to be mainly two sorts of GIT tutorials:
- Those for experts. GIT is an incredibly powerful tool, and I have barely touched a fraction of its features. I am not saying Second System Effect, but it comes close. One problem with that is that most of those expert tutorials are for Linux users. Now, I work on Windows. Go ahead, blame me: but that is the corporate environment I am in, and things are unlikely to change for the forseeable future. Because this document should also help my colleagues, a Linux command line tutorial wouldn't have been of great help, would it?
- Those for subversion users. Well, the first one Google finds (as of today) says it is outdated and not maintained any longer, and the next two links are a cheatsheet and a technical comparison. Furthermore, the "GIT for subversion" type of tutorial often tried to set one (command line) command next to the other (command line) command, lacking a lot of the conceptual background.
Furthermore, GIT is like a moving target. Write a tutorial, wait half a year, and enjoy the warm fuzzy sensation of an out-of-date tutorial that won't work and frustrate your users as you go along. The GIT community has no problems throwing away the old and forcing you to move along. In one way, this is all fine and good (GIT is free, developer work without pay and are free to do whatever damn hell they want to), but if you want to get into GIT it can be a major frustrating experience anyway.
So one day sufficiently annoyed with my own seeming inability to 'get git', I sat down, worked it all out, and tried to write something up that will hopefully be helpful for my target audience, which hopefully will include YOU.
Table of contents
- Introduction - This page
- Chapter 1 - Getting started with GIT on Windows
- Chapter 2 - Migrating a project from SVN to GIT
- Chapter 3 - A look behind the iron curtain of the GIT man pages (PLANNED)
GK, Sept. 14, 2014