Imagine you work with a huge legacy codebase. One day you write a feature and it works. However, you work in a team and you document your feature so badly that no one knows about it. Someone touches the code while you are out. To make it worse – many times, many people. You return and discover that your precious feature is broken. We have a regression. You want to fix that. How?
Well, the best way to do that is to find the commit which breaks things. You remember the last time your feature was fine. The problem is there are about 100 commits in the codebase since then. And they are spread all over the branches.
The best approach: Git Bisect
Where to start? There are different approaches, but let me show you the most effective one, namely Git Bisect. Watch the video to find out how it will speed up your bug hunting process significantly.
My motivation to make this talk was to increase the awareness of Git Bisect´s existence. The surface of bisecting is being barely scratched by me. However, I’m glad that I can recommend some resources covering it broadly. I hope this tool will get as popular as it should be.