Practical Series

Understanding Git and GitHub
and using Brackets to manage them

by Michael Gledhill

cover logo
Placeholder

This is my second Practical Series publication—this one happened by accident too. The first publication is all about building a website, you can see it here. This publication came about because I wanted some sort of version control mechanism for the first publication.

There are lots of different version control systems (VCS) out there; some are free and some are commercial applications—just google it. If you do, you will find that Git and GitHub show up again and again.

I also noticed something as I wrote and developed my first publication and used various third party open source software and applications:

  • Normalise.css

  • Lightbox

  • MathJax

  • Prettify

I noticed that all the people developing these applications did so by using GitHub—so, thought I, there must be something in it—best have a look and see what it’s all about.

So I did, and while GitHub and its poor provincial, command line cousin, Git are powerful version control applications, it’s fair to say that they’re also very difficult to understand.

I had a couple of goes at it and gave up each time—Git and GitHub have a pretty steep learning curve, especially Git (the application that runs on a local machine rather than GitHub that is web based). Git is driven through a command line terminal emulator and it’s a bugger to use.

So I did a bit more digging and I found that the Brackets text editor, the one I use to develop the Practical Series websites, has an extension that provides a Git and GitHub interface directly within the Brackets development environment.

This extension (it’s called Brackets-Git) has the distinct advantage that it is easy to use and doesn’t require command line inputs that are counter intuitive and hard to remember.

Git and GitHub, apart from having peculiar (and slightly rude sounding names), also have a wide range of in-house terminology and phrases, things like this:

  • Gist

  • Push

  • Repo

  • Fork

  • Pull request

  • Flirt

  • Flagellate

Ok, I made the last two up, but you wouldn’t necessarily know. It is all very confusing and it’s not that well explained.

It takes a long time to get to grips with Git—to such an extent that I had to make lots of notes, do a lot of reading around the subject, try a lot of different things and experiment with it until I had an understanding of what it all meant and how it worked.

And since I had written it all down, I thought it might be useful to other people—so I decided to publish it, and here it is.

Michael Gledhill
April 2017



Placeholder

This site has been up and running in one form or another for a year now and it’s time for an update.

I’ve reviewed the website and put it through a major proof reading exercise — I can only apologise for my clumsiness in not spotting some of the glaring typos before now. Thanks to everyone for pointing out my mistakes — I feel suitably chastened.

I’ve added a new section (well an appendix) for resolving multiple conflicts in both single and multiple files. This, I felt, was missing from the original website.

I’ve also made some changes to the difference and merge tool section; some of you were probably wondering why I included it at all, since I never used it. It was only so that the command line version of Git had a full and complete installation. I hope I’ve made things clearer now.

The more observant may also notice there are now social media links at the bottom of each page, I’m not convinced of the need for this and I’ve done it largely against my better judgment — I’m not a great fan of social media; I have a similar view to David Cameron (our old Prime Minister) “too many tweets make a twat”. But there it is, don’t expect any great pearls of wisdom, might be some pictures of the dogs though.

For those of you that have made a contribution (thank you very much, it is greatly appreciated) I will email a copy of the new pdf version of the website (or more accurately a link to where you can download it — it’s a bit too big to email now).

For those of you who didn’t make a contribution (you know who you are), well, shame on you.

For those that are interested, I’ve listed a few facts concerning the economics of this website below (they’re not encouraging):

Economics of this website

My philosophy for the Practical Series of Publications was fairly simple: there were no charges for reading the site, neither were there any adverts or annoying, nagging pop-ups, pop-unders or any of the other things that drive me mad. Instead I had a page called how to pay for this website — fairly straight forward I thought. I asked those readers that thought the site useful to support it by making a small contribution (£2 to £15 was the suggested amount) — Jeeze, would it kill you.

But no, no one did, not really — well two people did, and boy, that really cheered me up. I mean it. It is a really good feeling when someone you don’t know tells you that they appreciate your work and pay you for it.

That makes the conversion rate about one in 800 readers. I’ve only included those people who actually spent time on the website and returned multiple times (i.e. not people who arrive at the website and immediately leave). I realise that this is open to interpretation; I’ve no idea why people look at the website, but I figure if you keep coming back and spend fifteen minutes or so looking at stuff, then you are using the website as some sort of reference — a bit like using a book (and sometimes you have to pay for a book).

I’m going to stick with this arrangement; let’s call it an honour system,
dig deep and spend that two quid will you.

Michael Gledhill
July 2018 — Chester

End flourish image