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 $ git blame <file_path/file_name> 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` command specific file You can -L option to limit the line output range. $ git blame -L , new_file ^ d69a196b5c7 (Jhon Smith : : + ) def new ^ d69a196b5c7 (Jhon Smith : : + ) @article = Article.new ^ d69a196b5c7 (Jhon Smith : : + ) end aa2dbbce7 (David Smith : : + ) def edit aa2dbbce7 (David Smith : : + ) @article = Article.find(params[:id]) aa2dbbce7 (David Smith : : + ) end ^ d69a196b5c7 (Jhon Smith : : + ) def create aa2dbbce7 (David Smith : : + ) @article = Article.new(article_params) ^ d69a196b5c7 (Jhon Smith : : + ) @article.save ^ d69a196b5c7 (Jhon Smith : : + ) redirect_to @article ^ d69a196b5c7 (Jhon Smith : : + ) 11 21 95 2018 -05 -18 13 04 22 0200 11 95 2018 -05 -18 13 04 22 0200 12 95 2018 -05 -18 13 04 22 0200 13 3171 2018 -05 -16 18 21 30 0200 14 3171 2018 -05 -16 18 21 30 0200 15 3171 2018 -05 -16 18 21 30 0200 16 95 2018 -05 -18 13 04 22 0200 17 3171 2018 -05 -16 18 21 30 0200 18 95 2018 -05 -18 13 04 22 0200 19 if 95 2018 -05 -18 13 04 22 0200 20 95 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 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. `-C` option $ git blame -L -C , <file_path/file_name> 11 21 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? 1. First, let's start with the binary search mode to find a bug: $ git bisect start 2. 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 --oneline log option shows only the names of git commits. --oneline $ git log --oneline f11c599 Removed unnecessary lines 95d69a1 Added article tests 3171aa2 Enabled editing articles 95d69a1 Added articles 3. the oldest "good" commit SHA-1: Tag $ git bisect good 95d69a1 4. 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 f11c599 bisect bad 5. Once you have assigned initial and final pointers for your search, Git walks you through the and tags "good" and "bad" commits. commit history 6. 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 $ git grep <keyword> 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` command `.gitignore` GREP stands for lobal egular xpression rint. G R E P 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` Summary 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! Bugs, glitches, and coding problems we know how to solve them all! Subscribe and learn our special techniques. Previously published at https://kolosek.com/debugging-with-git/
