From 2675783aeff4fcf621c750e5435604fc72568567 Mon Sep 17 00:00:00 2001 From: Oliver Davies Date: Mon, 30 Jan 2023 23:01:18 +0000 Subject: [PATCH] daily-email: 2023-01-23 --- website/src/daily-emails/2023-01-23.md | 27 ++++++++++++++++++++++++++ 1 file changed, 27 insertions(+) create mode 100644 website/src/daily-emails/2023-01-23.md diff --git a/website/src/daily-emails/2023-01-23.md b/website/src/daily-emails/2023-01-23.md new file mode 100644 index 000000000..1d2c35c32 --- /dev/null +++ b/website/src/daily-emails/2023-01-23.md @@ -0,0 +1,27 @@ +--- +title: > + Debugging with git bisect +pubDate: 2023-01-23 +permalink: > + archive/2023/01/23/debugging-with-git-bisect +tags: + - git +--- + +Last week, I had to debug a regression in a codebase. + +Something was working at the last release but is now broken. + +There have been around 20 commits to the mainline branch since the last release, and the first step to fixing the issue is to determine which commit caused the regression. + +Git has a great tool for this - `git bisect`. + +You tell Git what the last known working commit was, such as the tag of the last release, and it will start to split the commits and prompt you to tell it whether the commit is good or bad. + +If there are 20 commits, it may pick commit number 10, and based on whether the commit is good or bad, it may pick commit 5 or 15. + +Based on your answers, Git will then tell you which the first bad commit is. + +Even better, if it's something that you can script or is covered with an automated test, `git bisect` can run a command for you and find the failure automatically rather than a human needing to check manually. + +Once you've found the commit that breaks, you can view it and find and fix the bug.