We continue our mini-series within a series learning the version control system Git. We learn two methods to enhance our branching strategy. First, we'll walk through some basic principles on how to number our released versions of our code. From there we'll explore three types of changes that would cause a change in our release version: fixes, new features, and breaking changes. Each of these types of updates to the version of our code can be articulated with Semantic Versioning, also known as SerVer. This numbering convention informs users of our code on the meaning of each release. Finally, we marry these concepts by creating meaningful commit messages using another convention called Conventional Commits. Not only can a user of our code see at a glance what happened in a specific commit, documentation can be auto-formatted to explain the commits.

There's not a lot of hands-on in this lesson but as a structured person, I really appreciate these conventions and why they're important.

You can find Bart's tutorial shownotes at pbs.bartificer.net/...

In this installment of Programming By Stealth, Bart Busschots continues on his series within a series explaining the version control system Git. We advance in our branching strategy by working several commits on our dev branch and then learn to use a merge commit to bring only the final commit into the main branch, leaving the half-working intermediate commits to exist only on the dev branch. This process illustrates the need to learn about tags, both light-weight and annotated. Once we understand how these tags work and their importance, we evolve our PBS branching strategy one step further.

Bart's tutorial shownotes are available at pbs.bartificer.net/...

This week's guest is Tom Merritt, prolific podcaster, author, and lover of dogs. I asked Tom to come on the show to explain how on earth he does as much as he does. We walk through all of his podcasts, what he has to do to prepare for them, and how he makes the time to get all of them done. He talks about the research required for each of them and even how some require him to watch TV. On top of podcasting, he's an author, he walks his dogs, he exercises, and even spends time with his wife, Eileen.

This week in our miniseries on learning the version control system Git, Bart dips our proverbial toe into branching. Branches allow us, as developers, to work on bugs or feature enhancements in a separate place from our stable code, and only merge the code back in when the bugs are squashed or the features are stable.

We don't get much practice in this instalment, but rather Bart talks to us about the idea of having a strategy for when to branch and how to name your branches in order to prevent chaos. He gives us some simple and yet difficult to adhere to strategies and then takes us through more rigorous strategies that will actually be easier to follow. He emphasizes that he's not telling us which strategy to follow, but rather to have a strategy.

We do a few small examples from the command line, but we get to open our Git GUI clients, like GitKraken and Sourcetree and see how the commands we're typing are graphically represented in the clients. It's a good illustration of what Bart has been promising us – that the GUI clients are doing exactly what the command line is doing.

You can find Bart's tutorial shownotes at https://pbs.bartificer.net/pbs107. And if you'd like to support Bart on Patreon, go to patreon.com/ltpod.

As we continue to learn Git from the command line for version control, Bart teaches us some tricks to travel through time. First he shows us how to view more compact Git logs so we can just see a shortened hash and the first line of our commit message. Then he shows us how to pick out a single commit from the past and see what changed. Then he shows us how, with surgical precision, we can go back in time and get a single file or even just the changes from a specific commit and bring them forward in time. It sounds head bendy but I could immediately see the usefulness of going back in time and grabbing some code that was working well and bringing it forward.

You can read Bart's tutorial shownotes at pbs.bartificer.net/...

It wouldn’t be an Apple announcement week without Lory Gil joining us, managing editor of iMore. We start the conversation by talking about what all of the new M1 Macs have in common, which is much more than we're used to seeing. Then we talk about what System on a Chip (SoC) actually means and why it's so important to us. There is a very subtle, but possibly important difference between the 256GB and 512GB storage models of the MacBook Air, which makes it even more interesting to decide between the MacBook Air and the MacBook Air that were just announced. We explore why Apple never said the word "gigahertz" and how that makes the nerds crazy because we can't compare the models to the previous Intel-based Macs. We explore the future just a bit and start dreaming of the next models Apple will release.

You can follow the wonderful Lory Gil at @appaholik and even email her at [email protected]. She has really enjoyed hearing from those of you who have written to her.

In our next baby step in learning to use the version control system Git, Bart teaches us how to track changes. We start by doing a bit of housekeeping, especially for Mac users to set Git to always ignore those pesky .DS_Store files. We learn how to stage and then commit a simple change, then we stage and commit multiple changes and even learn to see the differences in our staged files from the database all from the command line.

While we all think we're capable of making one structural change and then committing our changes, Bart knows that it isn't going to happen. But there's still a way to follow Helma's advice to "commit early and commit often". Bart teaches us how to divide the changes we inevitably make into separate commits with separate comments so we can figure out what we did later.

Lory Gil, managing editor from iMore is back to talk about the new toys announced by Apple this week. In a show where we do NOT talk about 5G we instead talk about how cool it is that Apple brought so many features to the entire product line of iPhones, and then we go deep into a couple of the differences between the models. We talk about magnetometers, nano ceramic crystals and more nerdy terms. Lory speculates on what fun things we'll get out of the MagSafe connector - like maybe we can stick our phones to our refrigerators. I nerd out a bit on size and weight specs (did you know the 12 is 12% thinner than the 11, and the 12 Pro is 9.4% thinner than the 11 Pro?

In any case, we had a blast together as we always do, and she promised to come back when Apple announces the new Silicon-based Macs, which John Prosser's rumor says will be on November 17th.

If you'd like to interact with Lory, you can follow her on Twitter @appaholik, you can email her at [email protected] and of course you can read her work at imore.com.