Chapter 9. Finding and Fixing Bugs
Even the best review processes will sometimes allow a bug into production. Perhaps the bug was introduced by a bad merge, or a scenario your tests didn’t cover. Whatever the cause of the problem, Git will be able to help you uncover at what point, and by whom, the offending code was introduced. This will allow you to understand the context of how the code ended up in the system, and tell you who the best person is to help you unpack a problem in an area of the code base you might not be familiar with.
There are two main ways to apply your forensic investigating skills: use the existing code to locate the problem and use the history of the code to locate the problem. You will be most effective when you use both of these techniques. When I’m debugging code, for example, I almost always start by looking at the code itself. This is left over from all of the frontend web development I’ve done, where it’s easiest to use a tool like Firebug to pick apart a web page to find the offending CSS. It’s definitely not the only way to debug code—and for many projects it will not be a viable strategy.
In this chapter, you will learn how to:
-
Set aside your current work with
stashso you can check out another branch -
Find the history of a file with
blame -
Find the last working commit with
bisect
By the end of this chapter, you will also have a better understanding of how you store history in Git now will affect how you can recover from mistakes tomorrow. ...
Become an O’Reilly member and get unlimited access to this title plus top books and audiobooks from O’Reilly and nearly 200 top publishers, thousands of courses curated by job role, 150+ live events each month,
and much more.
Read now
Unlock full access