Some code is broken, and you can’t figure out why. Maybe there are a lot of changes to consider, and identifying that breaking change seems impossible. Or, maybe you’re curious about how things generally break in your organization. The tool you need is git-bisect.

You’ve been working on a big set of changes, and haven’t committed to Git yet. Now, you want to commit some, but not all, changes to a file. Let’s look at adding patches.

I’m working on a team where we keep a clone of the development branch (the main place where work is done), used to deploy to a QA environment. The benefits of this branching technique are:

• clone is isolated from work
• It’s easy to tell what was deployed to QA– clone is the source of truth

My current favorite command line alias is mgrim, composed of four other aliases. Here’s what it is, and what it does.

Many pull requests go through a cycle: programmer opens pull request, maintainer gives feedback, programmer makes changes, repeat until ready to merge, maintainer merges. Prior to the merge, the pull request can be messy, full of reverts, fixups, and WIP commits. In the end, those commits are noise. We can tell a better story by squashing the branch.