Git bisect: find the commit that broke your application
Published on 2026-10-26 by frfrand
Binary search for the change that introduced a production failure
Your application worked two weeks ago and now breaks when creating a reservation. Forty commits have been merged since then. Reviewing them one by one is boring and slow; git bisect uses binary search to find the first one that introduced the bug.
The idea is to use it to solve a real problem, not to memorize commands because they look good in a screenshot. Let's go with the essentials, a working example, and the mistakes you should avoid.
What Git bisect does and when it's useful
You mark a known good revision and another as bad. Git automatically takes you to an intermediate commit; you test it and say good or bad. You repeat until you isolate a suspect. The more reproducible the test, the more reliable the result.
If you're learning, try it first in a test repository or environment. If you manage production, document the state before running anything that alters files, history, or data. That allows you to understand what changed and recover if you make a mistake.
Example to copy and understand
git bisect start
git bisect bad HEAD
git bisect good v1.3.0
# Ejecutar el test de la reserva
git bisect good # o: git bisect bad
# Al terminar
git bisect resetDon't copy the final command without checking the previous state. Branch names, host, user, or paths are examples; replace them with those from your project. Some commands modify files or make requests that can write data.
How I would use it step by step
- Step 1. Reproduce the error with a test or a short and repeatable procedure.
- Step 2. Identify a failing commit and a previous version that you know works.
- Step 3. Start bisect, mark both revisions and test the commit Git takes you to.
- Step 4. Mark each revision according to the result; use
git bisect skipif any cannot be tested. - Step 5. When finding the suspicious change, return to the original branch with
git bisect resetand review the cause.
Stop after each step and check the result. If something fails, note the exact message before changing strategy. Jumping between five random solutions usually makes it harder to find the real cause.
A case that could happen to you working with clients
A FastAPI API started duplicating reservations. You have a test that verifies that two simultaneous requests do not create the same slot. With bisect you find in a few tests the modification that stopped protecting that operation.
The goal is not for it to "work once", but for you to be able to explain how you repeat it without compromising another application. If there are client data or credentials, work with separate tests and minimal accesses.
The mistake I see most often
If the error depends on production data or an unstable external API, the test can give false results. Prepare stable fixtures or mocks. Do not run destructive migrations while bisect goes through old commits.
A simple rule: if you can't explain what the command will do to your code or server, check its official help first. This way you avoid confusing a quick fix with a new problem.
Where does ArduMaker come in?
The hash of each deployment in ArduMaker can help you delimit when an incident started. Retrieve the logs and associate the first error with a range of commits to speed up the bisect.
For example, you can deploy from a Git repository to a VPS, associate an HTTPS domain, and manage services and databases from the same environment. The panel reduces repetitive infrastructure tasks, but it does not replace Git, testing, or reviewing project permissions.
Quick questions before applying it
Does this change production? It depends on where you run the action. Test locally first, identify the affected commit or service, and prepare a recovery plan.
How do I check that it went well? Don't settle for the absence of error messages: check the status, run a functional test, and verify the corresponding logs or history.
Is it worth automating it? If it's repeatable and has verifiable results, yes. But automation should fail clearly and not hide errors or credentials.
To expand
Summary: the useful tool is not the one with the most options, but the one that allows you to understand what changed, verify it, and keep working without surprises.