BEDA: My experience with Git and Bitbucket

Every day you say? I guess that includes today then. Warning: today’s post contains 100% geek talk. You have been warned…

<geektalk>

Since the beginning of April I have started using Git as a version control system for my code. And there goes half of my readers…

As some of you can imagine, my PhD involves a hell of a lot of coding, predominantly in C++, using Eclipse, but also occasionally Visual Studio (which I must say is 1000x better than Eclipse, if only I coded in Windows more!) I also dabble in MATLAB, for drawing graphs mainly, and because I am a lab demonstrator for a course that codes exclusively in MATLAB. Recently, the odd bit of PHP (because it’s really good at HTTP and XML stuff), Java for Android app development and MySQL for odd bit of database gubbins.

As you can imagine, when a project gets going the complexity of merely managing all these tools across multiple platforms and devices can become quite a job in itself. For which Dropbox comes in very handy. But Dropbox can only really store the latest version of your code, which can be a pain if you break something after a day’s work as is too often the case. This is where version control, and Git in particular for me, comes in.

In essence, version control is a way to keep track of changes to your code as you write them, always allowing you to go back to an old version if need be. Even better, version control systems can handle your code “branching” so their are several active versions being worked on at the same time – like if you want to work on a new feature, but you don’t know how it will affect the rest of the code. Then, once you’re done with a branch and you want to put it back into the main version of your code, the version can do that for you – managing all the pesky differences in the files so you don’t have to worry about any progress being lost from either branch since the split. This isn’t just useful for coding projects, but really any project – websites, books, large collections of documents. And the more people working on a project at once, the more valuable the tool will be for managing progress and making sure nothing gets lost or broken along the way.

Those in the know will know about Git and SVN, and the eternal debate as to which one is better. I ended up choosing Git not because I needed the flexibility of a distributed system, but because it’s the new kid on the block and it’s got a big following since its release. My past experience suggests that the older, and therefore more common, standard is probably going to be superseded by the new kid at some point, and the only reason it’s a slow process is because people have got used to one system, and the hassle (and risk) of migrating their data is just not worth it – after all, if it ain’t broke, don’t fix it. But as I have no allegiance to either side,  I opted for the new kid. If that decision comes back to bite me at some point then so be it.

Next I needed to find a place to store my central repository, for which I was recommended Bitbucket.org. Having used Atlassian‘s bug tracking tool Jira extensively while on placement, I knew I could trust that the interface would be clean, and the product would work very reliably. And I got started. At first it took a while to get a hang of the commands, all a little confusing for a newbie, so I’ll spell it out here:

  • Pull – get’s the files from Bitbucket and puts them in your local repository ready to work on.
  • Commit – The action to save a state to your local repository.
  • Push – update’s Bitbucket with all the changes you’ve made.

All this fetch, check in, checkout, merge, etc. stuff is usually not required (at least that’s what I’ve found). And I’ve found it to work really well!

Capture

That is the view showing my most recent commits. The beauty of Bitbucket, as well as allowing you to do all the version control-y things like reverting back to an older version of your code, is that you can make issues that you intend to fix or a list of features you want to include, and then reference them in your commit message – which then automatically provides a link to that issue so you can see the history. Pretty cool.

There’s also a wiki function so you can make notes about what you are doing, but I haven’t really played around with that yet. I haven’t even created a branch for my code yet, I feel like there’s still a lot of potential to uncover. Even then, this step has already allowed my workflow to be far more structured, as it encourages you to comment on what each commit does – a very helpful way to see how you’re getting on. It’s also effortless to sync my code between my work machine, my laptop and my home desktop just by using Git commands to get the most up-to-date version in minutes. No more syncing issues!

</geektalk>

until tomorrow x