To GIT – or Not to GIT

For years I’ve been using DropBox on my various Windows PCs to make shared file access easy… and at work, my PA and I have shared DropBox folders for just as long. And that’s fine for lots of things, it certainly makes access when on location easy, but it is not ideal in all circumstances.

For example two of us have been working on our Arduino and ESP code and we recently decided we needed something better than DropBox, a means of not only sharing files but of knowing when changes have been made and by whom. There’s nothing worse than realising you have completely screwed up a project and you can’t quite remember when or how.

Of course there are ways around this – you can save various versions of a file or project in folders, meticulously named and dated, but, like backups that takes discipline and not many of us are that good at backups!

I was busy working on a new NODE for NODE-RED when one of the developers suggested I could make the program available to Node-Red users via GITHUB. I had of course heard of this but knew nothing about GIT. I’d even USED GitHub, downloading ZIP files of other people’s work but never given it a second thought.

This weekend I decided to change all that and learn more. I have to say it was a bit of a challenge and I don’t pretend to understand it all. This then is my description of how to make life easy. I’m not going to bore you with a load of unique Linux language as I’m not interested in that myself. This is about how to use GIT to your advantage as a Windows user – others may hopefully find something useful too. I’ll assuming you are a lone developer or someone in a very small team and that terms like “versioning” goes in one ear… and out of the other.

What is GIT and why bother?

GIT is a means of storing information, locally and, or on-line (in a “repository”) and keeping track of changes (“versioning”).  Let’s say two of you are working on an Arduino project and you think differently. You both make changes to the software and occasionally agree to put the two versions together. This is the stuff of nightmares without GIT. Oh, so everything I’m talking about here is free and I’m talking about work which might be private or which you might want the public to access.

What is a Repository?

So at least for me, I want to work on the files locally and when I’m done, “synchronise” them with something in the cloud like DropBox – BUT unlike DropBox, only when I decide – and I want to keep track of changes without any effort on my behalf.

Which Repository is best?

There are several and finding out which is best for me was daunting – so to save a lot of trouble, take a quick glance at this comparison.  So it would seem, if you want to be compatible with stuff that’s out there, like plug-ins for your blog etc., the on-line repositories to go for would seem to be GITHUB, GITLAB and/or BITBUCKET.  I spent ages going through the options. If you want everything for free, forget GitHub unless all your work can be public. That leaves GitLab and BitBucket. I spent ages on GitLab and although the instructions on-line seemed easy, every now and then they quickly devolved into instructions that would not work in Windows – or needed various plug-ins that turned Windows into a command-line environment… sorry I’m just NOT into that.

I don’t know where I first spotted BitBucket but I went off to their site – essentially free for up to 5 collaborating users so if there is just you that’s great or you and a small team is also great.  In the end the mental breakthrough for me came with BitBucket. This is not an exhaustive review – there should be just enough here to get you started. I didn’t use any secret keys, just created the account using user names and passwords.

Doing GIT with minimal effort!

When I started off the other day I was faced with public and private keys, a host of new Linux-type commands to learn and after several cups of coffee and lots of blind alleys, DropBox didn’t seem so bad after all, maybe I’d just give this all a miss. And then along came SourceTree.

To make a start,  I went to BitBucket and got a free account – then went off and grabbed SourceTree for your Windows PC. That took moments only.

This really does not get any easier once you get past the initial, brief learning curve. The following describes ONLY what I’ve done and which WORKS for me.

In essence… take a folder on your PC which contains a project – that is, one or more files you are working on. Add a simple text file called README.MD and put a brief description of the project (or not if you don’t wish to – but I decided this was one standard I could handle).

I have a simple library I wrote for Arduino (well, less a library and more a short header) to give me some simple timers for my work – I got sick of preloading and comparing variables with millis() and wanted something a bit more “posh”. I’ll use that as an example as it’s all very simple. So two files – the header file and the readme.md file.. that’s it.

Clearly in order for any system to keep track of file changes and synchronise online, there needs to be some information stored somewhere. You could store it in a program but with GIT the information is stored in the directory itself in a folder called .git  – yes that’s a period followed by the word git. But you don’t have to understand this because SourceTree does it for you.

The next step is to “initialise” that directory – fear not your files won’t be affected and if you want to start from scratch, just delete the .git folder if you change your mind – and I did… a lot.

So – in SourceTree, under “CLONE/NEW” just “Create a new repository” – give it the folder location and a name – my name was “Timing”.  I’d made a directory called GIT (not for any particular reason) and put my project in a file called “Timing”. 

Done. Now I needed a matching online Repository. I went to BitBucket website with my new account and created an empty project called “Timing” – that’s it, nothing more. It ended up with the URL https://bitbucket.org/scargill/timing – that doesn’t get any easier.

I made it public – I could just as easily have made it private.

Back to SourceTree I added in a new Remote Repository. By that I right clicked “Remotes” – “New Remote” and gave the dialog box the URL – it immediately knew what that was. I called it BitBucket. I realised later that you can add as many remotes as you like, commit locally and then just “push” to one or more remotes.  At some point it asked me for username and password then never again.

From that point on it got easier.  I tried making a local change to the “Timing.h” file and almost immediately the program noticed the change.  Two things need to be done at this point. One “stages” the changed files – then “commits” them. Thankfully this can all be done in one simple command – i.e. a couple of button presses. This is of course local – you then have to “push” the files – but then this is just two button presses.

So now to show this in action  I have deleted my Timing repository on BitBucket, removed my .git folder locally and will start from scratch to show you how easy this is to do.

At this point I’m going to make a short video – here it is…. this should make everything clear. Hope you find it useful. http://youtu.be/ZCLVMxvWxrY

Armed with this new toy it is possible to see every change you have committed and hence – if necessary  – to go backwards or even branch off with a completely new version – all without losing a thing.

Update: From scratch on a second computer…

1. Download SourceTree, install and launch – tick all 3 boxes unless you wish to un-tick middle one about sending anonymous data.

2. At this point the program goes off to download and install version control systems. No interaction needed. Say yes to creating default exclude file.

3. Add account – I added my free BitBucket account – you could add GitHub or GitLab accounts – on the first setup I added all 3.

At this point it knows about any repositories you’ve already set up – I said Skip setup…. Did I want to add an SSH key – no – as far as I can tell, certainly with BitBucket – you don’t actually need one.

At this point I dragged my local repositories (same location on both machines as I use mapped drives to my DiskStation) – all done – apart from asking for my username and password for BitBucket the first time I tried an update (and the first time only) no more needed.