Observations on learning to use GitHub

Did you know? The Amazing Spider-Man has a villain in his rogue’s gallery who goes by the name of ‘The Tinkerer’. This always struck me as a stupid choice for a name. The noble art of tinkering should not be limited to criminal masterminds.

Me, I’ve done a lot of tinkering. To name a few escapades: building and testing open-source 3D printers; installing (and reinstalling) multiple Linux operating systems on a battered old laptop; messing about with Raspberry Pi single-board computers because they were too cute to ignore.

Reflecting on these projects and others, I start to wonder about my sanity. But for the record: Not a single one of these activities entailed robbing banks nor kidnapping the President.

Nor would I claim to be an expert in any of the above. That’s where the tinkering comes into play. I’ve learned just enough about each of these things to make use of them in a small and gratifying way. And I’m incredibly grateful to the trail-blazers who documented and shared their knowledge so curious folks like me could follow in their footsteps.

The Gospel of GitHub

Over the course of these travels, I have encountered GitHub. But I never paid too much attention to it. At the periphery of my understanding, it was a place where developers would store code. It’s only in the past couple of weeks that I’ve come understand its value. And folks, I’m here to spread the gospel.

Now you have to remember that I’m not a web developer. It says as much in the title of this post. So please forgive me if I’m perpetuating misinformation or stating the glaringly obvious.

So yes, GitHub is a place to store code. But it’s much more complicated than that. It’s also about version control of code as it goes through a million and one iterations, and a meaningful way for groups of people to remotely collaborate on the code that makes up a project without going berserk and driving a fist through the monitor. That’s pretty amazing in itself.

And when I began to tinker with a fresh project — to build a basic website using the Jamstack philosophy— a lightbulb that was hitherto inactive just went “pop” in my head.

An account on GitHub, you see, functions as a passport to other services on the internet. You don’t need to create accounts with multiple sites and then try to remember passwords for each of them. One GitHub account grants you access to everything.

So I rolled up my sleeves and dived in. From GitHub I created and synced up accounts with Contentful (content management), Gatsby (static site generation), Netlify (deployment), and Vercel (deployment), and between those four entities have built four different websites in about a week. One account to rule them all!

The only outlier to this process was Google, which has its own authentication protocol for their services, which came into play for this project when buying and managing domains. But Google makes doing this so easy that I really can’t complain. Another story for another day.

Oh yes, and the OTHER amazing thing about GitHub is that it’s your de-facto place for storing and delivering files that go into the upkeep of a website.

Just call me Repo Man

Now that you’ve created an account on GitHub, the next stage is learning about the tools for managing repositories, or “repos” for short.

Standing on the shoulders of giants, many talented and industrious web developers have shared their code to GitHub, together with instructions for building the sites yourself. Each collection of files sits in its own little repo.

When you find a project you like the smell of — e.g., a simple template for a blog — you can clone a repo locally to your computer, run a few command lines in a terminal, and then upload your fork of that repo to your personal space on GitHub.

The gist of this is that you have a sandbox to test and run this code without messing up the source. Which you will, repeatedly. And that’s okay.

GitHub enables you to do this via the command line, as mentioned above, but in addition they offer a tool called GitHub Desktop that allows you to upload and sync your files between your desktop and your local machine. It’s very much a drag and drop affair.

I’m not saying this stage of the process is intuitive or absurdly easy, but after a few rounds of trial and error it all clicks into place. I’ve cloned a few repos now, and have even submitted a change to a repo that isn’t mine, to reflect an edit I made to the code in my own project. It’s currently being evaluated by the owner, and I promise I won’t cry if it gets rejected.

Regardless, when your own repo is ready to go, you simply hook it up to a deployment service of your choice, dial in a few settings, and unleash your creations onto the wider world. It’s a very cool thing to do.

Still awake at the back?

If you’ve made it this far down the page, congratulations! Have a cigar!

As a treat, I wanted to share one more thing about keeping your files up to date. See, once you’ve cloned or forked a repo, there is the conundrum that your files no longer being sync with the source.

I’m still figuring out how much of an issue this will be — so long as the website continues to work as intended, right? But you will want to keep your packages up to date, to resolve any dependencies in the code and patch any security flaws.

That’s where a nifty feature called “dependabot” comes into play. It’s an automated process to scan your repo or repos and update your packages so long as there are no breaking changes. Find the details here.

That’s the end of my introduction to GitHub; my impressions have been very positive so far, and I wish I’d started playing around with it sooner. Go forth! Create an account! Multiply!

And while you’re it, tell the world that tinkering is on the side of good. Z-list supervillains need not apply.