Version Control and Developer Tooling Questions

Direct answer

git bisect finds the exact commit that introduced a regression by binary-searching your commit history: you tell it one commit known to be good and one known to be bad, and it checks out the commit halfway between them for you to test; you report good or bad, and it halves the remaining range each time until exactly one commit is left. Automated with git bisect run and a script whose exit code reports good/bad, the same search can run entirely unattended, which is what makes it usable in CI.

Structured elaboration

Manual workflow:

git bisect start
git bisect bad                 # HEAD (the current commit) is bad
git bisect good v1.4.0         # this old tag/commit is known good

Git checks out the midpoint commit between them. Run your test, then tell git the result:

git bisect good   # or
git bisect bad

Repeat, git narrows the range by roughly half each round, until it reports something like <hash> is the first bad commit. Finish with:

git bisect reset   # return to your original branch/commit

Automating it: if the test can run non-interactively and its exit code reliably reflects pass/fail (0 for good, non-zero for bad), hand the whole loop to git:

git bisect start HEAD v1.4.0
git bisect run ./run-tests.sh

git bisect run checks out each midpoint, runs the script, interprets the exit code itself, and continues automatically, no human interaction needed, which is exactly the shape you'd wire into a CI job: trigger it manually (or on a schedule) with a known-good ref and the current bad ref as inputs, and let it report the offending commit.

Complexity. Because the search halves the remaining range each step, finding the culprit among N commits takes on the order of log2(N) test runs. For example, bisecting 1,000 commits takes at most 10 rounds (2^10 = 1024 ≥ 1000), versus testing every commit individually, which would take up to 1,000 runs in the worst case.

Worked example

A regression is somewhere between tag v1.4.0 (known good, 1,000 commits ago) and HEAD (known bad). git bisect start, git bisect bad, git bisect good v1.4.0 puts git at roughly commit 500. The test fails there, so git bisect bad narrows the range to commits 500 through 1,000, next midpoint around commit 750. This continues, each round halving the remaining range, until git isolates a single commit as the first bad one, roughly 10 rounds total for the 1,000-commit range, matching the log2(1000) ≈ 10 estimate above.

Trade-offs and pitfalls

A commit that's genuinely untestable at some point in the range (doesn't build, missing a dependency that existed later) forces git bisect skip instead of good/bad, which weakens the binary search slightly but still converges. A flaky or non-deterministic test is far more dangerous when automated with git bisect run, since the script's exit code is trusted blindly, a test that intermittently fails on a genuinely good commit sends the whole search down the wrong half of the range, and the reported "first bad commit" is simply wrong. Before trusting bisect run in CI, the test script needs to be deterministic (or retry-hardened) specifically for this reason. Merge commits can also obscure which side of a merge actually introduced the bug; git bisect --first-parent restricts the walk to mainline history only, useful when you only care about which merge brought the regression in, not which individual commit inside a feature branch did.

Direct answer

A local branch is a pointer that exists only inside your own clone, invisible to anyone else until you push it. A remote-tracking branch, such as origin/feature-x, is your local repository's read-only bookmark for where a branch actually sits on the remote server, and it gets created and updated automatically as you push and fetch. Setting "upstream" links your local branch to that remote-tracking branch, so a plain git pull or git push knows where to sync without you naming the remote and branch every time.

Structured elaboration

Three distinct things are involved: the local branch (your pointer), the remote branch (the actual branch living on the server), and the remote-tracking branch (your local, read-only mirror of the remote one). git push -u origin <branch> creates the remote branch and, in the same step, sets your local branch to track it.

Worked example

# make sure local main is current before branching
git checkout main
git pull origin main

# create a new local branch and switch to it
git checkout -b feature/add-retry-logic

# ... make changes, then stage and commit ...
git add .
git commit -m "Add retry logic for flaky network calls"

# push the branch to the remote and set it to track origin/feature/add-retry-logic
git push -u origin feature/add-retry-logic

Typical pull request steps on GitHub or GitLab (same concept, different name, a merge request on GitLab):

• Open the repository in the web UI; after a push, both platforms usually show a banner offering to open a PR/MR for the branch you just pushed.
• Click "Compare & pull request" (GitHub) or "Create merge request" (GitLab); set the target branch (usually main), add a title/description, and add reviewers.
• Wait for required CI (continuous integration: automated build and test jobs) checks to pass; address review comments by pushing more commits to the same branch, which updates the PR/MR automatically without opening a new one.
• Merge once approvals and checks are complete.

Key points

After the first -u push, later git push and git pull on that branch no longer need the remote or branch name spelled out. git branch -vv shows which remote-tracking branch each local branch is currently tied to.

Common mistakes and edge cases

Pushing without -u the first time still creates the remote branch, but does not set upstream, so the very next plain git push on that branch errors out asking you to specify a remote and branch explicitly. If two people independently branch off the same name, the first person's push wins; the second person's -u push is rejected as a non-fast-forward push until they pull or rebase onto the new tip first.

Direct answer

HEAD normally points at a branch name (you're "on main"), which in turn points at a commit. Detached HEAD means HEAD points directly at a commit instead of at a branch name. Any new commits you make in that state aren't attached to any branch, and the moment you check out something else, they become unreachable and eventually eligible for garbage collection. It happens most often from checking out a specific commit hash, a tag, or a remote-tracking branch directly (e.g. origin/main) rather than a local branch.

Structured elaboration

How it occurs: git checkout <commit-hash>, git checkout <tag>, or git checkout origin/main (checking out a remote-tracking ref instead of your own local main) all put you in detached HEAD. Git warns you explicitly when this happens.

Two ways to recover:

1. If you haven't switched away yet: run git switch -c recovery-branch (or the older git checkout -b recovery-branch). This immediately creates a new branch pointing at HEAD's current commit, attaching whatever you committed to a real branch before it can be lost.

2. If you already switched away and the commits look gone: use git reflog, git's local record of every place HEAD has pointed. By default git prunes reflog entries after 90 days, but that window is shorter, 30 days by default, specifically for entries pointing at a commit that isn't reachable from any branch, exactly the detached-HEAD-then-switched-away case, so don't wait too long. Find the lost commit's hash in the reflog, then git branch recovery-branch <hash> to reattach it (or git checkout <hash> followed by git switch -c recovery-branch).

Worked example

Illustrative transcript, hashes are placeholders (yours will differ):

$ git checkout a1b2c3d
Note: switching to 'a1b2c3d'.
You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by switching back to a branch.
...
$ echo "quick fix" >> notes.txt
$ git add notes.txt
$ git commit -m "quick fix"
[detached HEAD 9f8e7d6] quick fix

At this point, running git switch -c rescue-fix attaches commit 9f8e7d6 to a new branch called rescue-fix, and it's safe. If instead the developer had run git switch main first without creating a branch, 9f8e7d6 would appear "lost," recoverable via git reflog, which would show an entry like 9f8e7d6 HEAD@{1}: commit: quick fix, giving the exact hash to reattach with git branch rescue-fix 9f8e7d6.

Trade-offs and pitfalls

Detached HEAD itself isn't dangerous, it's a normal, intentional state for briefly inspecting old code or a tag. The risk is entirely about committing while in it and then forgetting you're not on a branch. The reflog is a genuinely strong safety net, but it's local-only (it lives in your .git directory, not on any remote) and it does eventually expire unreachable entries, so the sooner you create a branch for work you want to keep, the safer you are.

Direct answer

find /var \( -path /var/lib/docker -o -path /var/run \) -prune -o -type f -print0 \
  | xargs -0 du -h \
  | sort -rh \
  | head -n 10

This prunes the excluded directories before find even descends into them, NUL-delimits filenames so spaces and even embedded newlines cannot corrupt the pipeline, and sorts human-readable sizes in descending order.

Structured elaboration

Key points, piece by piece:

• \( -path /var/lib/docker -o -path /var/run \) -prune: matches either excluded path and stops find from descending into it at all. This is an exclusion at traversal time, not a filter applied after the fact, so find never even lists the files inside those trees.
• -o -type f -print0: the "or" branch that applies to everything not pruned: "give me regular files, NUL-terminated."
• -print0 / xargs -0: filenames are separated by the NUL byte (\0) instead of whitespace or newlines. NUL is the one byte that can never legally appear inside a Unix filename, which is what makes this delimiter fully safe, including for filenames containing spaces or embedded newlines.
• du -h: human-readable sizes (K, M, G) per file.
• sort -rh: -h sorts by numeric value while understanding the K/M/G suffix (GNU coreutils sort; if you are on a minimal environment without it, sort raw byte sizes from du -b or du -k and format afterward), -r reverses it to descending.
• head -n 10: keep the top 10.

Worked example

Real /var contents differ machine to machine, so this is a small, reproducible stand-in directory built to demonstrate the same pipeline, not the real /var.

$ mkdir -p "mockvar/log" "mockvar/lib/docker" "mockvar/run" "mockvar/weird dir"
$ head -c 500000  /dev/urandom > "mockvar/log/app.log"
$ head -c 2000000 /dev/urandom > "mockvar/lib/docker/bigimage.tar"
$ head -c 900000  /dev/urandom > "mockvar/run/socketfile"
$ head -c 1200000 /dev/urandom > "mockvar/weird dir/file with spaces.log"
$ head -c 300000  /dev/urandom > "mockvar/small.txt"

$ find "mockvar" \( -path "mockvar/lib/docker" -o -path "mockvar/run" \) -prune -o -type f -print0 \
    | xargs -0 du -h | sort -rh | head -n 10
1.1M	mockvar/weird dir/file with spaces.log
492K	mockvar/log/app.log
296K	mockvar/small.txt

This was run exactly as shown. The docker and run directories, and everything under them, never appear even though they contain the two largest files created, they were pruned before being measured. The file with spaces in its name is measured correctly as one entry.

Complexity & edge cases

• Complexity: one find traversal that never enters the pruned subtrees, proportional to the number of directory entries actually visited. The pruning is what keeps this cheap on a busy host where /var/lib/docker can contain enormous numbers of image layer files.
• Embedded newlines are a genuinely nasty edge case. I tested this directly: a file named with a literal newline byte in it is still delivered to du intact as one argument via -print0/xargs -0, so it is sized correctly as a single entry. But du and sort are themselves line-oriented tools, so when they print their own report, that filename's newline still makes it visually straddle two output lines even though it is one file. The pipeline is byte-safe up to xargs; the display from du/sort is where a newline in a name can still look like two lines.
• -prune must be combined with -o and the grouping parentheses exactly as written. Dropping the -o (or the parentheses) silently changes what actually gets excluded, this is the single most common mistake with this idiom.
• A broken (dangling) symlink under /var does not match -type f and is silently skipped, which is usually the behavior you want here.

Direct answer

Use pre-commit hooks for cheap, deterministic, auto-fixable rules (formatting) and CI as the real gate for anything you actually want to block a merge on, since a pre-commit hook can be skipped. Roll new rules out as warnings before making them blocking, and do the one-time reformat of existing code as a single dedicated commit rather than scattering it across normal pull requests.

Structured elaboration

• Pre-commit vs CI: pre-commit hooks run locally and are ideal for cheap, deterministic, auto-fixable checks like formatting, so a badly formatted diff never even gets pushed. CI is the actual enforcement gate: a pre-commit hook can be bypassed with git commit --no-verify or simply never installed, so CI re-running the same checks is what cannot be skipped by an individual.
• Auto-fix vs review changes: formatting issues should auto-fix (or fail the local commit until run), they are not a matter of judgment. Linting issues that require a human decision, for example "this variable really is unused, delete it or was that intentional," should surface as a review comment rather than a silent automated change that could alter behavior.
• Incremental rollout: turn new rules on as warnings first so the team can see the actual violation volume before it becomes a hard CI failure. If the tool supports it, enable "fail only on new violations" against a baseline, so old code does not have to be fixed before anyone can merge anything.
• Avoiding large rewrite PR noise: run the full-codebase reformat as one dedicated commit, reviewed and merged on its own, never mixed into a feature PR. Immediately register that commit's hash with git config blame.ignoreRevsFile .git-blame-ignore-revs (a Git feature since 2.23) so git blame skips over the mass reformat and keeps attributing lines to whoever actually wrote the logic.

Worked example

An illustrative rollout sequence for adopting a formatter and linter (for example Prettier and ESLint) on an existing JavaScript codebase:

1. Add config files and enable pre-commit auto-fix for formatting only; CI still passes, linting is not yet enforced.
2. Reformat the whole repository in one commit, and add that commit's hash to .git-blame-ignore-revs.
3. Turn on linting in CI as non-blocking (report only) for a couple of weeks so the team can see and fix real violations at their own pace.
4. Flip linting to blocking in CI. Pre-commit now runs both the formatter and the linter locally, so almost nothing reaches CI red in the first place.

Trade-offs & pitfalls

• Reformatting files opportunistically as people happen to touch them, instead of doing the dedicated one-time reformat, scatters unrelated whitespace diffs across every future PR for months. This is the single biggest source of reviewer friction with linting rollouts.
• Making a brand-new rule blocking in CI on day one, before anyone has seen the violation volume, tends to get the whole initiative reverted by a frustrated team; a warning period buys buy-in.
• Relying on pre-commit alone with no CI enforcement makes the rule optional in practice, since --no-verify and simply not installing the hook both bypass it silently.