Git on blog.iankulin.com

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.

Gogs - your own tiny GitHub

Wed, 06 Dec 2023 00:00:00 +0000

(edit: - I’ve had a rethink about my source hosting)

Once you’re familiar with coding tools, like the excellent VS Code, and git, it’s immediately apparent that these tools can be applicable for other purposes. A great example is that I now do my financial accounting in plain text (using beancount). I have a python script that converts by bank account data in to the beancount format text files, I edit them in VS Code with a plugin that does the syntax highlighting and checks everything balances.

Naturally, I want to version control that, so my text based accounts are all committed to git. But I don’t really want to push them up to GitHub, even to a private repo. I want to push them to a git server that’s available for me to pull down from anywhere, and is backed up with all my other data.

It actually is possible to run a git server to do this with vanilla git, and I’m sure that’s how the hairy chested sysadmins of old do it. But I want a web gui a bit like GitGub that I’m familiar with. Of course, GutHub does all that other sweet stuff like CI/CD, but I don’t need that for my accounts.

There are a couple of popular options for this job, one is Gitea which does lean into that CI/CD functionality, and the other is Gogs, which being a bit simpler, is also a bit simpler to get going. When I say simpler, it’s still massive overkill for my needs - you can have thousands of users, do pull requests, track issues, write project wikis - all that good stuff. It also has webhooks so you can knit together a pipeline with drone.io, Jenkins or other CI/CD tools. So I went with Gogs

Installing

It’s not mentioned on the install page for Gogs, but there is an official container build. Possibly this is because there’s a couple of rough edges that I’ll get to shortly. I’ve talked before about how I like to run services in Docker on LXC, so I won’t go over that again. Here’s my docker-compose:

version: '3'

services:
 gogs:
 image: gogs/gogs
 container_name: gogs
 ports:
 - "23:22"
 - "80:3000"
 volumes:
 - ./data:/data
 restart: always

However, there is a gotcha I hadn’t encountered before - when I docker compose up with this, I got the error “failed to register layer: unlinkat /app/gogs/docker/build: invalid argument”.

When I asked ChatGPT about this, she thought it might be to do with the storage driver. I didn’t know what that was so I spent time googling around.

Pretty soon, I discovered this thread. Part way down there’s the suggestion to edit /etc/docker/daemon.json to add a different storage driver, followed by many comments of “Thanks!” and “That fixed it”. I followed that advice, (it uses a different driver “vfs” rather than “aufs” as suggested by ChatGPT) and then the container came up properly.

With that out of the way, and the container live, if you go to the port you’ve specified in the docker-compose file (mine was :80), you’ll be greeted with the “Install Steps For First-time Run”.

They are not joking. You won’t be able to guess these settings. I guess they haven’t put a lot of work into the container experience - some of these settings need to be for inside the container, and some are used for prompting the user, which are outside of the container settings. I suspect this rough edge is why the container install is not on the Gogs website yet.

Anyway, after I’d ignored this suggestion, run into problems, google them, found closed issues where people had had the same problem and the devs pointed them to the perfectly clear guidelines we hadn’t read…

I’ll leave you to read the guidelines. The only other things of note is that I used the SQLite database to make my life simpler, and you don’t need to muck around making an admin account - it just makes the first person to log in the admin. Once that’s all done, you have to create a user account, then log in with it. You’ll be greeted by a reasonably familiar sight.

If you go ahead and create a repository in Gogs, it will give you the commands to push a repo up:

So let’s do that:

The back in our repo on Gogs:

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.

git stash

Sat, 12 Nov 2022 00:00:00 +0000

When I was writing the blog post for the last project, I needed the “before” code to paste into the post. I’d committed that code, so a quick way to go back without losing my changes. I hadn’t committed the new code, so there is a super easy way to accomplish this.

git stash

This grabs the code since the last commit and stashes it away, reverting the directory to the last committed version. I was able to copy the code I needed to the blog post, then to go back to my changes:

git stash pop

It does get more complex than this - it’s git of course. It’s possible to stash multiple changes then pop them back, it’s also possible name them to selectively pop them, and to view the diffs. They are like little uncommitted branches - which can also be turned into branches. There’s a good outline here from Atlassian.

git - Rollback to last commit

Tue, 08 Nov 2022 00:00:00 +0000

I’m on Project 12 of the #100Days course, and like a number of earlier “projects” it’s not really a project, but a series of type-along tutorials. Often these have the same format - there’s a base amount of code to provide the setup, then this base is used to try each of the tutorial techniques. At the end of each technique, you delete all the new code you’ve done back to the original setup, and you’re ready for the next one.

This is a perfect job for git. All I do is commit the code once the setup is done (and I’ve tested it). Then after I’ve mucked around, and want to go back.

git reset --hard

In fact this is all so simple, it’s probably the perfect use case for getting started with git even if you’ve never used it. The steps would be:

On a system with git installed (which includes macOS)
Open a terminal window, and navigate to the directory you want to be able to rollback later
**git init**
Create all your content
**git add -A**
**git commit -m "Some message"**
Make all your disposable changes, then when you’re done **git reset --hard**

Git - make all the commits into a single commit

Sat, 29 Oct 2022 00:00:00 +0000

When I’m following a tutorial app, I generally pause and type up the code as I go, and make local commits with appropriate messages. This is almost completely unnecessary, but it seems like a good habit and doesn’t cost me anything - I just tick the box for creating the git when I start the project, then it’s a couple of keystrokes (option-command-C) and I’m done.

Most of the apps have a follow-along portion, then some challenges which involve minor changes to the app. When I get to the challenges I like to throw it up on Github - it’s conceivable it could help someone one day, or at the least, I’m helping to train Microsoft’s AI to write shitty beginner code in exchange for free git server access.

The early commits I do are no help to anyone, even me by that stage, and it feels somehow untidy to leave them in there, so I started to wonder if there was some branchy/rebasey way to eliminate them before I push it up.

This and the related problems of just eliminating some of the recent commit history are clearly topics of interest - there’s many stackover flow posts and blog articles. But shout out to Pat Noz, for his suggestion - just delete the .git directory and start over.

When you git init, a hidden folder is created in the directory you init in called .git - you don’t normally see these hidden folders, but if you press command-shift-. you can see it. This directory holds all the data that allows the magic of git to happen. If you delete just this directory and it’s contents, it’s like you never used git on this code.

So in Pat’s words:

rm -rf .git
git init
git add .
git commit

Simple. Elegant. Obvious once you’ve had the suggestion.

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

Gitting up to date

Tue, 27 Sep 2022 00:00:00 +0000

I’ve started the habit of branching my code for each feature or batches of features. This is not really needed, I’ve developing solo, and the code on main is not in production. I could just go on committing, but part of my process is about becoming competent with git.

There are a couple of git commands (merge and rebase) that mush code between branches together in different ways. The video below (from Manuel Lorenz at Academind) is a particularly clear look at these two commands.

The discussion that follows is essentially just a re-hash of the video above, so if you think you’ve got it, you can leave now!

Here’s the situation we start with. A “feature” branch was created at the point in time that the most recent commit on the master branch was “m2”. A couple of commits have been made to the feature branch, but meanwhile a further commit has been made on the master branch:

So, what are the options now? (this is just a rehash of the video above in my words, so if you already watched that, you may leave :- ) I’m going to use “master” in my discussions here since that’s what Manuel uses, but if you’re new to git and you’ve only ever seen “main” - they are just different names for the default branch, “main” is the current (and slightly better) preference for that name.

Merge

We could checkout the master branch, and merge feature into it with

git merge feature

That works, and our commit history for the master branch will look like this:

M1 - M2 - F1 - F2 - M3 - Merge

Squash

To bundle up the feature branch and bring it across to master, we can (from the master branch) do:

git merge --squash feature

That add all the feature changes to the current branch, but they’re not committed yet, so we’ll also:

git commit -m "add feature"

The history of the master branch now will be:

M1 - M2 - M3 - add feature

So this is sort of neater, instead of a chronological history in the commits, we’re conceptually saying the feature work was all done in a single commit after the M3 change. But… what if we wanted to keep the feature commit history?

Rebase

Just to recap, although our master branch is up to m3, the feature branch was based off m2. So if we had a look at the history of the feature branch (using git log) it looks like this:

M2 - F1 - F2

Rebasing it will look at the changes in feature then apply them to the current m3 commit in master. If we change to the feature branch and enter:

git rebase master

Now the feature history will be

M1 - M2 - M3 - F1 - F2

That’s sort of cool and all, basically the code in the feature branch is in the state that master would be after we’ve joined them back up, so we can go ahead and test and so on. But we haven’t actually joined up feature and master yet. To do that, we could to checkout the master branch, and rebase it from feature with:

git rebase feature

Then master will have the same history as feature: M1 - M2 - M3 - F1 - F2 That can just be committed and we’re good to go. Since the whole commit history is now in the master branch its fine to go ahead and delete the feature branch.

Gotcha

If you’re working in a team around a shared repository, it makes a lot of sense to rebase your local project from the current main/master in the shared repo. That way you can test for any problems your code might have with the current version, but, it’s bad form to rebase any commits that get pushed up. A good explanation for why this is can be found in the git docs - scroll down to “the perils of rebasing”.

Instead what we should have done in the example above if we were planning on pushing the master would have been to rebase our feature branch as we did, but then change to the master branch and merge the feature branch in with

git merge feature

I git it*

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

This meme’s been trending in the r/ProgrammerHumor subreddit, and although “to do literally anything” is a stretch, my git / github workflow is pretty routine now using the relevant xkcd method, but actually with quite a bit of understanding from the first half of the excellent Pro Git book. I highly recommend it.

I had in my goals to set up XCode for push (I think I probably just need to generate a token on GitHub and save it in xcode), so I will do that for completion, but I’m also enjoying my pimped out terminal so I’m pretty much a git cli guy now.

I may have gone overboard creating repos for every tiny app in my learning process - sorry Microsoft you have to host all of that for free. It is probably possible to have one repo, with a heap of separate projects inside it. That would require the ability to clone just a directory and it’s sub directories, which is something I don’t know how to do yet :-/

* Yes, I’m always going to do bad git puns in post titles.

Oh My Zsh

Sat, 06 Aug 2022 00:00:00 +0000

I’ve been playing in the zsh shell since I started on the Missing Semester, and was wondering how to get my git branch name in the prompt. A few googles later, I’ve installed Oh My Zsh, and added the git and macos plugins. Pretty.

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

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.