For those not familiar with Git - no I'm not being rude. (Perish the ****ing thought!) Actually, 'Git' is a popular version control system for organising software development.
And to be honest, if you didn't know that already, you should probably skip the rest of this post because it isn't going to make any sense. Really this is not a very exciting post at all. Sorry.
That said - as mentioned previously, developers here are getting ready to start work on developments for our Moodle 2-based course website system (aka 'VLE2').
We are using Git to host the code. That's good news because (a) it is probably the best (widely-used) version control system in existence, and (b) it's the same one that Moodle core developers are using. But there are three problems:
- For most (not all) of our developers, their only experience of version control systems has been the CVS-based process we have previously used here. Hardly any have any previous Git experience.
- Git is really complicated (=powerful) and includes loads of new concepts (the basic concept of any kind of distributed version control at all is probably the biggest and scariest of these).
- Git's GUI integration into developer tools (Eclipse) is frankly only about half written so far.
None of these problems are insoluble (we hope). The approach we're taking is to define a very specific way to use the software and the system that avoids as many of the complexities as possible, while retaining the key benefits we need. And to document that in a really clear manner.
The documentation is why I'm making this post. I know there are other institutions who are trying to switch to Git and I thought maybe the documents I wrote about this might be useful as a base to work on for your own plans. Understand these aren't generic documents in any way - they're specifically about our own system and our process and they can't directly be used by anyone else. But if you're trying to help a bunch of developers to switch to Git, you might want to use our documents (or possibly even our process) as a reference when putting together your own material.
Or to put it another way, if you really want a Word document that tells you how to install git on a Windows computer, with like a zillion screenshots, congratulations! This is your lucky day.
There are actually three documents - one about installing Git, configuring Eclipse to work with it, and setting up an account on our Redmine system; one about 'ordinary' developers doing work on the system; and one about lead developers merging in those changes after review.
These have been 'tested' to the extent that other people have tried going through these processes and it worked (of course, the documents were initially wrong, but have since been corrected), but no further.
Of course the most important question regarding all this is... does our process actually work? If anyone's interested in the answer to that, please get back to me in about six, seven months.