Github on blog.iankulin.com

Website in a Docker Container

Mon, 11 Nov 2024 00:00:00 +0000

Having figured out how to use the GitHub package registry, I was a bit inspired by this blog post from Florin Lipan to deliver all my little static websites as Docker containers. I’m not as focused as he is about making them tiny, but I did steal the idea of using BusyBox httpd for serving them, resulting in about 4MB containers. That’s small enough for me, and since they are all very similar, there’s a fair bit of layer reuse going on.

Here’s the setup. I dump the static (html, css, js etc) files for the website into a ‘www’ sub-directory.

The dockerfile pulls in BusyBox then copies those files into the container. Note these are in the container, it’s not going to be bound to an external directory (where we could change them), the container carries its website files with it. Any change to the website content will require a container rebuild.

EXPOSE 80 doesn’t really do anything, it’s pretty much just documentation. Then the CMD directive starts the server on port 80 and points to the static files that we copied in earlier.

FROM busybox:latest

# Create the directory for the web content, and copy files in
RUN mkdir -p /var/www/html
COPY www/. /var/www/html

# Expose port 80 for the web server
EXPOSE 80

# Start the httpd server
CMD ["sh", "-c", "busybox httpd -f -p 80 -h /var/www/html"]

To use this dockerfile to build our container, just docker build it and give it a tag:

docker build -t ghcr.io/iankulin/example.com:latest .

Then if we run it, and go to http://localhost, there’s our website.

docker run --name httpd-example.com -p 80:80 ghcr.io/iankulin/example.com:latest

With NGINX Proxy Manager

The docker-compose.yml file I use on the VPS host is slightly more complicated. We want each of the website containers to run in the same docker network as Nginx Proxy Manager - since docker networks have their own little dns server based on the container names, that’s going to make hooking it up trivial.

services:
 example.com:
 container_name: httpd-example.com
 image: ghcr.io/iankulin/example.com:latest
 restart: unless-stopped
 networks:
 - nginx-proxy-manager_default

networks:
 nginx-proxy-manager_default:
 external: true

Architecture

Since I develop on an M1 MacBook, but host all my workloads on regular AMD64 Linux LXC containers or VMs, I need to build for that:

docker build --platform linux/amd64 -t ghcr.io/iankulin/example.com:latest .

In actual fact, I could have built that way for the Mac as well - Docker Desktop would have just run it in a Linux VM with a small performance penalty which wouldn’t be noticeable for my purposes. Once it’s built, we push it up to the GitHub Container Registry.

docker push ghcr.io/iankulin/example.com:latest

Working with the registry is well covered in my previous post, so I won’t go into those details here.

On the host

On the host where the website is to run, I just make a directory for it and drop the docker-compose.yml in. Then docker compose up -d

Since we’re running in the Nginx Proxy Manager docker network, when we specify the host name for the new web site for NPM to proxy to, it’s just the container name we gave it.

Then the DNS settings for your domain need to be pointed to this host. Once that’s propagated, you’ll be able to request the SSL certificate in NPM and your website is live.

Using the GitHub Container Registry

Mon, 04 Nov 2024 00:00:00 +0000

As the number of little projects I’m running on VPSs grows, I need to have a regimented system for managing all that. I could be using something like Coolify, but, at least for the moment, I’d rather build my own system.

Currently my system is Nginx Proxy Manager (dockerised) in front of each app. If it’s a static website, that’s another dockerised Nginx, started with a compose file and with www and conf sub-directories that I’ve git pulled from the project. It’s not pretty.

It occurs to me that I could just be bundling each static website inside a Docker image, then the only content for each website on the VPS would be a compose file. This has the extra appeal that eventually I could use GitHub CI/CD to rebuild the container so changing a website would be pushing my edits to main, then compose down, pull, and up on the VPS.

Currently I’ve only been using DockerHub for my containers, but the free plan only allows for a single private image, whereas on GitHub the free plan doesn’t have a number of packages limit - rather it has a total storage (500MB) and monthly transfers (1GB) limits. Along with the aforementioned integration with GitHub CI/CD, this makes it the obvious place to store these images until my scale is large enough to set up my own registry (which I would probably do with Forgejo on a VPS since the limits of running that inside my Tailscale network is starting to be a friction point anyway).

Long story short - I want to start using the GitHub container registry, and this post steps through that.

Access Tokens

If you set up your Docker Hub a while ago, you’ve probably forgotten that early on, you had to log into it from the command line with the docker login command. With Docker Hub, that’s your usual username/password combo, but GitHub has a more fine-grained system of permissions, where you generate ‘Personal Access Tokens’. This is quite cool, for example you can generate a token with add/update/delete access for your main development laptop, but then generate a different token that only has read access to use on the server where you need to deploy the image.

The Personal Access Token (PAT) is just used in place of a password when you log in. As well as the benefit of being able to control the permissions for each PAT when you create it, you also name them. This would be helpful for example if your software lead had their laptop stolen, and you needed to revoke the PAT for that device. It’s also possible to set expiry dates for the PATs.

Generating the PATs is done in:

If you have MFA set up (you should) it will ask for that. Then give it a ‘Note’ and the permissions you want for “Packages” - Container images are stored in the “Packages” section of GitHub (where it’s also possible to store other artifacts such as your private NPM packages). In the example below we’ve asked for Read/Write/Delete access.

Once that’s completed, you’ll be shown a list of your existing PATs, plus the new one you’ve just generated. This is the only time it will ever be displayed in GitHub, so you need to copy it out to where you need it.

Logging in

Before we can push an image to the GitHub Container Registry (ghcr.io) we’ll need to use this PAT to log in. I’m using the command:

docker login --username <github username> --password <PAT we just generated> ghcr.io

ghcr.io is just the URI for the container registry. It will complain about you pasting the PAT in the command line like that - I guess it’s in your bash history now. I’ll leave you to google how to do that more securely.

Note that you can be logged into several container registries at once. Logging into the ghcr.io won’t mean that you’ll need to re-logging to DockerHub later; that will still work fine.

Pushing

Once that’s done, you can push images just as you are used to with DockerHub, with the exception that you need to specify the container registry as part of your image name. It’s possible to do that with hub.docker.com as well, but Docker privileged themselves to make it a default. To use a different registry (in our case ghcr.io) it needs to be included in the image name, along with your GitHub use name.

docker push ghcr.io/<github user name>/<container name>:<tag>

If you head to GitHub, and go into “Packages” instead of “Repositories”, your container will be there.

Pulling

Pulling the container is going to be even simpler, log in to the registry with the same command we used above, then just docker pull with the registry in the container name - exactly as suggested in the package page on GitHub above.

docker pull ghcr.io/<github user name>/<container name>:<tag>

Getting Your Vite React App to Work on Github Pages

Fri, 26 Jan 2024 00:00:00 +0000

One of the many cool things about GitHub is GitHub Pages - the free web hosting Microsoft gives you while they vacuum up your code for CoPilot training. Each repository you keep there can have pages at <your-github-username>.github.io/<repo-name>

GitHub

To enable this, you need to go into the settings for the repository - look down the left for “Pages”.

It’s possible to have it based on a complicated GitHub action (where your build step happens on GitHub when you push your code), but the easiest thing is just to have it deployed from a branch. To do this you choose which branch (usually main) and whereabouts in the main branch your HTML is. The choices are in the root of your project, or in the /docs directory. I’ve chosen the /docs directory in the screenshot above, since my messy React project is in the root.

That’s all the GitHub set up we need. Now whenever I push my project to the main branch on GitHub, whatever is in the /docs directory will be uploaded to my GitHub page for this repo.

Vite/React

Now we need to make a couple of changes to our project to get this to work. The first is to tell Vite the “base directory” for the project which needs to be the repo name you’ve used on GutHub.

This is written into the index.html that is built as part of this process. If it’s not there, then any browser accessing your index.html on gh-pages won’t be able to find your JavaScript, and the user will be left looking at a blank white page instead of your amazing app.

My process from this point, is to build the project with npm run build. By default, this creates a /dist directory in your project (which is already added to .gitignore) and puts the project artifacts (the HTML, JavaScript, CSS and any images) into it. I then manually copy the artifacts over to the /docs directory of the project and push it up to GitHub to be published - which takes two or three minutes.

I like this manual step of copying the files over so that publishing is an intentful action on my part, and also, for solo projects I generally just work out of the main branch rather than on feature branches that then get PR’d into main. If you did want the process to be more CI/CD flavoured, you can just make another change the vite.config.ts file to have your builds go straight to the /docs folder.

import { defineConfig } from 'vite'import react from '@vitejs/plugin-react'// https://vitejs.dev/config/export default defineConfig({ base: "/mosh-expense/", plugins: [react()], build: { outDir: 'docs', }})

Once all that’s working, and you’ve pushed your changes and waited a minute or two, your project should be live to the world on github.io

If you want users browsing your repo to find the live version, it’s worth editing your repository about settings to point to it.

Git - pushing to two remotes

Fri, 15 Dec 2023 00:00:00 +0000

I am loving running a local Gogs instance - it’s nice pushing my git repos to a totally private hub that I know is backed up with all my other self-hosted infrastructure.

Of course, there’s good reasons to have code in GitHub as well - my build-in-public philosophy, the vague possibility that some of it might be useful to someone, my contribution to our future AI overlords, and when I need to make some code linkable - for example from one of these posts. And of course there’s this bit of social-engineering which I assume was inspired by the bathroom decor in Veronica Mars.

Git is an amazing tool, so of course this is possible. Normally my workflow is that I git init whenever I’m working on a new something, then at some point I think “I should really push all this so it’s backed up”. I create the repository for it on GitHub or Gogs via the web interface, then come back to my project and:

git remote add origin git@github.com:IanKulin/test.git

This is making the connection between my local project and the GitHub repo. I’d never really thought about what origin meant in this context the hundreds of times I’ve previously typed it in, but actually it’s just the name we are giving to this connection. It’s just a convention to call it ‘origin’, it could just as easily be called ‘fred’ or ‘github’. Since I am now planning to push to two separate remotes, it’s going to make sense to give them meaningful names. So in that case, we can do this:

git remote add github git@github.com:IanKulin/test.git
git remote add gogs http://ct-gogs/iankulin/test.git

Then, we can push with:

git push github main
git push gogs main

You might be wondering what happens if you just do a git push at this stage (or as I like to call it “Pressing the ‘Publish Branch’ button on the VS Code source control panel”). The answer is that at the command line you’ll get an error saying you haven’t specified the destination, or in VS Code, it will ask you which one.

We can set the default remote with the -u flag when we’re pushing

git push -u gogs main

Now the button in VS Code will say something “Sync Changes” and when you press it, it will only push to the remote we used in the last -u push. Same thing if we git push at the command line - it will work, but only push to the remote we used in the last -u.

It’s also worth noting that when we’ve set the default remote with the -u flag in a push, it is also the default remote for pulling from. Essentially this remote becomes the source-of-truth.

For me this setup is usually fine - I’m generally working on my local gogs remote, that’s the source of truth so I specify it as the default with the push -u. Then, when I’m done, I manually push to github so I can share it. If it was a project I needed to work on with anyone else, that would have to be the other way around - I’d use GitHub (or GitLab, Bitbucket etc) as the source of truth, and probably not even worry about hosting a copy on my home network unless I was worried about the repo being deleted.

New Project Routine

Sat, 21 Oct 2023 00:00:00 +0000

I have a sort of muscle memory for starting little web projects now. I seem to have landed on node/express SSR apps with HTMX sprinkles. So it goes a bit like this:

Create a working directory - all lower case with a simple, but unlikely to be duplicated by me, name.
Open the directory in vscode
npm init in the directory to create the package.json
create a public sub directory, and drop htmx.min.js in there, and create a styles.css there. I’m always conflicted about what to do about this htmx dependency. I’d rather host it rather than use their CDN because reasons. But I also feel bad about committing it on Github. I could .gitignore it, but then when I clone the project on the production server I’d need to add another step to download it. HTMX is only 44K, and Microsoft can afford the bandwidth, so for the moment I commit them, but I need a better solution for the future.
using the git tools in vscode, add .DS_Store to .gitignore (which also creates it), then edit it to also ignore node_modules
npm install express
npm install ejs
create a server.js, and add the hello world code
create a readme.md
commit these files as “initial”
Create the repo on github with the same name - no readme and no licence. I do it this way for a couple of reasons - I want to find out at this point if I’ve already used this repo name, and I want it to give me the cut and paste commands to push the repository.

Do those in the terminal.
Refresh the github page, and add the licence by Add File, name it LICENSE - this lets you choose the template you want. What I’d really like here is “GPL3 but giant cloud companies can’t make money from hosting it” - which I guess would be called the MongoDB license or something.
Do git pull in the terminal to check that’s all working
nodemon ./server.js then command click on the link to check everything’s working
profit

Express Skeleton

That’s my basic web app setup, but since this is an express app, and we’re using some EJS templating, there’s some other starter files I like to create. Let’s start with our pages. I’ll need an index and a 404 page, and my pages are all going to have a header section as well as a nav and a footer. Something like this:

─── views
 ├── 404.ejs
 ├── index.ejs
 └── partials
    ├── footer.ejs
    ├── head.ejs
   └── nav.ejs

To give you a flavour of how that all works, here’s a sample index.ejs

<!DOCTYPE html>
<html lang="en">
<%- include('./partials/head.ejs') %>
 <body>
 <%- include('./partials/nav.ejs') %>
 <div class="content">
 <h2>Hello world</h3>
 </div>
 <%- include('./partials/footer.ejs') %>
 </body>
</html>

Then we need some basic routing in server.js

const express = require('express');
const app = express();
 
const hostname = '127.0.0.1';
const port = 3000;

app.set('view engine', 'ejs');
app.use(express.static('public'));

app.get('/', (req, res) => {
 res.render('index', { title: 'Index'});
 });

//404 handling
app.use(function (req, res, next) {
 res.status(404).render('404', { title: '404', url: req.url });
});

app.listen(port, hostname, () => {
 console.log(`Server running at http://${hostname}:${port}/`);
});

And, lastly, a bit of CSS to make it beautiful.

@viewport {
 width: device-width ;
 zoom: 1.0 ;
} 

body{
 max-width: 1200px;
 font-family: Tahoma, Arial, Helvetica, sans-serif;
 margin: 0;
}

nav {
 position: fixed; 
 top: 0; 
 width: 100%; 
 overflow: hidden;
 background-color: #EEE;
}

nav li {
 display: inline-block;
 padding: 0;
}

nav a {
 display: inline;
 color: #333;
 text-align: center;
 padding: 17px 8px;
 text-decoration: none;
}

nav a:hover {
 background: #ddd;
 color: black;
}

nav ul {
 padding-inline-start: 4px;
}

/* push content down below the nav bar */
.content {
 padding: 50px 10px 10px 10px;
}

footer {
 width:100%;
 position:absolute;
 bottom:0;
 left:0;
 color: #757171;
 text-align: center;
 margin: 80px auto 20px;
 background-color: #EEE;
}

chefs_kiss.jpg

Git/GutHub - macOS - marking file as executable

Sun, 30 Apr 2023 00:00:00 +0000

I’m working on the world’s shortest shell script - it’s called by cron to pull down a JSON weather report to a text file using curl so I can expose it on an Nginx endpoint. The purpose is to allow me to hammer that weather API from multiple machines I control without violating the TOS of my free API key.

Because I’m learning all the things, instead of just creating this on the VPS where it runs, it’s cloned from my GitHub repo for that machine. I’m creating and editing the file in VS Code on macOS, pushing to Github, then pulling the changes on the Ubuntu VPS. The intention is that this will eventually become automated with a Github action.

The problem I’ve run into is that I want the file permissions so show the file is executable so when it arrives on the VPS - so no chmod is required to make it usable.

Some googling suggested that the executable flag (but none of the other file permissions) is stored and handled by git, and furthermore, there’s a git command to set it:

git update-index --chmod=+x bin/fetchWeather.sh

So I wrote my (one line) script, applied the command above, committed and pushed, then pulled it down on the VPS and the bit wasn’t set. So somewhere in this chain there’s a problem.

At this stage, it’s helpful to know that if the executable bit is set for a file, GitHub shows this in the header of the file where it says how many lines etc.

In my case, it was showing that the file was not marked as executable in GitHub, so the problem was that the git update-index was not working for me for some reason.

A bit more investigation turned up that there’s a setting in the .git/config file called filemode that controls if the originating file system executable status is preserved. That sounded promising - I was expecting to find that is was set to false, and I could change it to true, and it would fix my problem. I had a quick look and, oh, it’s already set to true.

Seems like it’s involved though, so perhaps (my thinking went) I should change it to false and see if the problem goes away…. and it did. I changed this value to false, applied the executable bit with the git update-index command, committed, pushed it to GitHub (it was marked executable), pulled it down to the VPS, it was still marked executable!

My whole tech life, I’ve never been happy with solutions to problems where I don’t understand the underlying reasons. If things just start working when you’re fiddling around and you’re not clear on why, it feels like they could change back with just as easily and with no more reason.

A clue to what’s going on (many readers will already have figured this out) was given to me by ChatGPT. When I was asking it about this issue, it kept insisting I should chmod the file to be executable before I committed it. I had to be really clear with it that this wasn’t possible on macOS because it doesn’t have that sort of file permissions…

Of course, in fact, it does. macOS is based on FreeBSD (“without the good bits” goes the old joke told at Unix conferences). I’d just somehow forgotten this - I guess in Linux I’m used to explicitly seeing them every time I look at a directory contents, but never see it on Mac. Even if you go into “Get Info” for a file in Finder on the mac, you can see the read/write permissions, but not the executable bit status.

So how do you set and view the executable status on mac? Exactly the same as on any Unix.

I did that, and changed the /git/config filemode back to true. Committed and pushed the file up (without worrying about the git update-index) and it showed up in GitHub as executable, pulled it down, still executable.

Committed

Tue, 06 Dec 2022 00:00:00 +0000

I quite like logging into GitHub and seeing my commit history as the graph with the green dots. Once I get up to a year it would be a great thing to have on a T-Shirt.

I’d expect to be seeing the busy weekends, but Tuesday nights seem to be oddly productive. It could just be a start of the week energy thing - I have some other community obligations on a couple of Monday nights a month.

git is an amazing tool - better that the commercial tool I used when I was programming a long way back. I really admire what the many open source programmers have put in to it. I also owe some gratitude to Microsoft for making GitHub available to newbs like me at no cost - it’s an great service.

According to the graph, my first commits were on July 10. My first blog post was on the 5th, and I’m on a 154 once per day posting streak - although there’s a few two per day scattered through there when I’ve been on holidays. I’m only up to day 64 of the 100 Days of SwiftUI - so I clearly I haven’t been getting in an hour each day on that religiously, but overall, I’m pretty happy with my commitment to myself.

Gitting Xcode to Push

Fri, 30 Sep 2022 00:00:00 +0000

I’m very comfortable with doing all the routine git stuff from the command line, but it was bugging me that I hadn’t for the Xcode integration working. I was able to commit locally with no problem from Xcode, but could not push up to Github. It works fine from the command line, so the error about the change to a stronger SSH authentication didn’t really make sense to me.

ERROR: You’re using an RSA key with SHA-1, which is no longer allowed. Please use a newer client or a different key type.

This post from pasllani on the Apple Developer forums was super helpful, the only thing they missed was that you need to restart Xcode before it will work. The steps were:

Generate a new ECDSA SSH key with ssh-keygen -t ecdsa -C "IanKulin@kulin.com.au"
Copy the key to the keyboard with pbcopy < ~/.ssh/id_ecdsa.pub
On Github, add the new SSH key, and while you’re there, generate a new Token in Developer Tools
In XCode, delete your github account, then recreate it specifying SSH and choose the ECDSA key. It will need the access token at this stage.
Restart XCode

Other git/Github posts

Intro to git - Gitting Started
Common git commands - Gitting the Hang of it
Merge vs rebase
Create an Empty Folder on Github
Download a Directory from a Github repo
Download a File from Github

How to download a file from GitHub

Sat, 17 Sep 2022 00:00:00 +0000

A quick tip - since it was not immediately obvious to me. If you need to download a file from GitHub (as opposed to cloning it etc), look for the “Raw” button - that’s a link to the file, then right click and do whatever your browser needs to download a web resource.

Download a Directory from a GitHub Repo

Tue, 30 Aug 2022 00:00:00 +0000

For Challenge 2 in the 100 days, I needed to download a directory of flag images from Paul’s GitHub. He has all the projects as sub-directories of a single “Hacking With Swift” repo. I didn’t need to whole thing, just the directory with the images.

Strangely, git does not have any simple way of doing this. Neither does GitHub - I assumed the web interface would have a “download as zip” option as it does for tags.

One of the popular solutions on StackOverflow was to use SVN, which GitHub supports and which does have this functionality. I much preferred Avinash Takur’s suggestion to use GitHub’s web based VSCode.

To access their VSCode, change the .com in the repo url to .dev. For example, instead of https://github.com/twostraws/HackingWithSwift/tree/main/SwiftUI/project2, go to https://github.dev/twostraws/HackingWithSwift/tree/main/SwiftUI/project2

Once that’s done, right click on the directory to download it.

Gitting the hang of it

Thu, 04 Aug 2022 00:00:00 +0000

I spent most of the day learning about, and practicing with git. I’ll list some of the resources at the bottom, but for the moment, this is my understandings / cheat sheet for git. Since this could conceivably turn up in someone’s google search, and slightly less conceivably be of some use, I will come back and edit it if there’s something bad/wrong here. Comments would be great if you think that’s the case.

It’s most likely to be useful to someone using Xcode, GitHub, and the command line for git on MacOS.

Start a new repository (repo)

on GitHub create the repo, it doesn’t matter if you create any files in it - they will be wiped shortly
while you are on GitHub, grab the SSH address for the repo - it’s under the green “Code” button. If your username is IanKulin and the new repo is named GitTest it would look like this [git@github.com](mailto:git@github.com):IanKulin/GitTest.git
create your Xcode (or whatever) project. I use the repo name as the project (and therefore directory name) but that’s not strictly necessary. I navigate to the Developer folder, so the new project is created as a folder inside that. Then in terminal inside that new directory:
git init
that marks it as a directory under source control, I usually drop a .gitignore in at this stage (more about that further down)
we need to add the files and commit them to the local git repo:
git add -A
git commit -m "Initial commit"
now we connect the local repo to your github repo
git remote add origin [git@github.com](mailto:git@github.com):IanKulin/GitTest.git
that just sets up the name so you can use origin now to refer to the remote repo
push the local files up to github with
git push -u -f origin main
main is the name of the branch - GitHub defaults to this. If you are looking at old tutorials they are probably using master rather than main.

Xcode

once a project is set up for git like this, Xcode will realise and use it to indicate changes in files, and mark them in the file navigator as “A” or “M” (need Added, or have been Modified). There is a Source Control menu that allows you to Add and Commit (more about these further down) to the local repo which work well, but I haven’t had any luck pushing up to GitHub with it - I do that from the command line. Doubtless this is something to do with the SSH key.

About .gitignore

this config file is used by git to ignore the working files that shouldn’t be tracked - stuff like the different compile states and so on. Normally we’d only want the source, asset and make files etc - the stuff needed to recreate the project
GitHub will create a default for the language you are using if you let it
I usually add these lines to it:
- # MacOS
- .DS_Store
to show hidden files like this in Finder, COMMAND-SHIFT-DOT and the same to rehide them
if you do that, you’ll also see the .git folder which is where git does all it’s magic.

To check how things are going

use terminal in the directory where the repo is
git status
you’ll see any files changed, or that need to be added, and if the local files are ahead of the last clone/push but not if they are behind the remote (GitHub) - until you do a git fetch, the local git doesn’t know what changes have happened on the remote

To add any files you’ve created in the project to version control from the CLI

git add .
or of you just want to do a particular file
git add
this adds the files to the “staging area” - they are having changes tracked, but they have not been “committed” to the local repository, or the remote

When done editing and adding files and they need to be “saved” to the local repository

this is called committing them
do from the XCode Source Control menu, or from the CLI with
git commit -a -m "Message for commit"
now they’ve been added to the local repo. If you do a git status it will tell you you are ahead of the remote

To “push” all the changes up to GitHub from the CLI

git push origin main
“origin” is the address for the GitHub repo, it was set for us when we cloned the repo. “main” is the branch we’re pushing to.
You can’t just create a new branch with this push?

To tag all the files in the current local repo

git tag -a v0.2 -m "Second draft"
the v0.2 is the tag and “Second draft” the description - change accordingly.
This only does the local copy, so you need to push it to GitHub
git push --tags
If you go and look on GitHub, the tags appear on the right under releases

To clone from a tag point

git clone --depth 1 --branch v0.1 [git@github.com](mailto:git@github.com):IanKulin/TagTest.git
where v0.1 is the tag
the --depth 1 means you don’t get all the history with it
alternatively, if you don’t need all the history you could just download the zip/tarball from GitHub

Some resources

How to Push an Existing Project to GitHub
MIT Missing Semester lecture - Version Control
Pro Git (book)
Git Tutorial for Beginners - Git & GitHub Fundamentals In Depth (Tech with Tim video)
Learn git in 15 minutes - Colt Steele video
Fireside Swift podcast - Ep 11

Create an Empty Folder on GitHub

Fri, 15 Jul 2022 00:00:00 +0000

You can’t, but you can create a folder by adding a file through the web interface and using <folder name>/<file name> - so add a README.md or whatever. Then you can drag your source into the new folder as normal.

I learned this from Zack West here, where there is also a better explanation with pictures.

Gitting Started

Wed, 13 Jul 2022 00:00:00 +0000

One of my early goals was to get in the habit of using version control with Git/Github, and I’ve got that sorted out today. My source was this excellent, very clear video from Gwen Faraday. I highly recommend it if you are just starting.

It possibly helped that I’m also on mac, so I didn’t have to deal with the “or however that’s done on your system” type problems. Also, where things didn’t work as expected, the explanation about what was being done was clear enough that the problem was solvable. For example, the push command Gwen used was:

git push origin master

but GitHub had defaulted my initial branch to “main” rather than “master”. Easily fixed since she immediately explained what both of those modifiers were. The only other tiny bit of troubleshooting was that my git global config wasn’t set up, so my commit was followed by a big message pointing out that my real email address wasn’t used for the commit:

 Committer: User Name <username@Ians-MacBook-Pro.local>
Your name and email address were configured automatically based
on your username and hostname. Please check that they are accurate.
You can suppress this message by setting them explicitly. Run the
following command and follow the instructions in your editor to edit
your configuration file:

 git config --global --edit

After doing this, you may fix the identity used for this commit with:

 git commit --amend --reset-author

It didn’t make any difference - the file I’d created locally pushed up to the GitHub repo just fine. When I did follow those instructions to edit the file, I suddenly needed to know how to use Vim (hint: “i” to go into insert mode for editing, then “:” for command mode and “x” to exit and save).

The only real complexity in the whole process was generating the SSH key and saving that on GitHub to allow the push from your local directory up to the GitHub repository.

Ignoring that, the process was:

Creating the repository via on GitHub
Using git clone to download the repository to the local machine and set it up for tracking in git
Edit/create the files, however. Gwen used Visual Studio code, I used my tools
Check status with git status
git add . to stage the new files and freshly edited files
Commit those changes with git commit -m "commit title" -m "description"
Then push them up to GitHub with git push origin main where “main” is the branch name.

All of that was by about the 25 minute mark in the video, and is probably enough for me to go away and get some practice with. The rest covers getting an already established local git repository to GitHub, branching, forking, undoing.