Version Control and Developer Tooling Questions

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.

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

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

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.