Git Quiz

Think of the staging area as a holding pen between your files and your commit history: git add moves changes there, and only what's actually in that holding pen is what git commit will save, which is why you can choose to commit some changes but not others.

git blame goes line by line through a file and tells you exactly which commit (and which author) last touched each one, which is exactly what you want when you're trying to figure out who wrote a weird line of code and why.

A submodule reference in the parent repo is a pinned commit SHA recorded as a special "gitlink" entry, not a live link to a branch, so moving the submodule's checked-out commit makes the parent repo's working tree differ from what it last committed. That difference is exactly what `git status` is flagging: an uncommitted pointer change waiting for you to `git add` the submodule path and commit it in the parent. Nothing here is a bug or a `.gitignore` problem; it's the normal, if surprising, mechanics of how submodule pointers work.

`git stash` saves your staged and unstaged modifications to a hidden stack and cleans your working directory back to HEAD's state, which is useful when you need to switch branches without committing half-finished work. You later bring the changes back with `git stash pop` or `git stash apply`. It's easy to confuse with `git reset --hard`, but reset discards changes entirely instead of saving them.

The moment you push, assume the key is already out in the wild, someone could have cloned or scraped it within seconds. Editing your commit history afterward doesn't undo that exposure, so the only thing that actually removes the risk is revoking or rotating the leaked credential itself, immediately.

A regular rebase always replays your commits onto the tip of whatever branch you're rebasing onto. --onto is more surgical: it lets you say 'take just this range of commits and replay them onto this completely different commit instead', which is handy when a branch needs to move to a new starting point that isn't its original parent.

A remote is just a nickname (usually 'origin') that Git uses to remember where another copy of your repository lives, typically on a server like GitHub, so commands like push and pull know where to send or fetch changes.

Interactive rebase opens up your recent commits as an editable list before replaying them, so instead of just moving them as-is, you can reorder them, squash several messy ones into a single clean commit, tweak a commit message, or drop a commit entirely.

`git bisect run` takes a script or command, checks out each bisection candidate automatically, runs it, and uses the exit code to decide the next step: 0 means good, any code from 1 to 124 means bad, and the special code 125 means "can't test this commit, skip it." This turns what would be manual back-and-forth into a single unattended command that finishes with the exact first-bad commit already identified.

The pre-commit hook runs right before Git finalizes a commit, letting a script inspect the staged content and abort the commit, by exiting non-zero, if something's wrong, such as a failing linter. A post-merge hook only fires after a merge has already completed, so it can't block anything, and an alias is just a shortcut for typing commands, not an enforcement mechanism.