Git for Teams

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 stash so 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 ...