Programming By Stealth

In this week's installment of Programming By Stealth, Bart teaches us how to use GitHub as a public repository for our code, or for anything we write for that matter. He reviews whey he chose Github, and then we dig right in. He does explain the benefits of using SSH to access Github instead of HTTPS, and if you haven't set up SSH keys before or you're rusty on the topic, he includes links to our sibling show, Taming the Terminal where you can learn how to do it. We create a new repo from scratch in Github on the web with a README file and a license, and then we get to use a command line version of Github called `gh`. With `gh` we pull the repo down from Github, we edit the files, we commit them locally, and push them back up to Github all from the command line. We then flip the tables and from the command line create another repo directly on Github, create some files, set them up to track and push and pull again to prove it's working. It's surprisingly easy and simple. Bart teases us with the next episode

In previous installments of our Git miniseries within a series in Programming By Stealth, Bart taught us how to work in Git standalone on one computer, then how to work as one developer with multiple computers. In those installments he taught us the necessary commands and their importance in the Git scheme of things. In this installment he talks about how and where to work with a team in Git. We learn about the plethora of options from free to full enterprise-size Git-as-a-service, and why he'll be focusing on Github for the future. He explains how important it is to set up conventions for your team (before you start) for things like coding styles, development paradigm and more. There's no coding in this episode as it's more philosophical than other episodes. You can find Bart's fabulous shownotes over at pbs.bartificer.net/pbs115.

When Bart started this mini-series within a series on using Git for version control, he explained that our journey would be in three Phases. Phase 1 was the section where we learned about local repositories, and Phase two was dedicated to learning how to have multiple repositories just for ourselves. In this lesson, we finish up Phase 2 by learning how to push and pull changes from our imaginary desktop to our imaginary NAS to our imaginary laptop and back. I slowed down the class a few times with some confusion I had, but Bart always claims that my confusion often helps other people who might be hung up on the same thing. I enjoyed myself immensely, even when I was confused! We are about to enter Phase 3 where we will learn how to collaborate with others. We'll be doing this collaboration using Github, because it's pretty much the defacto home for most open source projects. When you're done listening to PBS #115 and studying the shownotes, you might want to get yourself a Github account so you can be ready

We continue on our journey to learn how to use Git to do version control as a single person, but this time with multiple devices. As Bart says during this episode, "Who is learning to program here who doesn't have multiple computers?" We've learned how to push our changes to a single separate repo, but we had to always say what branch we wanted to push to what branch on the origin. In this installment we learn how to tell Git to _track_ our branches so they stay in sync without us having to tell Git every time which branches to push where. We also learn how to make sure our annotated tags get pushed as well by setting a single repo or all Git repos on our computers to push our tags. Bart leaves us with a big tease at the end. We learn how to clone a repo in preparation for having two computers accessing the same code in Git with a primary source acting as the go between for them.

Last time on Programming By Stealth, Bart introduced the concept of remote repositories, also known as remotes. It was one of those episodes where we learned a lot but didn't get to apply what we learned. In this week's installment we get our hands digitally dirty as we create a _bare repository_ (a repo with no working tree), and declare it to be a backup of our local repo. We learn how to fetch and view remote branches and tags, how to push everything to the remote, and then after making some changes, push them to our remote backup. We're still in a bit of a sandbox as we do all this on one computer inside a couple of local folders, but the lessons exercise our new muscles to get ready for the big leagues. Bart's excellent tutorial show notes are as always available at pbs.bartificer.net/... [audio mp3="https://media.blubrry.com/nosillacast/traffic.libsyn.com/nosillacast/CCATP_2021_04_03.mp3"] mp3 download

In this next installment in our mini-series on learning Git, Bart Busschots gives us some foundational knowledge on how to work beyond being one person with one Git repository. He starts by reinforcing what he's explained before, that Git is a peer-to-peer technology, which is hard to wrap your head around if you're used to client-server relationships. He walks us through three scenarios to explain how every "actor" gets a repository and why. Then he explains the jargon of "local" vs "remotes". It's at this point that my head started to hurt, but Bart claims this is where I'm value-added to the podcast. I ask all the questions you might have, and I suspect many more than you have. Bart sticks with me and makes sure I fully understand. You can find Bart's tutorial show notes at: pbs.bartificer.com

In this installment of Programming By Stealth, Bart teaches us how Git can help us when we forget to switch to the correct branch before starting to make changes to our code. We're only human, and we will forget, and Git's `stash` command allows us to set our changes aside, switch to or even create and switch to the correct branch and then apply our changes. His explanations and repetition in the exercises really cement the knowledge. As a bonus tip, he teaches us how to make shell variables inside the Terminal which will help us with some of the repetitive typing in the future. Bart's tutorial shownotes are at pbs.bartificer.net/pbs111

In this installment of Programming By Stealth Bart teaches us how to deal with conflicts in branches of our code. He has been purposely only changing one thing at a time before now, but it's time to face the reality of when two branches change the same line in the same file. I've been terrified of this topic for a long time, but Bart shows us how easy it is to see exactly what the conflict is, how you can back out of merging if you make "a pig's breakfast" of it, and how to resolve your conflicts without fear. It's not nearly as terrifying as I thought it would be. You can find Bart's tutorial show notes at [pbs.bartificer.net/...](https://pbs.bartificer.net/pbs110) And if you learn a lot from Bart, please consider becoming a patron of his by going to [www.patreon.com/...](https://www.patreon.com/ltpod/posts)

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 tut

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 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 promisin

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/...

Bart takes us on a time traveling adventure with Git. By using commands like `git diff` we can see changes over time, but we can actually see older versions of the code in a couple of ways. Using the `archive` command we learned out to pull just the files at a certain point in time (without the history) and the more terrifying `checkout` command that creates a "detached HEAD"! Bart even explains why that phrase was introduced and what it actually means. This was a fun lesson and a good foundation for what we'll learn next time, when we'll learn about stashing and branching to control the past and future.

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. I enjoyed this installment because I could tell it was laying a very important foundation of understanding. You can follow along with Bart's famous shownotes at pbs.bartificer.net/... allison@podfeet.com Support B

After some quick revision from the previous episode, Bart explains how Git commands work with their subcommands. We start by looking at how to configure Git and the differences between local, global and system-level settings. Then we create our very first repo with an exciting README file, and we commit the file to our repo. It's a fairly simple lesson while laying down a good foundation for all future work. You can find the shownotes for this installment at PBS 103 of X — Getting Started With Git allison@podfeet.com Tesla Affiliate Link podfeet.com/patreon podfeet.com/slack podfeet.com/facebook podfeet.com/paypal

In our last Programming By Stealth we learned about the concept of version control, and the evolution from client/server version control to peer-to-peer version control and the creation of Git. In this installment we start learning the fundamental concepts of Git. We learn about the database, the working copy, and the index and understanding the difference is critical to effectively using Git. We also dig into the Git database and begin to learn the terminology inside it, which oddly uses normal English words but those words might not mean what you think they mean. We gain an understanding of why Git uses SHA1 hashes but not for encryption. We start to get into the power of Git as we learn about commits, staging, stashes, and tags. We didn't get to play with Git yet but the challenge is to install Git and if you want the extra credit, choose and download one ore more Git GUI clients.

It's time to take on a new subject: version control. As Bart explains in this week's episode, version control allows you make changes in your code and roll the changes back. This gives us the freedom to experiment and if an idea doesn't pan out, get back to where we started. Bart explains some of the origins of version control, starting with client server systems and then tells us how peer-to-peer version control has become the standard from industry to open source. Bart explains how the version control system Git was created and how it proved itself worthy of becoming the standard. There's not a lot of heavy lifting in this episode but Bart promises that future episodes will be challenging as we get into how to actually use Git. If you like Bart's work, please support him by going to lets-talk.ie and becoming a Patron.

In this positively _delightful_ episode, Bart and I celebrate 100 episodes of Programming By Stealth. When we hit 99 instalments, Bart declared that for 100, there should be cake! So I got Bart's darling beloved to deliver him a piece of cake right as we started, and Steve delivered one to him. To say that Bart was surprised and delighted would be an understatement! This episode is entirely dedicated to us describing our solutions to the Time Sharing challenge from PBS 96, and to explaining what we learned while working on the assignment. You can view Bart's working solution at this-ti.me/ and you can view Allison's working solution at podfeet.com/time-shifting-clock

This week our guest is Dr. Helma van der Linden from the Netherlands here to talk about how she created the Taming the Terminal book using all Open Source software. On the NosillaCast I talked a lot about the book but I should probably give an explanation for the Chit Chat audience. Bart Busschots and I created the Taming the Terminal podcast and for this series on learning the macOS (and Linux) command line, Bart wrote a spectacular set of tutorial shownotes on his website at bartb.ie. I had a dream for many years to make Taming the Terminal into a book as a surprise for Bart, but my few attempts to do it failed spectacularly. Around Easter, I mentioned my dream to Helma and she said, “I bet I could do that!” I don’t expect anyone to learn from this discussion how to do what Helma did, but rather to learn what’s possible and how cool it was that Helma put these pieces together. Below are the rough shownotes we used for our discussion, included so that you would have the links to all of the tools s

Bart and I are taking a few weeks off from Programming By Stealth as we do every summer but we'd like to encourage you to check out the new Taming the Terminal episodes we'll be publishing instead.