Even when with a few commands we can create a robust git flow, there are always more **tools that can make our developer lifes much easier**! `git bisect` is one of those; a functionality which helps us finding the commit where a certain change (generally a bug) took place. I have to admit that I had never read about this command until just a few weeks ago. I decided to do the LinkedIn Git exam to obtain my batch, and found that **there were some -apparently- useful commands that I wasn't using!** The most interesting one is `git bisect`. Let's have a look! # What is this 'bisect' thing? `git bisect`, according to the docs, **"uses binary search to find the commit that introduced a bug"**. So what is binary search, in the first place? **Binary search is an algorithm used to efficiently find items in an array**. Instead of just looping them one by one, the list is splitted in two; this way, you only keep the half that contains the item you are looking for. Repeating this process several times results in a match. ![80_width_image](https://marcomartinezavila.s3.eu-west-1.amazonaws.com/git-bisect/1_binary_search.jpg) The example above clarifies this procedure muuuch better than I do. Imagine you want to find the index of the number '7'. - The first step shows the initial array, where number **10 is the middle element**. - As 7 < 10, **we can already rule out the right half of the list**. We keep working with the first one, where 5 is the new middle element. - As 7 > 5, **we also rule out numbers 1 to 5**. The new middle element may be 7 or 8, depending on the implementation of the algorithm, the rounding, etc. We are chossing 7, but being 8 would only imply repeating the process once more. - As 7 = 7, **we have our item**! Already bored? Wait a second. Understanding the theory is important for `git bisect`, as it will guide you through the process and will make you realize why some commits are used, while others are not. Took some time in my case... # How does `git bisect` apply to real life? Imagine our goal is to achieve a simple SVG spinner with a seedy header. ![30_width_image](https://marcomartinezavila.s3.eu-west-1.amazonaws.com/git-bisect/2_spinner_30.gif) We start the process, write the HTML and CSS files, and after our last commit realize that the red bar is not spinning! ![30_width_image](https://marcomartinezavila.s3.eu-west-1.amazonaws.com/git-bisect/3_spinner_bug_30.gif) If the code is simple, **there is always the possibility of just inspecting it to identify the cause**. But **what happens if there are thousands of lines of code**? Or if you just have no idea were the bug may come from? Or if you are just working on a branch, but the responsible of the project is your colleage, who of course is on holidays? `git bisect` is a command that **helps finding when a certain change -tipically a bug- was introduced;** In our example, helping us to identify when the red bar stopped spinning. So, once we know the theory, let’s get into action! ## Identify two points of reference Our first task is to **identify two commits**: - **The good one**: in which the code was working as expected. - **The bad one**: usually the HEAD, where you know the change was already introduced. Let’s have a look at our git history. ```git $ git log --oneline 3e21ac1 (HEAD -> master) Reduce header height 3da83dc Fix vertical scrollbar showing in main ae8caa2 Update header aesthetics 67adeb5 Align spinner top e47a702 Improve header aesthetics 73dc527 Fix grid layout gap overflow 76ef210 Improve body layout and add header 9697309 Create spinner small moving circle 89290ea Create spinner outer circle faddc3d Create spinner middle circle c316598 Create spinner inner circle 7e29b5b Add header 49671c0 Add base HTML file ``` We already know that our HEAD has the bug, so *3e21ac1* can be our bad commit. To identify the good one, you can either check one of the intermediate ones, or even select the first project commit. This way, we would loop -using binary search algorithm- through all the changes, and will identify the origin of the problem for sure. ## Start the *bisect* process Having chosen the bad (*3e21ac1*) and good (*49671c0*) commits, we are now able to start the *bisect* process. The are several ways of doing it: - Specifying both commits separately: ```git git bisect start git bisect bad # Current commit is bad git bisect good 49671c0 ``` Alternately, you can checkout a certain commit to inspect the code, and mark it as good or bad afterwards: ```git git bisect start git bisect bad git checkout 49671c0 git bisect good ``` - Specify both commits in the start command: ```git git bisect start HEAD 49671c0 ``` Either way, the bisect process will be started. ## Inspect the changes of each step Let’s check the terminal output after introducing the last command. ```git $ git bisect start HEAD 49671c0 Bisecting: 5 revisions left to test after this (roughly 3 steps) [76ef210c7f33ce1e3403be561497b4374fb4a412] Improve body layout and add header ``` We are now in commit *76ef210*. Why? ```git $ git log --oneline 3e21ac1 (HEAD -> master) Reduce header height 3da83dc Fix vertical scrollbar showing in main ae8caa2 Update header aesthetic 67adeb5 Align spinner top e47a702 Improve header aesthetics 73dc527 Fix grid layout gap overflow 76ef210 Improve body layout and add header :arrow_left: 9697309 Create spinner small moving circle 89290ea Create spinner outer circle faddc3d Create spinner middle circle c316598 Create spinner inner circle 7e29b5b Add header 49671c0 Add base HTML file ``` If you remember the binary search algorithm, the list we are searching in (a list of commits, in this case) is splitted in two. We then get the middle element (*76ef210*), and check if the change we are looking for was already introduced. Depending on the answer: - The bug is still here, so we know that **it was introduced before the actual commit**. In this case, we would need to execute the folloging command to indicate that we are still in a *bad* situation. ```git git bisect bad ``` - The code is working correctly, so **the bug was introduced after the actual commit**. Same command as before, but in this case our commit is a *good* one. ```git git bisect good ``` Translating to our example: we check if in commit *76ef210* our red wheel is spinning. Aaaaand the answer is no, so the bug was introduced before this commit. Checking the *git log --oneline* output, the reasoning would be the following: **as *76ef210* doesn’t work as expected, we know for sure that commits from *76ef210* to HEAD are *bad***. Therefore, **one of the commits from the first one to *9697309* has our bug**! To let the process know about the current situation, it is time to execute the command we explained some lines above: ```git $ git bisect bad Bisecting: 2 revisions left to test after this (roughly 2 steps) [faddc3d4e82b6d5a103091f6bef8d2bc03b5c067] Create spinner middle circle ``` ```git $ git log --oneline 3e21ac1 (HEAD -> master) Reduce header height :boom: 3da83dc Fix vertical scrollbar showing in main :boom: ae8caa2 Update header aesthetics :boom: 67adeb5 Align spinner top :boom: e47a702 Improve header aesthetics :boom: 73dc527 Fix grid layout gap overflow :boom: 76ef210 Improve body layout and add header :boom: 9697309 Create spinner small moving circle 89290ea Create spinner outer circle faddc3d Create spinner middle circle :arrow_left: c316598 Create spinner inner circle 7e29b5b Add header 49671c0 Add base HTML file ``` Following the binary search algorithm, **our new middle element is *faddc3d***, where the red wheel is... spinning! Consequently, our next command is: ```git $ git bisect good Bisecting: 0 revisions left to test after this (roughly 1 step) [9697309eb7914338057a59e87f9b2fa6ae012435] Create spinner small moving circle ``` ```git $ git log --oneline 3e21ac1 (HEAD -> master) Reduce header height :boom: 3da83dc Fix vertical scrollbar showing in main :boom: ae8caa2 Update header aesthetics :boom: 67adeb5 Align spinner top :boom: e47a702 Improve header aesthetics :boom: 73dc527 Fix grid layout gap overflow :boom: 76ef210 Improve body layout and add header :boom: 9697309 Create spinner small moving circle :arrow_left: 89290ea Create spinner outer circle faddc3d Create spinner middle circle :heavy_check_mark: c316598 Create spinner inner circle :heavy_check_mark: 7e29b5b Add header :heavy_check_mark: 49671c0 Add base HTML file :heavy_check_mark: ``` With only two commits left, the wheel stopped spinning again in *9697309*. ```git $ git bisect bad Bisecting: 0 revisions left to test after this (roughly 0 steps) [89290ea157fadf3b0649685f32ffbe9e0e8ec3a1] Create spinner outer circle ``` ```git $ git log --oneline 3e21ac1 (HEAD -> master) Reduce header height :boom: 3da83dc Fix vertical scrollbar showing in main :boom: ae8caa2 Update header aesthetics :boom: 67adeb5 Align spinner top :boom: e47a702 Improve header aesthetics :boom: 73dc527 Fix grid layout gap overflow :boom: 76ef210 Improve body layout and add header :boom: 9697309 Create spinner small moving circle :boom: 89290ea Create spinner outer circle :arrow_left: faddc3d Create spinner middle circle :heavy_check_mark: c316598 Create spinner inner circle :heavy_check_mark: 7e29b5b Add header :heavy_check_mark: 49671c0 Add base HTML file :heavy_check_mark: ``` We can now realise how our remaining list of possibilities has decreased! Only one commit left :muscle: This means **either the bug was introduced in this or in the previous one**, and we just need to check our spinner to discover it! ![30_width_image](https://marcomartinezavila.s3.eu-west-1.amazonaws.com/git-bisect/4_spinner_working_30.gif) Finally. Our wheel is spinning, and we have completed the rebase process! As our last option was *good*, the bug must have been introduced in *9697309*. The last *good* command clearly exposes this fact. ```git $ git bisect good 9697309eb7914338057a59e87f9b2fa6ae012435 is the first bad commit commit 9697309eb7914338057a59e87f9b2fa6ae012435 Author: Marco Date: Sun Dec 19 22:44:08 2021 +0100 Create spinner small moving circle css/index.css | 12 +++++++++++- index.html | 3 +++ 2 files changed, 14 insertions(+), 1 deletion(-) ``` ```git $ git bisect reset Previous HEAD position was 89290ea Create spinner outer circle Switched to branch 'master' ``` The *reset* is used to clean up the bisection state and return to the origina HEAD; it is the last *good* command which gives use some useful information. - *9697309* is the first bad commit. That is to say, **the bug was introduced here**. - Author, date and commit message, just as *git log* output. - Updated files. There are only two, so our friend can only be in index.html or index.css. We use the *git diff* command to check, with more detail, what changed in *9697309.* ```git $ git diff 9697309~1 9697309 diff --git a/css/index.css b/css/index.css index 85482e3..a318360 100644 --- a/css/index.css +++ b/css/index.css @@ -31,7 +31,7 @@ stroke-dasharray: 400, 100; -webkit-animation: spinner-rotate 1s linear infinite; -o-animation: spinner-rotate 1s linear infinite; - animation: spinner-rotate 1s linear infinite; + animation: spinnedr-rotate 1s linear infinite; :boom::boom::boom: } #middle-circle { @@ -55,6 +55,16 @@ animation: spinner-rotate 5s linear infinite; } +#small-circle { + fill: #f6da3c; + stroke: #f6da3c; + stroke-width: 2; + stroke-dasharray: 500, 30; + -webkit-animation: spinner-rotate 3s cubic-bezier(.69, 0, .33, .99) infinite; + -o-animation: spinner-rotate 3s cubic-bezier(.69, 0, .33, .99) infinite; + animation: spinner-rotate 3s cubic-bezier(.69, 0, .33, .99) infinite; +} + @keyframes spinner-rotate { 100% { -webkit-transform: rotate(1turn); diff --git a/index.html b/index.html index 6218084..1381401 100644 --- a/index.html +++ b/index.html @@ -17,6 +17,9 @@ + ``` Ooooooh wait! Have you realised the typo in index.css? **spinner-rotate animation was replaced with spinnedr-rotate!** Surely something unexpected... and surprise surprise, restoring the previous line solves our problem. # Conclusion *git bisect* is not the most known command; morover, it was also new for me until just a few weeks ago! However, I think this is one of this tools that, even when they are oooovbiously not as used as *status* or *commit*, may be definitely useful in certain scenarios. And if you still have not had the possibility of using it, at least you may show off to your colleagues!