Ben's blog
Software development, games, and all that jazz
Home
Archive
Posts
Pages
Search:
Edit Post
Title:
Body:
<p>Subversion is good, don't get me wrong, git is just better! In a nutshell, git is a fast distributed version control system, which supports a much more flexible style of development than Subversion. The two features that prompted me to switch were its distributed nature and its support for branching.</p> <p>The distributed part is interesting; instead of checking out "the latest version" then checking in your changes, you make a complete clone of the repository (including history), do whatever you want with it, then merge your changes to wherever, you want, however you want. The main reason this is interesting to me (and the main thing that prompted me to use git) is that it means I can work completely 'offline', in that I can view full history, make commits, branch and so on without having access to the server. My server is actually an ordinary desktop PC that dual boots into Windows, so sometimes it's not available, and being able to still work properly when it's not on is brilliant. Using Subversion, I would end up building up large changelists whilst waiting to be able to commit, which is a bad thing. Additionally I wouldn't be able to view history or revert anything to a previous version, which are two things that are needed more often than you'd think.</p> <p>Git's branching is also very useful to me. It supports fast and local branching and merging; branching is a lightweight operation, you can have branches that are local to only one repository, and merging is pretty brilliant.</p> <p>I tend to flit between tasks depending on how I feel when I sit down to do some work. Sometimes I'll want to do some refactoring, sometimes I want to work on a new feature, sometimes I feel like making some new art. Under Subversion, one way to do this would be to work on all of these in the same working directory and selectively commit parts of that when they are ready. That's dangerous because it's then impossible to test changes in isolation - I may end up checking in something that depends on something I'm not checking in. It also becomes a pain when changes overlap, as you then can't selectively commit anyway.</p> <p>You could also save changelists and apply them when you want to do some more work, or commit, but then you're losing many of the benefits of source control, in that each of these features is effectively now one version, and they're not backed up on a server.</p> <p>Another way to do it would be to create branches and work within those, but Subversion doesn't do branches very nicely. Branches are basically just a dumb copy of the whole working directory to another directory, and as such are checked in to the main repository visible to everyone. With git, you can quite easily create and switch to a new branch, do some fiddling, switch to another branch, fiddle some more, merge the two branches and commit the result. This is perfect for me, and is exactly what I do, except with several days between each step! You can commit several times to each branch, you can store work in progress (via git-stash) so you don't have ugly half-finished commits, and the 'main' repository (the central server visible by everyone) needn't know about any of this. You just push to it once a series of commits that make up some number of features is deemed 'done'.</p> <p>Of course there are plenty of other niceties that come with using git, but these were the two most important things to me.</p> <p>I'll go into exactly how I use git in my next git post. Stay tuned :)</p>
Tags:
development
Body markup:
Plain Text
Textile
HTML
Markdown
ReStructuredText
Draft: