Programming By Stealth

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