From e617faf80505bfa5801a52ad1225d5e80fbf81d5 Mon Sep 17 00:00:00 2001 From: Brandon Rozek Date: Tue, 3 May 2022 01:31:11 -0400 Subject: [PATCH] New post --- content/blog/git-bisect-broken-builds.md | 32 ++++++++++++++++++++++++ 1 file changed, 32 insertions(+) create mode 100644 content/blog/git-bisect-broken-builds.md diff --git a/content/blog/git-bisect-broken-builds.md b/content/blog/git-bisect-broken-builds.md new file mode 100644 index 0000000..7d60b43 --- /dev/null +++ b/content/blog/git-bisect-broken-builds.md @@ -0,0 +1,32 @@ +--- +title: "Which commit broke the build? Using Git Bisect" +date: 2022-05-03T01:15:55-04:00 +draft: false +tags: [] +math: false +--- + +Lets imagine a scenario where in the latest merge a test +starts failing. Lets say these tests are saved +in `test.sh`. Instead of having to test each individual +commit in the merge, to see where the test fails, luckily +`git bisect` narrows it down in a more efficient way! + +To use: +```bash +git bisect start [good] [bad] +git bisect run test.sh +``` +Where `[good]` and `[bad]` are replaced with their respective +commit hashes. + +Under the hood, Git will run a binary search between the good +and bad nodes in the commit tree. + +As a reminder, don't forget to make `test.sh` an executable. +Starting in Git 2.36 it will provide a warning, but earlier +versions will perform the search anyways even with it all +failing. + + +Read more: https://git-scm.com/docs/git-bisect \ No newline at end of file