One of the things I’ve had to learn on this journey into the unknown is how to use Git instead of Subversion as my version control system. I started by using a personal account to just save the practice I had been doing, but it is SO different when collaborating with others and using it for huge projects! On first impression, I felt that it was overly complicated as a tool and kept doing things that I didn’t understand, and I began to resent it (why bother using something more complicated when Subversion ain’t broke?!)
A colleague then suggested I run a Git Kata at work, aimed at beginners, to get myself (and others in my position) used to at least some of the more basic commands in a much simpler context, so it becomes less daunting when using it in the real world. Not a bad idea, I thought, so I went away, came up with a whole scenario to run through (obviously Harry Potter themed, this time we’re planning Harry and Ginny’s wedding!) and ran the session earlier in the week.
Some interesting things that came out of running this kata:
- I actually know a lot more than I thought I did. When you’re in an environment surrounded by people discussing things, you are bound to absorb a lot of information, and it is only through explaining it to others that you realise how much you’ve actually picked up (reinforced my reasons for starting this blog in the first place!)
- I have grown to love Git! OK, “love” is a strong word, but it’s definitely grown on me since I first used it. Most of the attendees of the kata were complete beginners who were used to Subversion, and had the same concerns that I had when I first started, so I completely understood where they were coming from. However, there are arguments in favour of Git over Subversion even for a newbie like me. My main points in favour of Git over SVN were:
- Git is a much more detached way of working compared to Subversion. Subversion requires everyone to work off the same trunk/master, whereas Git takes several copies of the master in the form of branches, and allows you to test your branch independently before committing to master/trunk. This means that things only get merged back to master when the feature is complete AND TESTED so you don’t end up breaking other people’s code
- You choose how many people work on each feature branch, it could just be you, or you could collaborate with a couple of others. This would mean that the changes you make are visible to the people working with you on that particular feature, BEFORE it is merged into master (trunk in the Subversion world) where everyone can see it, and so you can test your feature first to make sure it all works. No longer do you have people committing half finished, untested changes to the master for the rest of the team to work off.
Here’s a diagram summarising the bare bones of how Git works plus some basic commands:
- Commit messages are SO important. In fairness, this is the case regardless of what version control system you are using, but it was the most common point that I raised to the attendees of the kata.I felt so strongly about this point that I decided to turn this point into a whole new blog post of its own.
If reading any of this has whetted your appetite for trying out Git (or, if you’re an experienced user, having a bit of fun/practising the more basic commands) try out the kata! It can be found here: