Ongoing Investigations

Revisiting Git & GitHub

So as luck would have it, a couple of things have dovetailed in my work recently. In my last blog post, I talked about the experiments I’ve been doing with HTML & CSS, building site files directly instead of using WordPress or another application. Ideally I’d like to learn more about JavaScript and PHP as well, so thinking about how HTML, CSS, JS and PHP files slot together is part of that. I also had to roll out my HTML/CSS site, my Hideous Creation (that’s its name now, I’m not taking it back) by manually uploading it to cPanel.

This month I’m also working on revising our GitHub related documentation for this month. There’s only two articles, one on how to point custom domains and subdomains to your GitHub Pages site and one on how to… well, set up a GitHub Pages site (using the GitHub desktop app & Jekyll). My revisions are primarily centered around making the language more cohesive, double-checking that all our links work and our screenshots are accurate, and confirming that the process we’ve outlined is still up-to-date. That means that the best way to do it is to work through them myself.

Maybe you’ve started to see where this is going.

I didn’t have GitHub configured on my computer yet — I set up an account a couple months ago when I started working through some PHP tutorials, but never had any files that I actually would consider sharing. I was honestly a little nervous! It’s been a long time since I used Git, particularly from the command line, and I didn’t want to install the desktop app, since a) it wasn’t how I originally learned to use Git and b) it felt tantamount to giving up.

Of course, to work through our documentation and update our screenshots properly, I am going to have to install the desktop app eventually, but I’ll live (and maybe, if I’m ambitious, I’ll add a new section that also walks you through using the command line). I’ve found resources that have helped me review and practice Git commands. And with the Hideous Creation semi-realized, I have something to put out into the world!

So, what does that mean? No more excuses.

The Tech Part

GitHub does try and make it easy for you to start a new repository, right from the homepage. Maybe it’s just because I haven’t done a lot of work with my account, or my homepage is still set to the default configuration, but right at the front and a little left of center is a quick-start area for a new repo.

And after that, they provide instructions! They have a quick-setup option for people who’ve done this before, and then for those who haven’t, there are instructions on how to create a new repository or push a local repository to GitHub. Great!

Except… GitHub does assume that you’ve already connected to your GitHub account on your computer. So these are the steps you’d take after you’re logged in… which I wasn’t. And I couldn’t remember how to. Oops.

So when in doubt, tutorial time.

I found a tutorial by Karl Broman titled “git/github guide: a minimal tutorial” which did start me at the very beginning (a very good place to start). Without going into tons of detail, the important bits were getting my GitHub account connected (with SSH) and starting/pushing my repository. Technically speaking, what I set up wasn’t a repository for Hideous Creation — it was a repo for “Hideous Creation – Git Experiment”, which was a duplicate directory for the original HC, because I didn’t want to use the directory where I was actually doing my work as the place where I was also doing all my Git experiments. (This was probably a smart idea, but it wasn’t a smart idea I had before I started working. This was a smart idea I had about four steps into the process, which meant I had to go back and start over.)

Everything was working mostly really well until I tried to set up a .gitignore file and found that the directions in the tutorial were just straightup wrong — it implied that git add .gitignore would create the file, but add doesn’t create new things, it yoinks an existing thing and adds it to the list of things that’ll be committed to the repository. So instead it just threw errors because the command was trying to look for a file that didn’t exist. A bit of googling later, and GitHub’s own documentation informed me that the command I wanted was touch .gitignore. So, checked off that step.

And then I hit a weird patch.

• I got all my files added (git add filename1 filename2 filename3 filename4 filename5…, etc.)
• checked that they were ready to go (git status)
• got connected to the repository I’d already made on GitHub (a little late in the game, but no big deal), which based on the tutorial was git remote add origin git@github.com:username/new_repo, but here was git remote add origin git@github:CapnPilot/hideouscreation-gitexperiment [Note: this is how you connect to the repo through SSH, GitHub’s instructions in the screenshot above are oriented towards connecting with HTTPS]
• created a commit (git commit -m "My first commit")
• and tried to push that to the repo (git push -u origin master)

Which didn’t work.

In fact, I tried a couple times. None of my commits were getting pushed.

Note: I didn’t get any errors, so nothing was wrong with the syntax of my commands (that I knew of), but when I went to GitHub and looked at my repo to check my work, there was nothing there. Nothing had been pushed. Which was a little weird.

After a whole bunch of puttering around and cross-checking things, I noticed that in GitHub’s original instructions, which were oriented towards connecting your repo using HTTPS, the formatting was always git remote add origin https://github.com/CapnPilot/hideouscreation-gitexperiment.git, with that little .git extension on the end being what particularly caught my eye. That extension wasn’t included in the tutorial, but it seems pretty likely that the author thought it would be well-understood.

But I missed it, and in doing so I’d connected my local directory to a GitHub repository that didn’t exist using the wrong remote URL. What I needed to do now was to replace my old work, making sure to keep using SSH instead of HTTPS despite GitHub’s original instructions.

I was worried I’d have to fully remove the incorrect remote URL and replace it, and that removing it would break something, but nope. Turns out you can just switch remote URLs! That was actually something I found in GitHub’s documentation, under “Managing remote repositories: Switching remote URLs from HTTPS to SSH.” And you don’t actually have to be switching from HTTPS to SSH to make this work. You can be switching from an incorrectly configured SSH remote URL to a correct one, and it’ll still be A-OK.

The ending is a bit anticlimactic to describe: I re-added my files, re-committed them, re-pushed the commit, and it worked. But after the stress and irritation of figuring out what I’d done wrong and whether it was fixable, it felt really cool to refresh the page and finally see my work come through.

I’ve written a pretty epic saga in order to describe what’s essentially, “I set something up, broke it immediately during setup, and then fixed it,” but I’m pleased. It’s fun to putter around and try stuff and experiment. I like being able to pull different areas of my work together into one cohesive whole. Working with Git again feels one part familiarity, one part learning, which is always a good zone to be in. And I still haven’t actually gotten to start on the GitHub Pages parts, so there’s more to do yet.