git

I rarely use git-bisect, but thinking about it has changed how I structure my commits. The principle is simple: don’t break git-bisect. If a change breaks something, the fix should belong in that same change. This mental model helps avoid common anti-patterns like splitting a bug fix into two commits—one with a failing test, one with the fix. Even if you never run bisect, thinking “would this commit work in isolation?” creates a provably linear set of working changes rather than an aspirational attempt at correctness.

Let’s explore how to create a one-liner for fuzzy matching when navigating git worktrees. The ideas demonstrated here can be used to solve many more types problems beyond worktrees and even git.

If you work with Git as your version control system, you’ve likely already resigned yourself to the fact that it’s a complicated beast. Git is a fantastic tool, but it can be cumbersome to navigate repositories, logs, the stash, etc. That’s where a tool like Tig comes in.

Anyone who spends a lot of time working with Git will eventually need to do some form of context switching. Sometimes this adds very little overhead to your workflow, but other times, it can be a real pain. Let’s discuss the pros and cons of some common strategies for dealing with context switching.

I’m going to show you a couple of handy tricks that I use to help Git “Do What I mean”.