Earlier this week I found myself in an interesting spot. We had a hell of a bug come though that had no real reason for existing, much less any kind of answer to "how did this even get there?!". Someone mentioned I should use git bisect -- I'd never heard of this. It's a little strange at first, but once I got the hang of it, it's really slick.
Say for instance your on your repository on the latest and greatest and you find a bug was introduced ... say ... three weeks ago. You don't know when exactly, but you know it was sometime in that time frame. Grab a hash code, (treeish, the first few letters of the hash I'm told are usually enough for uniqueness) and go ... something like this ...
git bisect start HEAD <someHash>
and you'll see something like this ...
$ git bisect start HEAD <someHash>
Bisecting: 174 revisions left to test after this (roughly 8 steps)
[someMiddleHash] Comment for that commit
JRiley@JRILEY /c/Projects/Core ((someMiddleHash...)|BISECTING)
What git will do is say ok, somewhere between HEAD and <someHash> was a screw up, so it will pick the middle commit and give that as a starting point. Build, do your dance and determine if its a good (problem isn't there) or bad (problem still exists) as such ... in my case, I'll say its bad.
$ git bisect bad
Bisecting: 86 revisions left to test after this (roughly 7 steps)
[yet another hash] comment for that commit