When you are working on a huge project, you may discover bugs in the code that prevent you from proceeding any further in your development. How to fix them? You can start by looking through your commit history by hand, but this would end up as a very tedious process. Thankfully, Git has multiple that can help you hunt for a bug or the culprit when things go wrong. tools Git Blame The helps you find the commit that created the specific line of code that causes a bug in a of a project. It also determines the author of the commit, making is easier to ask for more information about the code. $ git blame <file_path/file_name> **git blame** command specific file You can -L option to limit the line output range. $ git blame -L 11,21 new_file^95d69a196b5c7 (Jhon Smith 2018-05-18 13:04:22 +0200 11) def new ^95d69a196b5c7 (Jhon Smith 2018-05-18 13:04:22 +0200 12) @article =Article.new^95d69a196b5c7 (Jhon Smith 2018-05-18 13:04:22 +0200 13) end 3171aa2dbbce7 (David Smith 2018-05-16 18:21:30 +0200 14) def edit 3171aa2dbbce7 (David Smith 2018-05-16 18:21:30 +0200 15) @article = Article.find(params[:id])3171aa2dbbce7 (David Smith 2018-05-16 18:21:30 +0200 16) end ^95d69a196b5c7 (Jhon Smith 2018-05-18 13:04:22 +0200 17) def create 3171aa2dbbce7 (David Smith 2018-05-16 18:21:30 +0200 18) @article = Article.new(article_params)^95d69a196b5c7 (Jhon Smith 2018-05-18 13:04:22 +0200 19) if @article.save^95d69a196b5c7 (Jhon Smith 2018-05-18 13:04:22 +0200 20) redirect_to @article^95d69a196b5c7 (Jhon Smith 2018-05-18 13:04:22 +0200 21) else By following the of a commit you can easily see who, when and how was a specific line of code modified. Note that the prefix shows lines that were created in the initial commit and have remained unchanged ever since. partial SHA-1 ^ Use [_-C_](https://git-scm.com/book/en/v2/Git-Tools-Debugging-with-Git#_file_annotation) option to figure out where snippets of code originally came from if they were copied from elsewhere. It tells you the original author and commits regardless of the refactoring done afterward. _$ git blame -L -C 11,21 <file_path/file_name>_ is helpful when you can assume the cause of the problem. What if you had no idea how to get back to a working state? This is where comes into play. git blame git bisect Git Bisect A is a used to find out which specific commit introduced a bug or a problem in the project by doing an . You don't know what file in the project contains the bug. **git bisect** debugging tool automatic binary search If you don’t know what is breaking, and there have been a bunch of commits since the last state where you know the code worked, you’ll likely turn to for help. git bisect What does is, it divides the into "good", bug-free commits and "bad" commits by testing them with . Based on the result of the tests, Git navigates through recent commits identifying them, until it finds the culprit. This is known as a binary search algorithm. git bisect git commit tree binary search If you have multiple bugs, you need to perform a binary search for each of the bugs. How Does This Work? First, let’s start with the binary search mode to find a bug: . $ git bisect start Next, you need to look for a commit where everything was still working. To do so, let’s examine the to find what you need: . commit history $ git log --oneline — oneline option shows only the names of git commits. $ git log --onelinef11c599 Removed unnecessary lines95d69a1 Added article tests3171aa2 Enabled editing articles95d69a1 Added articles the oldest “good” commit SHA-1: . Tag $ git bisect good 95d69a1 After you have assigned the “good” tag, you need to find a to divide the commit tree where Git can apply the binary search algorithm. Since you know that the latest commit has the error, you will assign it as the “bad” commit: . “bad” commit $ git bisect bad f11c599 Once you have assigned initial and final pointers for your search, Git walks you through the and tags “good” and “bad” commits. commit history This process continues until you successfully find out the first “bad” commit, the cause of your problem. Now you can exit the git binary search mode by executing: . $ git bisect reset Git Grep The allows you to efficiently and quickly search through your project for a string or regular expression in any of the files in your source code. It avoids searching through files. $ git grep <keyword> **git grep** command .gitignore GREP stands for G lobal R egular E xpression P rint. Additional options: or : Prints out the line numbers where Git has found matches. -n --line-number or : Ignores case differences between the searched keyword and the file. -i --ignore-case or : Shows the number of matches found in the file for the inputted keyword. -c --count or : Displays the context of the searched keyword. -p --show-function : Ensures multiple matches in the same line of text. --and is a great tool if you know where the buggy code is located. On the other hand, if your repository is considerably large, with a huge commit history that makes it difficult to find the error, is the way to go. Or you could easily search through your project for a string or regular expression with . git blame git bisect git grep Three debugging tools with three different ways to fix your problems in their own unique ways. Which one did you encounter so far? Share your experience! Thank you for reading! Originally published at kolosek.com on June 18, 2018.
