A bug was introduced at some point in the last month. You know how to test for its existence, but don't know what code introduced it. What's the most effective way to find where the bug was created?
Most computer scientists have had to implement binary search – it's one of the more simple and intuitive algorithms that's also fast. But few utilize one of its more practical manifestations: git bisect. The algorithm goes like this: find the latest revision where the code works, and pick the middle revision between that and now. If that works, then the bug was introduced in a later revision, if it doesn't, the bug was introduced in an earlier revision. Continue until you find the bug – O( log n ) time complexity.
You could try every single revision to search for the bug, but that wouldn't be very quick. Instead, figure out the last time the code was working as intended, and bisect. Git doesn't always have the best UX, so maybe it's just hard to use bisect practically. Here's an example.
$ git bisect start
$ git bisect bad # current version is bad
$ git bisect good v0.9.0 # this was the last known good version
Then git will automatically pick the commit to test. Then run your unit test or script that checks for the bug, and report back to git with either git bisect good or git bisect bad.
Eventually, you'll get the exact revision where the bug was introduced, and you can remedy everything. git bisect reset will take you back to your original starting point.
You can even run your tests automatically at each commit with git bisect run your_script.