Trace bugs and undo changes safely

↑

CLI examples labeled Bash work in Git Bash on Windows 10 and Windows 11, or Bash on Linux, with Git installed. Bash variable assignments such as DEFAULT_BRANCH=main are shell syntax; use Git Bash for these examples rather than pasting them into PowerShell or Command Prompt.

The goal of investigation is not to blame a person. It is to find the change that introduced a behavior, understand its context and repair it with minimum risk. Begin with the symptom: first failing version, reproduction steps, environment and expected result. Record the exact deployed commit rather than guessing from a date on the website.

Open the History tab, select a commit and inspect its changed files. Use the repository view on GitHub to open the linked pull request and issue. Desktop can help you inspect and revert individual commits, but complex history searches and automated bisection are better suited to the CLI.

git status --short --branch
git log --oneline --decorate --graph -20
git log -- path/to/file.cs
git blame -L 15,35 -- path/to/file.cs
git show --stat COMMIT_HASH

Replace example paths and commit IDs. git blame tells you which commit last changed a line, not necessarily who caused the bug; inspect the surrounding history and the related review.

Find the first bad commit with bisect

git bisect uses a binary-search-like process over commit history, reducing how many versions you need to test. You need a known good commit and a known bad commit, plus a reliable test. The result is a suspect commit to examine, not an automatic diagnosis.

# Work in a clean clone or dedicated Git worktree.
git bisect start
git bisect bad BAD_COMMIT
git bisect good GOOD_COMMIT
# At each checked-out commit: run the same reproducible test.
git bisect good    # or: git bisect bad
git bisect reset   # return to the original checkout when done

On GitHub Desktop, use History to narrow the range; for real bisection, open the same repository in a terminal. If a historical commit cannot build because of tooling changes, mark it git bisect skip and document the uncertainty.

Revert versus reset

Revert creates a new commit that attempts to undo an earlier commit. It is usually the safer choice for already-published changes. Reset moves a branch reference; --hard also discards tracked working-tree changes. Avoid using reset or force-push on protected/shared branches. Reverting a merge commit can require selecting a mainline parent, so check its history before acting.

A safe investigation often ends with a feature-branch revert pull request, verification in CI, merge into protected main, and a recorded deployment. Never assume that changing a branch automatically rolls back a running service.

Branch naming: main is an example. Use master or your repository’s actual default branch where applicable. See Git terminology.