Version Control and Developer Tooling Questions

Direct answer

Interactive rebase (git rebase -i <base>) lets you rewrite a range of your own local commits before merging: reorder them, squash several into one, reword messages, edit contents, or drop commits entirely. Git opens an editable list of the commits (oldest first) with an action assigned to each, replays them in order according to what you chose, and produces a cleaner, more reviewable history, at the cost of changing every rewritten commit's hash, which is exactly why doing this on a branch other people have already built on is risky.

Structured elaboration

Command: git rebase -i <base>, where <base> is the commit before the first one you want to touch, for example HEAD~5 for the last five commits, or main for everything since the branch diverged.

Todo-list actions git gives you (oldest commit first, the reverse of git log's newest-first order):

• pick keep the commit as-is
• reword keep the content, edit the message
• edit pause after applying this commit so you can amend or split it
• squash merge this commit into the previous one, combining both messages for editing
• fixup merge into the previous one, discarding this commit's message entirely
• drop remove the commit
• reordering lines in the file reorders the commits

Worked example

A feature branch with five commits (hashes below are illustrative placeholders, running this yourself will produce different real hashes):

$ git log --oneline main..feature-login
e5f6a01 fix login bug
d4e5f90 wip styling
c3d4e89 add password validation
b2c3d78 fix typo in error message
a1b2c67 add login form

(git log --oneline lists newest first, so oldest-to-newest here is a1b2c67 → b2c3d78 → c3d4e89 → d4e5f90 → e5f6a01.)

Goal: fold the typo fix into the commit it was fixing, split a forgotten test file out of the validation commit, and fold the bug-fix commit into the styling commit. Run git rebase -i main and edit the todo list git opens to:

pick a1b2c67 add login form
fixup b2c3d78 fix typo in error message
edit c3d4e89 add password validation
pick d4e5f90 wip styling
squash e5f6a01 fix login bug

Saving and closing the editor starts the replay. Git applies a1b2c67, then silently folds b2c3d78 into it (fixup drops the message). It applies c3d4e89 and pauses (edit), letting you add the forgotten file and fold it in:

$ git add tests/test_login.py
$ git commit --amend --no-edit
$ git rebase --continue

Git applies d4e5f90 as-is, then folds e5f6a01 into it (squash opens an editor to combine the two messages into one). The branch now has three commits instead of five, each self-contained and reviewable.

Risks on a shared branch

Squashing, reordering, or editing changes a commit's content or parent, and a commit's hash is derived from both, so every rewritten commit gets a new hash. Anyone who already pulled the old commits now has history that has diverged from yours. If you force-push the rebased branch, their next git pull either creates confusing duplicate commits or conflicts outright, and any unpushed work they built on top of the old commits gets orphaned unless they also rebase onto your new history.

Mitigations: only interactively rebase commits that are still unshared, typically your own feature branch before you've opened the PR or before anyone else has pulled it. If the branch must already be shared, use git push --force-with-lease instead of a bare --force (it refuses to push if the remote has commits you haven't fetched yet, so you don't silently overwrite someone else's work), and tell collaborators explicitly to rebase their local copy onto the new tip rather than merge it.

Trade-offs and pitfalls

Interactive rebase produces a cleaner, more intentional history, which is genuinely valuable for future git blame/git log readability, but it is a real risk on anything already shared, and it's easy to lose work during a botched squash/edit sequence if you don't have the reflog (git's local record of every place HEAD has pointed) as a safety net to fall back on.

Direct answer

Four of these five signals are conventions a process can catch and act on; SIGKILL is the one exception the kernel enforces unconditionally. SIGTERM is "please stop" from a process manager, SIGINT is "please stop" from an interactive terminal (Ctrl+C), SIGQUIT additionally requests a debug core dump, SIGHUP originally meant "your terminal disconnected" but is commonly repurposed by long-running daemons as "reload your config," and SIGKILL cannot be caught, ignored, or handled at all.

Structured elaboration

The kernel's OOM killer (out-of-memory killer: it force-kills a process to free memory when the whole system is critically low on it) is the other common source of an unrequested SIGKILL, alongside an explicit kill -9.

A well-behaved service traps SIGTERM (and usually SIGINT, for consistent behavior in manual testing) to run its own shutdown sequence: stop accepting new work, finish in-flight requests, close connections, then exit. SIGKILL exists specifically for the case where that graceful path has already failed or is not trusted.

Worked example

#!/usr/bin/env bash
set -euo pipefail

cleanup() {
  echo "[graceful] caught SIGTERM, finishing in-flight work..."
  sleep 1
  echo "[graceful] cleanup complete, exiting 0"
  exit 0
}

trap cleanup SIGTERM

echo "[graceful] pid=$$ running, waiting for signal..."
while true; do
  sleep 1
done

Real run:

$ ./graceful.sh &
[graceful] pid=9805 running, waiting for signal...
$ kill -TERM 9805
[graceful] caught SIGTERM, finishing in-flight work...
[graceful] cleanup complete, exiting 0
$ wait 9805; echo "exit status: $?"
exit status: 0

This was run exactly as shown. The trap cleanup SIGTERM line registers the function; the while true; do sleep 1; done loop is what lets the shell actually notice the signal between iterations rather than being stuck inside one long blocking call.

Trade-offs & pitfalls

• trap only fires while the shell is able to receive the signal between steps. A script blocked inside one long, non-interruptible external command may not react until that command returns, which is why real shutdown handling belongs in a loop the trap can interrupt (as shown), not behind a single blocking call with no way back to the trap.
• If the cleanup function itself hangs, you have traded an unclean kill for a hung shutdown; bound cleanup work with its own timeout.
• Init systems send SIGKILL automatically after a grace period regardless of whether your trap finished (a systemd unit's TimeoutStopSec, Docker's default 10-second SIGTERM-then-SIGKILL). The cleanup logic has to comfortably fit inside that window or the "graceful" part is lost anyway.
• Trapping only SIGTERM means a SIGINT during manual testing (Ctrl+C) skips your cleanup entirely. Trap on both if you want consistent behavior: trap cleanup SIGTERM SIGINT.

Direct answer

List available signals with kill -l, read their full semantics with man 7 signal (Linux) or man signal (BSD and macOS), and read the kill command's own syntax with man kill. Always try SIGTERM first and give the process a bounded grace period to shut down cleanly; escalate to SIGKILL only if it ignores SIGTERM and is still running after that window, since SIGKILL cannot be caught or ignored and skips any cleanup the process would otherwise perform.

Structured elaboration

Discovery commands:

kill -l      # list available signal names
man 7 signal  # Linux: full semantics of every signal
man kill      # semantics of the kill command, including -s/-SIGNAME syntax

• Why SIGTERM first: it is the "please shut down" signal. A well-behaved process can install a handler for it, finish in-flight requests, close file handles and database connections, and exit on its own terms.
• Why SIGKILL only as a last resort: the kernel terminates the process immediately. No handler runs, no cleanup happens, and anything the process would have flushed (temp files, half-written state, an open transaction) is simply abandoned.
• Decision criteria in production: send SIGTERM, wait a bounded grace period sized to the service (long enough to drain in-flight work, short enough not to stall an incident response), check whether the process actually exited, and only send SIGKILL if it is still alive after that window. This is exactly the escalation most process supervisors implement natively (systemd, Docker, Kubernetes all send SIGTERM, wait a configured grace period, then SIGKILL).

Worked example

$ kill -l
HUP INT QUIT ILL TRAP ABRT EMT FPE KILL BUS SEGV SYS PIPE ALRM TERM URG STOP TSTP CONT CHLD TTIN TTOU IO XCPU XFSZ VTALRM PROF WINCH INFO USR1 USR2

This was run on macOS (BSD). On a typical Linux distribution, kill -l instead prints a numbered list (1) SIGHUP 2) SIGINT ... 15) SIGTERM ...) and additionally shows the SIGRTMIN through SIGRTMAX real-time signal range that BSD does not have. The signal names and the SIGTERM-then-SIGKILL decision logic are identical on both; only the exact numbering and list differ.

Trade-offs & pitfalls

• Jumping straight to SIGKILL because it "just works faster" is the most common production mistake: it can corrupt in-progress writes and orphan child processes or open sockets that the OS then has to clean up on its own schedule.
• killall (or pkill) matches by process name across the whole host, not by the specific PID you intend to target. killall java on a shared host kills every JVM process it can see, including ones owned by an unrelated service. Confirm the exact target first with ps aux | grep <name> or pgrep -a <name>, and prefer signalling by PID (kill -TERM <pid>) once you have verified it is the right process. If you must match by name, scope it as tightly as the tool allows, for example pkill -f 'exact/path/to/binary --exact-flag'.
• Some processes ignore SIGTERM entirely, by design or by bug. That is the specific case SIGKILL exists for, not a default you reach for out of impatience.

Direct answer

Using Python with VS Code (Visual Studio Code, a free, extensible code editor) as the example stack, a productive setup covers four functional buckets: real language intelligence (autocomplete and navigation), an autoformatter, a linter, and a debug configuration wired to how the project actually runs, not a pile of unrelated extensions.

Structured elaboration

• Language intelligence: the Python extension (Microsoft) plus Pylance, which adds type-aware autocomplete, go-to-definition, and inline type checking based on the code's actual type hints.
• Formatting: an autoformatter, Black is the common default for Python, set to run on save so code style is never a manual chore or a pull-request debate.
• Linting: a fast linter such as Ruff (or flake8) that flags real issues, unused imports, undefined names, likely bugs, as you type rather than only at CI time.
• Debugging: a launch configuration (VS Code's launch.json) that mirrors how the application actually starts: correct environment variables, correct working directory, correct entry point. That is what makes "set a breakpoint and step through" work on day one instead of falling back to scattering print statements.
• Editor-level settings: format-on-save, "organize imports" on save, and a .editorconfig file checked into the repository so indentation and line-ending rules travel with the project instead of living only in each developer's personal preferences.

Worked example

This is an illustrative configuration sketch, not executed code with printed output.

// .vscode/settings.json
{
  "python.defaultInterpreterPath": "${workspaceFolder}/.venv/bin/python",
  "editor.formatOnSave": true,
  "editor.codeActionsOnSave": { "source.organizeImports": true }
}

// .vscode/launch.json
{
  "version": "0.2.0",
  "configurations": [
    {
      "name": "Run app",
      "type": "debugpy",
      "request": "launch",
      "program": "${workspaceFolder}/app.py",
      "envFile": "${workspaceFolder}/.env"
    }
  ]
}

Trade-offs & pitfalls

• Committing .vscode/settings.json at the project level, not just relying on personal editor tweaks, is what actually speeds up onboarding; an individual's private settings do nothing for the next hire.
• Over-configuring with dozens of extensions upfront creates its own friction, slower startup, conflicting formatters fighting over the same file. Start with the four essentials above and add only what a real, recurring pain point justifies.
• A debug configuration that does not match how the application actually runs in practice (wrong environment variables, wrong working directory) gives false confidence: "it launches in the debugger" is not the same as "it launches the way production does."

Direct answer

Build-time (or "dev") dependencies are tools needed to produce or test an artifact but not needed to run it in production, a compiler, a bundler, a test framework. Run-time dependencies are what the running application actually imports and needs present to execute. Keeping them separate lets you strip build-time tooling out of what actually ships.

Structured elaboration

Management guidance:

• App size: in npm and pip, build-time tools should never ship in a production artifact. A multi-stage Docker build, install everything including dev dependencies in a builder stage, then copy only the compiled output plus the run-time dependencies into the final image, enforces this more reliably than trusting npm prune --omit=dev alone.
• Vulnerability surface: a CVE (Common Vulnerabilities and Exposures entry) in a dev-only tool is real but lower urgency than one in a run-time dependency, since the dev-only tool never runs in the deployed artifact. Most vulnerability scanners let you filter by whether a dependency is dev-only for exactly this reason.
• Build instability: putting something the running app actually needs into a dev/build-only scope (or the reverse) causes exactly the class of bug that only shows up in production, "works on my machine" because the dev environment happens to have the tool installed, but the deployed artifact never included it.

Worked example

This is a conceptual walkthrough, not an executed transcript. A Node.js app imports lodash in its source code, so it belongs in dependencies, but also uses eslint only in CI to lint the code, so eslint belongs in devDependencies. If lodash were accidentally listed under devDependencies instead, a production install using npm ci --omit=dev would install everything except lodash, and the app would crash at startup the moment it hit its first require('lodash') call, a bug a developer's local environment (which has both dependency groups installed) would never surface.

Trade-offs & pitfalls

• The most common real bug here: a package genuinely needed at runtime gets added under the wrong scope, usually because whoever added it was mid-script or mid-test and was not thinking about the production build. It only surfaces when a stricter production install (npm ci --omit=dev, a Maven provided-scope mismatch) is actually exercised, often for the first time in CI or, worse, in production.
• Maven's provided scope assumes the container or runtime environment supplies that dependency; using it for something the runtime environment does not actually provide compiles fine locally and throws NoClassDefFoundError at runtime.
• pip's ecosystem is looser than npm's or Maven's about enforcing this distinction structurally. requirements.txt has no first-class dev-versus-runtime split the way package.json does; teams typically simulate it by convention with a separate requirements-dev.txt or, more recently, pyproject.toml optional dependency groups.