git

Earlier this year I wrote a post about git worktree that allows you to load different versions of an R package at once on your computer. To keep with the “juggle between versions of a codebase with Git plant-related commands” theme, let me show you how I use cherry-pick to assess the quality of an unit test. Scenario: you fix a bug in a branch In a perfect world, the bug you’re working on is paired with a ✨ reprex ✨, and you even start your work by adding a test case for it.

I’ve now explained on this blog why it’s important to have small, informative Git commits1 and how I’ve realized that polishing history can happen in a second phase of work in a branch. However, I’ve more or less glossed over how to craft the history in a branch once you’re done with the work. I’ve entitled this post “Hack your way to a good Git history” because writing the history after the fact can feel like cheating, but it’s not!

This post was featured on the R Weekly highlights podcast hosted by Eric Nantz and Mike Thomas. “Make small Git commits with informative messages” is a piece of advice we hear a lot when learning Git. That’s why we might want to sometimes rewrite history in a branch. In this post, I’d like to underline three main (😉) reasons why you’ll be happy you, or someone else, made small and informative Git commits in a codebase.

This post was featured on the R Weekly highlights podcast hosted by Eric Nantz and Mike Thomas. Do you ever see GitHub issue comments where someone posts the results of a reprex with a current package version, and then with an older one, to prove a regression? How would you go about preparing such a report? Today I learnt there is a clean way to have different versions of a codebase at once on your computer, thanks to the ever powerful Git.

As mentioned about a million times on this blog, last year I read Git in practice by Mike McQuaid and it changed my life – not only giving me bragging rights about the reading itself. 😅 I decided to give Pro Git by Scott Chacon a go too. It is listed in the resources section of the excellent “Happy Git with R” by Jenny Bryan, Jim Hester and others. For unclear reasons I bought the first edition instead of the second one.

I got more confident with Git since reading Git in practice. This has resulted in a more enjoyable Git practice! I’m also more keen to sharing Git “tips” with others, but felt it was challenging to quickly come up with examples to demo some Git workflows. This is what motivated my creating saperlipopette, an R package containing small Git playgrounds to practice various Git commands and strategies! What is saperlipopette? The saperlipopette package creates Git messes, or playgrounds, that users need to solve.

I seem to have at last entered my Git era. 🎉 Reading and applying Git in practice was probably the best thing I did for my upskilling this year. One Git workflow aspect I’ve finally realized is that it’s fine to have two phases of work in a Git branch. I’ll explain it in this post. Set up: create a branch for your work! Ideally, in most cases, when adding a feature or fixing a bug or whatever, I’ll work in a branch.

While preparing materials for teaching Git a few months ago, I re-read Suzan Baert’s excellent post about Git and GitHub, where she mentioned having read “Git in Practice” by Mike McQuaid. I added the book to my Momox alerts, where it got available a few weeks later. The book source is on GitHub. The book isn’t too heavy, so I took it with me on a long train journey! 🚋

If you’ve been taught git and GitHub but practice so rarely that you’re discouraged, what should you do to re-start more easily? Let’s imagine you have to, or really want to, use git and GitHub for your next analysis project. Here’s what I would recommend… I assume you already own a GitHub account. If not, refer to happygitwithr guidance. Thanks to the people who shared recommendations on Mastodon, whose names are acknowledged in the rest of the post!

When I create a new .git repository, my first commit message tends to be “1st commit”. I’ve been wondering what other people use as initial commit message. Today I used the gh package to get first commits of all repositories of the ropensci and ropenscilabs organizations.