Version Control and Developer Tooling Questions

Direct answer

git clone is a one-time operation that copies an entire remote repository (all branches and history) to create a new local repository. git fetch downloads new commits and branches from a remote into your local repo's remote-tracking branches (like origin/main) without touching any of your own local branches. git pull is git fetch followed by automatically integrating the fetched branch into your current local branch, by default via a merge, but configurable to rebase instead. git push uploads your local commits to update a branch on the remote.

Structured elaboration

fetch + merge vs. pull --rebase. Plain git pull (the default) fetches, then merges origin/main into your local main, creating a merge commit if the two have diverged. git pull --rebase fetches, then replays your local commits on top of the freshly-fetched remote branch instead, producing a linear history with no merge commit.

Use --rebase when you want a clean, linear history for commits nobody else has based work on yet, it reads better in git log later. Use a plain merge (or git fetch followed by an explicit git merge) when you want the history to honestly reflect that two lines of work happened concurrently, or, importantly, when the commits you're integrating have already been pushed and shared, since rebasing shared commits carries the same shared-history risk as any other rebase (see below).

Worked example

Two developers both start from the same origin/main. Developer A commits locally and pushes. Developer B, unaware, also commits locally, then runs git pull. Since origin/main now has A's commit that B's local main doesn't, git creates a merge commit joining both histories: git log --graph on B's machine shows a fork-and-join shape. If B had instead run git pull --rebase, git would have fetched A's commit, then replayed B's local commit on top of it, giving a single straight line with B's commit last, no merge commit at all, same end content, different history shape.

Trade-offs and pitfalls

For a collaborative team specifically: defaulting everyone to plain git pull means merge commits accumulate constantly on a busy shared branch, which clutters git log with noise that has no real informational value beyond "two people worked on this around the same time." Defaulting everyone to git pull --rebase is fine for commits that are still only local, but is dangerous the moment those commits have already been pushed and someone else has pulled them, rebasing rewrites their hashes, and a subsequent force-push causes the exact same shared-history problem as any other rebase of shared work: collaborators' next pull either duplicates commits or conflicts outright. The safest team-wide default is usually to pick one convention explicitly and configure it (git config pull.rebase true sets rebase as the repo-wide default) rather than leaving it to each developer's local git config, an inconsistent mix of merge-pullers and rebase-pullers produces a history that's neither clean nor honestly concurrent, just inconsistent.

Direct answer

Don't bypass the protections, compress the same process into a fast, prioritized path instead: branch off main, make the smallest fix that actually addresses the issue, get a real but expedited review, let CI run, merge normally once both pass, and communicate loudly before, during, and after so nobody duplicates the fix or gets surprised by it landing.

Structured elaboration

1. Branch from the right base. git checkout -b hotfix/checkout-500 main (or from the currently-deployed release tag if main has since moved ahead of what's actually in production).

2. Keep the diff minimal. Fix the specific issue only, no drive-by refactoring or cleanup bundled in. A smaller diff is faster to review genuinely well and carries lower regression risk, exactly what you want under time pressure.

3. Get a real review, just an expedited one. Open the PR immediately, mark it clearly (a [HOTFIX] prefix or a dedicated label), and directly page or ping the on-call reviewer rather than letting it sit in the normal queue. If the protected-branch rule requires human approval, get that approval synchronously, a quick screen-share or pairing session, rather than skipping it. The review step is exactly the safeguard you want to keep, not cut, when you're moving fast under pressure.

4. Let CI actually run. If the team has a pre-agreed, legitimately-scoped "critical-path-only" CI profile for genuine emergencies, use it. Don't disable required checks in the branch-protection settings themselves as a shortcut, that's a configuration change that typically needs its own approval and is easy to forget to revert afterward, leaving the branch under-protected long after the emergency has passed.

5. Merge and deploy through the normal path. Once approvals and checks pass, merge the same way any other change does, then deploy via the standard pipeline (or an expedited manual trigger, if one legitimately exists) rather than pushing directly to a server.

6. Communicate at every step. Post in the incident or on-call channel before starting ("working a hotfix for the checkout 500 error, branch is hotfix/checkout-500"), link the PR so it's visible, confirm once it's deployed, and follow up with a short retro note. Back-merge or cherry-pick the fix into any other active release or long-lived branches too, otherwise the bug quietly returns the next time one of those branches ships.

Worked example

An on-call engineer notices checkouts are failing with a 500 error. They branch hotfix/checkout-500 off main, isolate the fix to the one function causing the failure, open a PR tagged [HOTFIX], and page a teammate for immediate review over a quick call rather than waiting for the async review queue. CI runs the same required checks as any other PR. Once approved and green, the PR merges normally and deploys through the standard pipeline. The engineer posts a short update in the incident channel confirming the fix is live, then separately checks whether any active release branch also needs the same fix cherry-picked in.

Trade-offs and pitfalls

The temptation under real pressure is to grant yourself an admin override and push straight to main, "just this once." That erodes the protection for everyone going forward and sets a precedent that the rules are optional when things feel urgent, exactly when they matter most. In practice, an unreviewed hotfix has caused as many outages as the bug it was meant to fix, skipping review to save a few minutes is a bad trade against that risk. The most commonly missed step isn't the fix itself, it's forgetting to back-port it into other active branches (release branches, long-lived version branches), which means the same bug quietly resurfaces at the next release from one of those.

Direct answer

curl -s -o /dev/null -w '%{http_code} %{time_total}\n' -L https://example.com

Structured elaboration

Key points:

• -s: silent mode, suppresses the progress meter.
• -o /dev/null: discards the actual response body; only the status and timing matter here.
• -w '%{http_code} %{time_total}\n': the write-out format string, printed after the transfer finishes. %{http_code} is the final HTTP status code, %{time_total} is the total request time in seconds.
• -L: follow redirects, so %{http_code} reflects the FINAL response in the redirect chain, not an intermediate 301 or 302.

Worked example

$ curl -s -o /dev/null -w '%{http_code} %{time_total}\n' -L https://example.com
200 0.043313

This was run exactly as shown, a real network call. The exact time_total number is a live measurement, it will differ every run and on every network, so treat it as a live reading, not a constant. What stays constant is the shape of the output: a three-digit status code, a space, and a floating-point seconds value.

Trade-offs & pitfalls

• The dominant cost here is network latency and the TLS handshake, not curl itself, so there is nothing meaningful to say about curl's own "complexity" beyond one HTTP round trip.
• Without -L, a redirecting endpoint reports the redirect's OWN status code (for example 301), not the final destination's, a common source of confusion when someone expects to see 200.
• %{time_total} bundles DNS lookup, connect/TLS handshake, and the full transfer. To isolate one phase, curl exposes separate write-out variables in the same format string, for example %{time_namelookup}, %{time_connect}, and %{time_starttransfer}.
• On a connection that fails outright (DNS failure, connection refused), curl exits non-zero and %{http_code} prints 000. Check curl's own exit status ($?) rather than trusting http_code alone to detect that class of failure.

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

I would use two layers: a fast client-side pre-commit hook for immediate developer feedback, and an authoritative server-side check that actually blocks the push or merge, because a client-side hook alone is not a security boundary. A Git hook is just a script Git runs automatically at a point in its workflow (before a commit, before a push accepted by the server, and so on); anything that only runs on the developer's own machine can be skipped, so the enforcement that matters has to happen where the developer does not control the environment.

Structured elaboration

Client-side layer (fast feedback, not enforcement)

• Use the pre-commit framework (pre-commit.com): the repo carries a versioned .pre-commit-config.yaml, and each developer runs pre-commit install once to wire a real hook into their local .git/hooks/pre-commit.
• Plug in a secret-scanning tool as a hook: gitleaks or detect-secrets (from Yelp) both scan the staged diff for patterns (AWS-style keys, private key headers) and high-entropy strings (a long, random-looking sequence of characters is a decent proxy for "this looks like a real secret, not a word").
• Example config:

repos:
  - repo: https://github.com/gitleaks/gitleaks
    rev: v8.18.0
    hooks:
      - id: gitleaks

• Scope: scan only the staged diff, not the whole tree, so it stays fast (seconds, not minutes) and does not annoy developers on every commit.

Server-side layer (the real enforcement point)

• On a self-managed Git server (GitHub Enterprise Server, GitLab self-managed, Bitbucket Server), you can install a real pre-receive hook: a script the server runs on every incoming push, before any ref is updated, that can reject the push outright.
• On hosted SaaS (github.com, gitlab.com) you generally cannot install a custom pre-receive hook on an ordinary repo. The equivalent there is (a) a required, blocking CI check that runs the same scanner against the pushed commits before a merge is allowed, and (b) the platform's own secret-scanning push protection (GitHub Advanced Security's secret scanning, for example, intercepts the push server-side when it recognizes a known secret pattern).
• The point of the server-side layer is that it does not care whether the developer had the client hook installed, disabled it, or ran git commit --no-verify to skip it.

Handling false positives without training people to bypass the tool

• Maintain a baseline/allowlist file (detect-secrets calls this .secrets.baseline) for known-safe matches, like test fixtures that intentionally contain fake keys.
• Scope detectors to file types and paths most likely to hold secrets, and tune entropy thresholds so ordinary hashes, UUIDs, and encoded blobs stop tripping the scanner.
• Give a documented override path: a reviewer-approved bypass tied to a ticket, logged, rather than a silent skip, so an override is visible and rare instead of a habit.
• Track the false-positive rate as a metric. A noisy hook is worse than no hook, because it teaches developers to reflexively bypass anything red.

Worked example

A developer edits config.py and accidentally leaves a real value staged: AWS_SECRET_ACCESS_KEY = "AKIA..."). On git commit, the pre-commit hook's entropy and pattern rules flag the exact file and line, and the commit is aborted with a message pointing at it. If the developer bypasses that with git commit --no-verify (or never ran pre-commit install in the first place) and pushes, the server-side layer is the backstop: on a self-managed server the pre-receive hook rejects the push before the branch updates; on GitHub.com, the required CI job fails the pull request and push protection can block the push itself if it recognizes the secret's format. Either way, the secret never reaches a branch other reviewers can pull.

Trade-offs and pitfalls

Client-side hooks improve turnaround time but are fundamentally advisory, not authoritative, since they run in an environment the developer controls. Server-side checks are authoritative but add latency to CI. Detector aggressiveness is a real dial: too strict burns trust and gets bypassed, too loose lets real secrets through. Finally, catching a secret in a new commit does not undo exposure that already happened: if a real credential is found even after the fact, the fix is rotating the credential and, separately, purging it from history, not just relying on the hook going forward.