I use GitHub, like a lot of developers, to handle my project files.
I like GitHub a lot. It’s great. I don’t understand it as well as I’d like, but what I do know and use, works very well, and is very useful.
I don’t really know git, the command-line program that GitHub is based around, which does all the version control magic you need. Because I’m a dummy, I only use GitHub Desktop for Windows. But that’s fine; it does exactly what I need it to do, I haven’t hit any limits with it as yet, and I’m able to understand/figure out its interface to do what I need. That’s the whole point of a tool. Who has time to read all the docs and learn the muscle memory to type all the commands manually, am I right?
But I say this because I need to make it clear, I’m not entirely clear where git ends and GitHub begins. I’d been hearing about git and how good it is for, I don’t know, years and years, before I finally started using it. About a year ago, I grew tired of all the obstacles that were preventing me from just sitting down and forcing myself to learn to use git from the command line, and decided to just jump in and use GitHub rather than figure out how to set up git on my own server and then do stuff with it via shell commands. I was still worried about doing something that made me look dumb in public, so I didn’t use my GitHub account much at first, until I grew tired of that fear blocking me, and decided to just spend the $7/mo on an account so I could set up private repositories and enjoy the ability to screw things up as much as I dared, without it being on full public view.
This was when I started to make serious progress with getting into GitHub. And I found that with GitHub Desktop, the Windows app that wraps a bunch of command line magic that I wish I knew, but don’t, was amazing. It took a little bit of trial and error to learn the ins and outs, and a very small number of minutes watching tutorial videos. But that was what was so great about it. If I had a question, I could search GitHub’s help, and most often I’d find a video that was, at most, about 2 minutes long, that answered my exact question. Most IT tutorial videos feel like they need to spend 20-30 minutes going through some process, and it’s too much to follow, but these bite sized videos were just what I needed.
Anyway, now that my background is explained, I’ll talk about something that happened last night.
I have a project that I’m managing in GitHub, my Ludum Dare 41 project, InvadTris. I had just spent the evening going over the project and made a few minor edits, which I checked in. As I did my commit, GitHub Desktop notified me that it had an upgrade available. Without thinking, I clicked the button to install the update. It installed in a few seconds, and then I noticed that while I’d submitted the commit, I hadn’t yet synced it with GitHub. So I went to do that, when GitHub prompted me to log in. I entered my credentials, and authentication failed. GitHub Desktop showed me as being logged in (I guess locally?) but authentication to github.com through GitHub Desktop was failing.
I tried logging out, then logging back in, as the interface recommended, but this did not fix the problem. I logged out of GitHub in my browser, and logged back in, just to verify that I did indeed have valid credentials, and this was successful. I wasn’t sure what else it could be, so I tried removing my SSH key in my GitHub account settings, but this didn’t help, either.
I figured I’d open up a ticket with GitHub Support, and they’d give me a solution, so I started writing up a ticket. I went to check the version number of GitHub Desktop, and in the About screen it told me that I was on the last version of this particular tool, which was no longer actively being developed. I learned also from this that there was a new GitHub Desktop, and downloaded and installed that.
The New GitHub Desktop had no problem authenticating me. Problem solved, right? Well, almost. For some reason, the new GitHub Desktop didn’t pick up any of the local repositories that my old GitHub Desktop knew about. So, to complete syncing, I’d need to manually add my repository, then I could sync. Later, I could introduce all my other local repositories into the new Desktop, and then I could just use the new version from now on.
Well, for some reason, the New GitHub and the Old GitHub didn’t seem to agree with each other on the status of my local repositories. This is where intricate understanding of how git and GitHub works would have come in very handy, but I didn’t have that. All I had was Old GitHub telling me that I had a recent commit locally that was pending sync, and New GitHub telling me that it saw no changes, so had nothing to commit, nor anything to sync.
WTF? I still don’t know. I quickly went through some of my other local repositories, and found that they also disagreed with their check-in/sync status according to Old GitHub as well.
Fortunately, I eventually discovered that I could simply roll back the update to the old GitHub Desktop, and once I had done so, it was once again able to authenticate me to GitHub’s server, and I was then able to sync up my local files with the server.
I understand that the whole point of git is to have de-centralized version control, but I still think of the repository on GitHub’s server as The Repository. The files there are backed up, are offsite relative to me, and I feel comfortable knowing that they exist somewhere else in case of disaster.
Now that I have everything synced with the server, I can switch over to using the New GitHub Desktop, and life will be good. If my other repositories still have disagreements between the Old and New GitHub Desktop, I can resolve them, and it won’t be a problem.
In all, this took me about 3 and a half hours to resolve, from the time that I applied the bad update to Old GitHub, to restoring Old GitHub to the version that works and completing my sync. Unfortunately, I was up half the night doing this. I was in a panic, and whenever I have problems with a computer that means I am at risk of losing data, I just can’t sleep until the problem is solved.
So, my takeaway from this experience is that the primary cause of the problem was a failure of the tool, but it was compounded by my stupidly not completing my check-in/sync work before applying an update. In recent years, software quality has gotten so good across the board that I’ve grown accustomed to upgrades going without a hitch. I can install Chrome upgrades, relaunch, and it’ll remember all my preferences, all my tabs and sessions, and it’s not even a concern at all anymore. 10, 15 years ago, when I’d upgrade my web browser, it was this big ordeal of bookmarking any open tabs that I wanted to return to, checking all my extensions for compatibility with the new version, installing the upgrade, re-checking all my configuration customization, etc. Such a pain. It’s good to remember how much better things have gotten over the years. This time, though, it bit me. If I’d simply completed the work I was doing before applying the upgrade, I could have went to be a lot earlier, and worried about the authentication bug later. So, that’s a good lesson to remember.
Also, as this article shows, I don’t mind being dumb in public after the fact, if once I’ve learned from the mistake, I can share what I’ve learned. I still don’t know git, or GitHub as well as I’d like, and I’m sure I’ll never have perfect, full understanding of either, but they’re very good tools, and I’m glad I can use them well enough.