Advanced Git: Debugging, History Rewriting, and Submodules

1. What is a Git branch, physically speaking?

• A full copy of all project files stored separately

  This answer treats a branch like a folder copy — branch creation never duplicates files; only one ref file is written.

• A 41-byte text file in .git/refs/heads/ containing one commit SHA
• A separate network connection to a remote server

  This answer confuses a branch with a remote; branches are local refs in .git/refs/heads/, not network connections.

• A compressed archive of your working directory

  This answer treats a branch like a backup archive rather than a single-line pointer file.

2. Which statements about Detached HEAD state are true? (Select all that apply) (select all that apply)

• HEAD points directly to a commit hash instead of a branch name
• Any commit you make in detached HEAD is automatically saved to the nearest branch

  This answer assumes Git auto-anchors detached-HEAD commits to a branch — it doesn’t, which is the whole reason orphans happen.

• Commits made here are orphaned unless you anchor them with a branch before leaving
• .git/HEAD contains a 40-char SHA rather than a line like ref: refs/heads/main

3. Why can HEAD point to a branch name rather than a commit SHA?

• Branch names are shorter and easier to type

  This answer mistakes ergonomics for mechanism — the indirection exists so commits can update the branch ref without rewriting HEAD.

• Symbolic refs let git commit update the branch pointer and HEAD automatically stays current through indirection
• Git requires it for compatibility with GitHub

  This answer assumes a remote constraint drives a local design decision; symbolic refs predate any hosting service.

• It prevents you from committing on the wrong branch

  This answer treats indirection as a safety feature; it’s actually a mechanism for cheap commits, not a guard rail.

4. You want to inspect a commit from last week without risking any accidental edits. Which is the safest approach?

• git switch --detach <old-sha> — look around; return to main with git switch main
• git reset --hard <old-sha> — rewinds your current branch to that point

  This answer confuses inspection with rewinding — reset --hard mutates the current branch’s pointer, the opposite of read-only inspection.

• git checkout <old-sha> . — overwrite files in working directory

  This answer overwrites working-tree files without moving HEAD; not destructive to history but stomps your editor state.

• rm -rf .git && git clone <old-sha> — start fresh

  This answer is the “burning down the repo” antipattern — far more destructive than the read-only detached HEAD it replaces.

5. Put in order the steps to safely inspect an old commit and return to normal operation. (arrange in order)

1. git log --oneline main # find the old commit SHA
2. git switch --detach # enter detached HEAD at it
3. cat calculator.py # look around, read freely
4. git switch main # return; no changes made

• git reset --hard # DANGER: rewinds main
• git checkout . # DANGER: overwrites working dir
• git branch -f main # DANGER: moves branch pointer

1. You made three commits in detached HEAD state, then ran git switch main without creating a branch. A teammate asks if the commits are lost. What do you tell them?

• Yes, they are permanently gone — detached HEAD commits are deleted by git switch

  This answer assumes git switch deletes data — it only moves HEAD; the commit objects stay in .git/objects/ until git gc decides to prune them.

• They are currently orphaned but still in the object database; git reflog can find their SHA, and git branch rescue <sha> makes them reachable again
• Git automatically migrated them to the main branch when we switched

  This answer assumes Git auto-attaches detached commits to a branch on switch — it doesn’t, which is exactly why we need the rescue.

• They are stored in a hidden recovery folder we can copy from

  This answer invents a recovery folder that doesn’t exist; orphans live in the same .git/objects/ as every other commit.

2. In one sentence, why can git reflog show commits that git log --all cannot?

• git log --all walks only reachable commits from refs (branches, tags); an orphan is reachable from no ref. git reflog logs every HEAD position regardless of reachability, so it remembers SHAs even after all references to them are gone.
• git reflog is a newer, more powerful version of git log

  This answer treats reflog as “log v2” — they’re different tools answering different questions (graph traversal vs. HEAD-position diary).

• git log --all is broken by default

  This answer assumes a default tool is broken; both work correctly, they differ only in what they walk.

• git reflog reads from the remote server; git log only from local

  This answer confuses reflog with remote history; reflog is purely local, while log --all walks any ref including remote-tracking ones.

3. What does HEAD@{2} mean?

• The second commit on the current branch

  This answer confuses HEAD@{2} (a reflog position) with HEAD~2 (a parent walk along commit history).

• Where HEAD was two movements ago in the reflog — usable anywhere Git expects a commit ref
• The second parent of HEAD (like HEAD^2)

  This answer confuses HEAD@{2} with HEAD^2 — three similar-looking suffixes (~, ^, @{}) all mean different things.

• A tag named HEAD@{2}

  This answer treats @{n} as part of a name rather than reflog syntax.

4. Reflog is local only. Which of these destroys your reflog and the rescue path with it? (Select all that apply) (select all that apply)

• rm -rf .git (or deleting the whole clone directory)
• A fresh git clone of the same repo from the remote
• git push --force to a remote

  This answer confuses remote history with local reflog; force-pushing rewrites the remote branch but leaves your local .git/logs/ (and its rescue path) untouched.

• Default reflog expiry once the configured retention window passes without activity

5. Put these steps in the correct order to rescue an orphaned commit you just made in detached HEAD. (arrange in order)

1. git switch main # leave detached HEAD
2. git reflog # find the SHA of the orphaned commit
3. git branch rescued-work HEAD@{1} # anchor it with a branch
4. git log rescued-work --oneline # verify it is reachable again

• git log --all --oneline # would NOT show the orphan
• git checkout # needs the SHA you just lost
• git push origin rescued-work

6. [Revisit Step 3 — preview] In the next step you will see that commits are content-addressable and immutable. Given that, what does git branch rescue <orphan-sha> actually do to the commit object?

• It copies the commit into a new location

  This answer treats git branch as a copy operation; it only writes a 41-byte ref file — the commit object itself never moves.

• It does nothing to the commit object — it only writes a 41-byte file (.git/refs/heads/rescue) containing the SHA. The commit itself never moves; it just becomes reachable again via the new ref
• It rewrites the commit’s SHA so it becomes reachable

  This answer assumes Git mutates commits to make them reachable; SHAs are content-addressable and immutable, so any rewrite would be a different commit.

• It restores the commit from a backup

  This answer invents a backup mechanism; the commit was never deleted, only unreferenced.

1. You want the commit two before main. Which reference is correct?

• main^2

  This answer confuses ^2 (the second parent of a merge) with ~2 (two commits back along the first-parent chain).

• main~2
• main-2

  This answer invents a syntax — Git uses ~ and ^, never - for relative addressing.

• main..2

  This answer confuses .. (a range expression) with single-commit addressing.

2. What does git hash-object do?

• Uploads the file to GitHub

  This answer confuses a local plumbing command with a network operation; hash-object never touches a remote.

• Computes the SHA-1 Git would assign to the content — letting you prove that identical content always produces the same hash
• Encrypts the file with a cryptographic hash

  This answer confuses cryptographic hashing (one-way fingerprint) with encryption (reversible).

• Compresses the file for storage

  This answer confuses content hashing (identity) with compression (size reduction).

3. Which statements about Git objects are true? (Select all that apply) (select all that apply)

• A commit object stores a reference to a tree, not the files themselves
• A blob stores file content without the filename
• Trees map filenames to blob or sub-tree SHAs
• Git stores file differences (deltas) between commits, not full snapshots

  This answer confuses Git’s snapshot-based history model with its later pack-file storage layer; delta compression is a storage optimization, not the model.

4. [Revisit Step 1] You are in detached HEAD at a commit that is 4 back from main. Which command prints that SHA without copying it from git log?

• git rev-parse main~4
• git log main --limit 4

  This answer invents a flag — git log uses -n or --max-count, not --limit.

• git checkout main~4

  This answer moves HEAD instead of just printing the SHA; the prompt asked for the SHA without checkout.

• git show main~4

  This answer prints the full commit diff; git show is overkill when you only need the resolved SHA.

5. Why does git branch feature complete in milliseconds even on a 10-GB repo?

• Git compresses the whole working directory in parallel

  This answer assumes branch creation involves heavyweight work; it’s just a fwrite() of 41 bytes — no traversal, no compression.

• It just writes one 41-byte file (.git/refs/heads/feature) containing the current commit SHA — no files are copied
• Branches are stored on the remote server, not locally

  This answer confuses local branches with remote refs; local branch creation is purely local and offline-capable.

• Git skips adding the branch until you commit to it

  This answer assumes lazy initialization; the branch is created and ready immediately, no commit required.

6. [Revisit Steps 1-2] You enter detached HEAD at an old commit, make one exploratory commit, and switch away without creating a branch. In terms of Git objects, what happens to that commit?

• Git deletes the commit object immediately

  This answer assumes Git is eager about cleanup; objects survive until git gc decides to prune unreachable ones.

• The commit object still exists in .git/objects but is unreachable from any ref, so git gc will eventually prune it
• The commit is moved into the .git/orphans directory

  This answer invents a .git/orphans directory; orphans live in the same .git/objects/ as everything else.

• The commit is converted into a blob

  This answer assumes Git mutates the object type; commits stay commits, they just lose their refs.

7. Put in order the commands that prove Git is content-addressable (same bytes → same SHA, across unrelated repos). (arrange in order)

1. echo "hello world" | git hash-object --stdin # in your main repo
2. # note the 40-char SHA — call it SHA-A
3. cd /tmp && git init -q other && cd other # fresh unrelated repo
4. echo "hello world" | git hash-object --stdin # same bytes
5. # output is IDENTICAL — call it SHA-B; SHA-A == SHA-B

• git push origin main # sharing has nothing to do with hashing
• git config user.email alice # author metadata is in commits, not blobs
• git commit -m "hello" # commit SHA includes parent/time; not the demo

1. You are mid-edit on app.py when your lead asks for an urgent hotfix on main. You have NOT staged your changes yet. Which approach keeps your tree clean for the hotfix without losing your in-progress work?

• git restore app.py — discards the edits

  This answer destroys the in-progress work the question wants to preserve.

• git commit -m 'WIP' — commits the half-finished changes

  This answer pollutes shared history if pushed; the prompt asks to keep the tree clean without losing work.

• git stash — saves modifications to a temporary holding area and cleans the tree
• git reset --hard — resets everything so you can restart later

  This answer wipes the in-progress changes entirely — the opposite of preserving them.

2. What does git status report immediately after git stash?

• Your modified files appear staged and ready to commit

  This answer confuses stash with staging — stash moves changes to a private commit at refs/stash, not the index.

• Your modified files appear untracked — Git has forgotten about them

  This answer assumes Git forgets the changes; they’re safe in a stash commit, the working tree just matches HEAD.

• nothing to commit, working tree clean
• An error, because git status cannot be run after stashing

  This answer assumes stash breaks git status; status works fine after stashing.

3. Difference between git stash pop and git stash apply?

• pop restores AND removes the stash entry; apply restores but keeps the entry
• pop works only on the oldest entry; apply works on any entry

  This answer reverses the constraint; both verbs work on any entry, the difference is whether the entry is removed afterward.

• apply creates a new commit; pop does not

  This answer confuses applying a stash with creating a commit; neither pop nor apply produces a new commit.

• They are identical

  This answer ignores the actual difference (whether the entry survives or is dropped).

4. You ran git stash but your brand-new file feature.py (never git add-ed) is still there. Why?

• The file is too large to stash

  This answer invents a size restriction — stash has no size limit; the issue is tracked vs. untracked.

• By default, git stash only stores tracked file changes; untracked files need git stash -u
• git stash needs a message for untracked files; use git stash push -m

  This answer confuses message annotation with the inclusion of untracked files; -u is the relevant flag, not -m.

• Git ignores files starting with .

  This answer confuses .gitignore rules with stash’s tracked-files default; dot-files aren’t ignored by default.

5. [Evaluate] A teammate says: ‘I never use stash — I just commit with WIP and squash later.’ Best evaluation?

• WIP is strictly better — stashes can be accidentally dropped

  This answer ignores the cost of WIP commits polluting shared history if pushed.

• Equivalent — personal preference only

  This answer flattens a real distinction (private/local stash vs. potentially-pushed WIP commits) into mere preference.

• Both work; WIP pollutes shared history if pushed and requires disciplined squash, stash stays private/local. Mature teams have conventions for both
• WIP is wrong — Git rejects commits with that message

  This answer assumes Git rejects messages — it doesn’t; the practice is just discouraged, not blocked.

6. [Revisit Step 1] You stashed on main, then switched to a commit with git switch --detach HEAD~2 to inspect old code. What is the safe way to recover the stash?

• Run git stash pop here — stash works in any HEAD state

  This answer ignores the conflict-on-pop risk in detached HEAD where there’s no branch to anchor unresolved changes.

• Return to a named branch first (git switch main), then git stash pop — applying a stash in detached HEAD risks creating orphaned state if conflicts arise
• The stash is lost — it was tied to main

  This answer assumes stashes are tied to the branch where they were created; they aren’t — refs/stash is independent.

• Run git stash apply detached to redirect it

  This answer invents a syntax — git stash apply takes a stash ref, not a branch state name.

7. [Revisit Step 3] Where does Git physically store a stash entry?

• As a plain text file in .git/stash.txt

  This answer invents a stash.txt file; stash uses the regular Git object database, not a separate text store.

• As a single merge commit reachable via refs/stash (with HEAD and an index-state commit as its parents) — the same object model as any other commit
• In RAM only; restarting the shell loses it

  This answer assumes stash is volatile; it survives reboots because it’s a real commit anchored at refs/stash.

• In the remote repository

  This answer confuses local stash with remote sync; stash is local-only by design.

8. Put in order the complete “stash → hotfix → resume” workflow from Task 3 of this step. (arrange in order)

1. git stash # save WIP, clean working tree
2. git switch -c hotfix-xyz # dedicated branch for the hotfix
3. git commit -am "Hotfix: ..." # fix + commit on the hotfix branch
4. git switch main && git merge hotfix-xyz --no-edit
5. git branch -d hotfix-xyz # clean up the merged hotfix branch
6. git stash pop # restore your WIP on main

• git commit -m "WIP" # pollutes history if pushed
• git restore . # discards WIP permanently
• git stash drop # would throw away the WIP
• git push origin stash # you cannot push a stash

1. What does git cherry-pick <sha> do?

• Permanently moves the commit from its original branch to the current branch

  This answer assumes cherry-pick mutates the source branch; it’s a copy, not a move — the source commit is untouched.

• Computes the patch of that commit vs its parent and creates a new commit on the current branch applying the same patch
• Merges the entire branch containing that commit

  This answer confuses single-commit cherry-pick with whole-branch merge.

• Renames the commit on the current branch

  This answer treats cherry-pick as a metadata edit; it actually creates a new commit object with a new SHA.

2. You cherry-pick commit abc123 from experimental onto main. Afterwards, what is on experimental?

• abc123 has been removed from experimental

  This answer assumes cherry-pick removes the source commit; cherry-pick is purely additive and doesn’t touch the source.

• abc123 is still on experimental, unchanged — cherry-pick copies, not moves
• experimental now points to main

  This answer assumes branches got rewired; cherry-pick only adds to the current branch.

• experimental has been deleted

  This answer assumes cherry-pick is destructive on the source; it isn’t.

3. During a cherry-pick, Git reports a conflict. Which sequence correctly completes it?

• Delete the conflicted file and run git cherry-pick --continue

  This answer destroys the work instead of resolving the conflict.

• Resolve conflicts in the file, git add the file, then git cherry-pick --continue
• Run git cherry-pick --force to override the conflict

  This answer invents a flag; Git has no --force option for cherry-pick.

• Run git commit --amend to finalize the cherry-pick

  This answer breaks the cherry-pick flow — --amend rewrites the previous commit, not the cherry-pick in progress.

4. [Revisit Step 3] After a cherry-pick, the new commit has a different SHA from the source. Why?

• Cherry-pick mutates the patch content

  This answer assumes cherry-pick rewrites content; the patch is identical, only the parent differs.

• The new commit has a different parent, and a commit’s SHA hashes its tree + parent(s) + metadata — any change alters the SHA
• Git randomly regenerates SHAs for safety

  This answer assumes randomness; SHAs are deterministic hashes of (tree + parents + metadata).

• The new commit has no parent at all

  This answer assumes the new commit is parentless; it has the current HEAD as its parent.

5. Which scenario is a bad fit for cherry-pick?

• Backporting a single bugfix from main to a release branch

  This answer rejects cherry-pick’s canonical use case; one-commit backports are exactly what it’s for.

• Pulling one reviewed commit from a colleague’s branch while the rest is still in review

  This answer rejects cherry-pick’s other canonical use case (surgical extraction from a partial branch).

• Integrating all 50 commits of a long-running feature branch into main
• Applying the same emergency patch to three parallel maintenance branches

  This answer rejects another canonical use case; cherry-picking the same fix into multiple maintenance branches is standard practice.

6. [Revisit Step 4] Mid-cherry-pick, a conflict pauses Git. You realize you need to check something on another branch first. Which sequence safely preserves your conflict-resolution progress so far?

• git stash — stashes work across branches, including mid-cherry-pick state

  This answer assumes stash captures Git’s internal cherry-pick state (CHERRY_PICK_HEAD, conflicted index); it doesn’t.

• git cherry-pick --abort first to restore a clean state, then switch; re-do the cherry-pick when you return
• Just git switch other-branch — Git will remember the cherry-pick

  This answer assumes Git tolerates mid-cherry-pick switches; it doesn’t, the index is in an unmergeable state.

• git commit -m 'WIP conflict' --allow-empty to save the mid-state

  This answer corrupts the cherry-pick state by inserting a foreign commit into its in-progress flow.

7. Put in order the commands that resolve a conflicted cherry-pick end-to-end. (arrange in order)

1. git switch main # be on the target branch
2. git cherry-pick # CONFLICT reported
3. git status # see which files conflict
4. # edit the conflicted file: remove <<<<<<<, =======, >>>>>>> markers
5. git add # mark resolved
6. git cherry-pick --continue # finalize with original message

• git commit -m "resolve conflict" # breaks the cherry-pick flow
• git cherry-pick --force # not a real flag
• git merge --continue # wrong verb — not a merge
• git reset --hard # would abort + discard

1. What does git blame calculator.py show?

• A list of bugs that were found in calculator.py

  This answer treats git blame as static analysis; blame is purely about line provenance, not bug detection.

• For every line in the file: the SHA, author, and timestamp of the commit that last modified that line
• The remote collaborators who have access to the file

  This answer confuses authorship-of-lines with access-control of the file.

• The diff of the most recent commit that touched the file

  This answer confuses blame’s per-line view with git show’s per-commit view.

2. You need to know the commit message for line 42’s last modification. Which sequence gets you there fastest?

• git log calculator.py | grep 42

  This answer treats line numbers as a search string; git log doesn’t index by line number, only blame does.

• git blame -L 42,42 calculator.py to get the SHA, then git show <sha> for the message and diff
• git diff calculator.py to see what changed

  This answer shows uncommitted changes, not authorship of committed lines.

• git status calculator.py

  This answer reports working-tree state, not historical authorship.

3. A colleague recently ran black across the whole repository. Now git blame shows them as the author of every line. How do you see the real last-meaningful author?

• Revert the black commit

  This answer is needlessly destructive; -w and blame.ignoreRevsFile solve this without rewriting history.

• Use git blame -w to ignore whitespace-only changes, and/or configure blame.ignoreRevsFile to exclude the black commit SHA
• Git has no way to recover this information

  This answer assumes the reformatter has masked the data permanently; it hasn’t, blame just needs the right flags.

• Use git reflog to rewind blame

  This answer confuses reflog (HEAD-position diary) with blame’s commit-by-line attribution.

4. [Revisit Step 3] When git blame prints a SHA for a line, what kind of object does that SHA refer to?

• A blob object containing just that one line

  This answer confuses commit objects with blob objects; blame attributes to commits, not blobs.

• A tree object for the file’s containing directory

  This answer confuses commit objects with tree objects; blame’s SHAs are commit SHAs.

• A commit object — the last one that modified that line
• A stash entry

  This answer confuses commits with stash entries; blame doesn’t reference stashes.

5. When is git blame the wrong tool for finding a bug?

• When the bug is a missing line that was never added
• When you need to know who last modified a specific line

  This answer states blame’s core use case — the question asked when blame is the wrong tool.

• When you need the timestamp of a line

  This answer states another core blame use case; blame prints timestamps for every line.

• When you need the commit message behind a line

  This answer describes the standard blame → show chain; it’s blame’s strength, not its weakness.

6. [Analyze] Give a concrete bug where git blame would mislead you even though the culprit line IS in the file. Which of the following fits best?

• A one-character typo fixed by a teammate — blame shows the typo’s original commit, not the fix

  This answer assumes blame keeps showing the original typo; once fixed, blame attributes the line to the fixer.

• A logic bug in a line that was auto-reformatted by a CI script last week — plain blame points at the CI bot, not the author who introduced the logic bug
• A commit that was cherry-picked to main from experimental

  This answer assumes cherry-pick fools blame; the new commit has its own SHA but blame still attributes correctly.

• A commit that was merged via a merge commit

  This answer assumes merge commits mask authorship; standard merges leave per-line history intact.

7. [Revisit Step 4] Your working tree has an uncommitted edit to calculator.py. You run plain git blame calculator.py. What do you see for the modified line?

• Nothing — Git refuses to run blame on a dirty file

  This answer assumes Git refuses dirty trees; blame works fine, it just shows the uncommitted line specially.

• The line appears with a zero SHA labeled “Not Committed Yet” — default blame annotates the working-tree copy of the file, including uncommitted lines
• The line appears with the SHA of the last commit that touched the file — uncommitted edits are invisible to blame

  This answer assumes blame ignores the working tree; default blame uses the working-tree copy, only blame HEAD -- restricts to committed lines.

• An error about a detached working tree

  This answer invents an error condition; “detached” applies to HEAD, not to working trees.

8. Put in order the “forensic chain” for understanding why a specific line in parser.py exists. (arrange in order)

1. git blame -L 42,42 parser.py # find SHA of last change to line 42
2. # copy the SHA from the first column
3. git show # read commit message + full diff
4. # is the commit message a reformatter? If yes, try -w:
5. git blame -w -L 42,42 parser.py # ignore whitespace-only commits

• git log parser.py | grep 42 # slow, imprecise
• git diff HEAD parser.py # shows YOUR uncommitted edits, not authorship
• git status parser.py # unrelated to authorship

1. A regression appeared somewhere in the last 50 commits. Roughly how many tests does git bisect need to find the exact breaking commit?

• 50 — one per commit

  This answer assumes linear search; bisect halves candidates each step (log₂(50) ≈ 6, not 50).

• 25 — approximately half

  This answer halves only once; bisect halves repeatedly until one commit remains.

• ~6 — log₂(50) ≈ 6
• 1 — bisect inspects all commits at once

  This answer assumes a single oracle; bisect needs one test per midpoint to drive the search.

2. Which sequence correctly runs an automated bisect?

• git bisect start; git bisect run <cmd>

  This answer skips the boundary-marking step; without bad/good markers, bisect can’t binary-search.

• git bisect start; git bisect bad; git bisect good <old-sha>; git bisect run <cmd>
• git bisect run <cmd> HEAD HEAD~50

  This answer puts boundaries in the wrong place; start takes them, run takes a command.

• git bisect <cmd>

  This answer omits both start and run; bisect needs both for automation.

3. You ran git bisect run successfully. What must you do afterwards?

• Nothing — bisect cleans itself up

  This answer assumes auto-cleanup; HEAD stays at the last midpoint until you bisect reset.

• git bisect reset — otherwise HEAD stays on the midpoint commit it last checked out
• git stash to preserve bisect state

  This answer confuses stash (working-tree shelving) with bisect cleanup.

• Push the result to the remote

  This answer assumes the bisect result needs to be shared via push; the result is local diagnostic info.

4. Which test property is required for git bisect run to work?

• The test must produce JSON output

  This answer invents an output-format requirement; bisect cares about exit codes, not output format.

• The test must exit 0 on pass and non-zero on fail, and must run on every commit in the range
• The test must be written in Python

  This answer invents a language requirement; bisect runs any executable.

• The test must only exist in the latest commit

  This answer is backwards; the test must work at every commit in the range, not just the latest.

5. [Revisit Step 1] In the middle of a manual bisect, Git leaves HEAD at a historical commit while you decide good/bad. What HEAD state are you in, and why is that OK?

• Detached HEAD — and it is safe because bisect manages it; git bisect reset restores you to the starting branch afterwards
• Attached to a new branch called bisect/working that Git creates automatically

  This answer invents a bisect/working branch; bisect uses internal refs (refs/bisect/*), not a magic branch.

• Detached HEAD — and any git commit you make here will corrupt history

  This answer assumes detached-HEAD commits are dangerous; bisect’s transient state is safe and reset undoes it.

• Attached to main — bisect only moves the working tree, not HEAD

  This answer assumes HEAD doesn’t move; bisect explicitly checks out historical commits at each midpoint.

6. [Revisit Step 6] A bug appears because a line that used to exist was deleted. Which tool finds the deletion commit?

• git blame — it shows every line’s author

  This answer ignores blame’s deletion blind spot; absent lines are invisible to blame regardless of mode.

• git bisect — it binary-searches the history for the commit where behavior changed, regardless of whether the change was an addition or deletion
• git log --grep='delete' — it finds commits with ‘delete’ in the message

  This answer assumes the commit message contains “delete”; commit messages don’t reliably announce deletions.

• git cherry-pick --find-deletion

  This answer invents a flag that doesn’t exist on cherry-pick.

7. Put in order the commands for an automated bisect that finds a regression in the last 100 commits and returns HEAD to normal. (arrange in order)

1. python3 test_calculator.py # verify HEAD currently fails
2. git bisect start HEAD HEAD~100 # bad=HEAD, good=100 back
3. git bisect run python3 test_calculator.py # Git iterates ~7 times
4. # Git prints: " is the first bad commit"
5. git bisect reset # return HEAD to pre-bisect state

• git bisect stop # not a real subcommand
• git bisect --force # not a real flag
• git reflog # unrelated to bisect workflow
• git bisect run -- python3 test.py HEAD HEAD~100 # wrong arg order

1. What does git rebase main do when run on feature-sqrt?

• Moves main to point at the tip of feature-sqrt

  This answer reverses the direction; running rebase main on feature-sqrt rebases feature-sqrt, not main.

• Computes the patches of commits unique to feature-sqrt, resets feature-sqrt to the tip of main, and replays those patches as new commits
• Merges main into feature-sqrt with a merge commit

  This answer confuses rebase with merge; rebase is the linearizing alternative, no merge commit involved.

• Deletes main and renames feature-sqrt to main

  This answer assumes destructive renaming; rebase moves the current branch’s commits, never deletes other branches.

2. After rebasing, why does the rebased commit have a different SHA than before?

• Git chooses a new SHA for clarity

  This answer treats SHAs as cosmetic choices; they’re deterministic content hashes, not chosen for clarity.

• The new commit has a different parent (the tip of main, not the previous branch point), and a commit’s SHA hashes its parent(s) + tree + metadata
• Rebase encrypts the commit

  This answer confuses content hashing with encryption.

• Rebase changes the commit message

  This answer assumes rebase rewrites text; the message is preserved, only the parent (and thus the SHA) changes.

3. When is git rebase a bad idea?

• On a personal feature branch that only you have checked out

  This answer rejects rebase’s canonical safe use case (private feature branch).

• On a short-lived local branch before opening a PR

  This answer rejects another canonical safe use case (short-lived local branch before PR).

• On a public/shared branch that teammates have already pulled
• To linearize history before a fast-forward merge

  This answer rejects rebase’s exact intended workflow (linearize then ff-merge).

4. [Revisit Step 2] You rebased feature-sqrt and realized it broke everything. Before pushing. How do you recover the pre-rebase state?

• It is gone — rebase is permanent

  This answer ignores reflog’s safety net; rebase only abandons refs, the old commits are still in .git/objects/.

• git reflog to find the pre-rebase SHA, then git reset --hard <sha> to restore feature-sqrt
• git stash pop to retrieve the old commits

  This answer confuses stash (working-tree shelving) with reflog (HEAD-position history).

• git clone a fresh copy of the repo

  This answer is the “burning down the repo” antipattern when reflog can rescue locally.

5. After rebasing a feature onto main, you run git merge feature on main. What happens?

• A merge commit with two parents is created

  This answer ignores that rebase made feature a strict extension of main, so merge fast-forwards instead of creating a merge commit.

• A fast-forward occurs — main simply moves to point at the feature tip; no merge commit, no diamond in the graph
• The rebase is reversed

  This answer assumes merge undoes rebase; they compose, they don’t reverse.

• Git reports an error

  This answer assumes Git rejects this; it’s actually the canonical “rebase + ff merge” workflow.

6. Which statements about rebase are true? (Select all that apply) (select all that apply)

• Rebase creates new commits with new SHAs for each replayed commit
• Rebase can cause conflicts at each replayed commit, requiring you to resolve one at a time with git rebase --continue
• Rebase automatically pushes the updated branch

  This answer confuses local rewriting with publication; push is always a separate step from rebase.

• Rebase can be aborted with git rebase --abort, restoring the branch to its pre-rebase state

7. [Revisit Step 5] You had two choices for bringing a colleague’s single fix into main: cherry-pick or rebase. Both create new commits with new SHAs. What is the key difference in intent?

• Cherry-pick copies one commit onto HEAD; rebase moves all of a branch’s unique commits onto a new base — they differ in scope, not mechanism
• Cherry-pick is destructive; rebase is not

  This answer assumes cherry-pick mutates the source; it’s purely additive, just like rebase’s commit creation.

• Cherry-pick requires the commit to be on a branch; rebase does not

  This answer invents a constraint; cherry-pick takes any commit-ish, branch or not.

• They are identical aliases

  This answer ignores the scope difference (one commit vs. a series).

8. [Revisit Step 3] During rebase, a conflict halts you mid-stream. git reflog at this moment shows many entries. Which entry do you want to git reset --hard to if you decide to abort manually instead of using git rebase --abort?

• The most recent HEAD@{0} entry

  This answer points at the current (post-rebase) state; you want the entry from before the rebase.

• The checkout: moving from ... entry that shows where the branch pointed before rebase started
• The very oldest reflog entry

  This answer ignores the relevant time range; the pre-rebase entry is recent, not the oldest.

• Any entry — they all point to the same commit

  This answer ignores that reflog entries each refer to a different historical HEAD position.

9. [Revisit basic tutorial Step 11] You edit a conflicted file during a git rebase, remove the <<<<<<< / ======= / >>>>>>> markers, and run git add. What is the next command to finalize this one commit of the rebase?

• git commit — same as finishing a merge

  This answer treats a rebase conflict like a merge conflict’s final step; rebase needs --continue, not commit.

• git rebase --continue — during a rebase, Git is replaying commits one at a time, so continuation (not a fresh commit) is how you resume
• git merge --continue

  This answer uses the wrong verb; this is a rebase, not a merge.

• git push

  This answer skips finalizing the rebase entirely.

10. Put in order the commands to rebase a private 3-commit feature branch onto the latest main and fast-forward merge, with nothing leftover on disk. (arrange in order)

1. git switch feature # be on the branch being rebased
2. git rebase main # replay feature commits onto latest main
3. git switch main # target the integration branch
4. git merge feature # fast-forward, no merge commit
5. git branch -d feature # clean up the now-merged branch

• git push --force # DANGER on shared branches
• git merge feature --no-ff # would create a merge commit — not ff
• git rebase feature # backwards — rebases main onto feature
• git reset --hard feature # destroys main's history

1. Which interactive-rebase action keeps the commit but lets you change only its message?

• pick

  This answer doesn’t change anything; pick is a no-op that uses the commit as-is.

• reword
• squash

  This answer melds two commits; the question asks for a message-only edit on one commit.

• drop

  This answer deletes the commit instead of editing it.

2. What is the difference between squash and fixup?

• squash combines messages (editor opens); fixup silently discards the squashed commit’s message
• squash rewrites hash; fixup preserves it

  This answer confuses ‘rewrites the SHA’ (both do, all rebase verbs do) with the actual difference (message handling).

• fixup can only be used on merge commits

  This answer invents a constraint; fixup works on any commit, not just merges.

• They are identical

  This answer ignores the actual difference (whether the editor opens for the squashed message).

3. You just ran git rebase -i HEAD~3 and realized you dropped a commit you needed. Can you recover it?

• No — dropped commits are permanently deleted

  This answer ignores reflog’s safety net; the dropped commit is unreferenced, not deleted.

• Yes — git reflog still shows the pre-rebase HEAD; git reset --hard HEAD@{1} restores everything
• Only by running git rebase --undo

  This answer invents a subcommand; git rebase has no --undo.

• Only if you had pushed the commit

  This answer reverses the rule; pushing makes recovery harder, not easier (because teammates also have the old SHAs to reconcile).

4. [Revisit Step 3] After an interactive rebase, the rewritten commits have new SHAs even if their patches are identical. Why?

• Interactive rebase randomly generates SHAs

  This answer assumes randomness; SHAs are deterministic content + parent hashes.

• A commit’s SHA hashes its tree + parents + metadata; rebase changes the parent, so the SHA changes
• Interactive rebase encrypts commits

  This answer confuses hashing with encryption.

• Git renames the commits for clarity

  This answer treats SHAs as cosmetic; they’re determined by content + parents, not chosen for clarity.

5. Which of these is the most dangerous use of interactive rebase?

• On a local branch to squash WIP commits before opening a PR

  This answer rejects interactive rebase’s canonical safe use case (local WIP cleanup before PR).

• On a local branch to drop a commit that accidentally included a secret

  This answer flags a safe-zone use; rewriting unpushed history is the right context for drop.

• On main of a shared repository used by 10 teammates, to drop a week-old commit
• On a personal experiment branch that nobody else has cloned

  This answer flags another safe-zone use; nobody else holds the old SHAs on a personal experiment branch.

6. You want to split one giant commit into three smaller ones during interactive rebase. Which action lets you do that?

• pick

  This answer keeps the commit as-is; splitting requires pausing and recomposing.

• squash

  This answer merges commits; splitting goes the other direction.

• edit — pauses at the commit so you can git reset HEAD~, stage smaller pieces, and commit each separately
• reword

  This answer changes the message; splitting changes the commit count.

7. [Revisit Step 2] In Task 3b you ‘rescued’ a dropped commit. In terms of the object database, what did git branch secret-backup <sha> actually do?

• It copied the dropped commit from .git/trash back into .git/objects

  This answer invents a .git/trash directory; Git has none — nothing was ever moved out of .git/objects/.

• It wrote a 41-byte file at .git/refs/heads/secret-backup containing the SHA, making the commit reachable again — the commit object itself never moved
• It recreated the commit from the reflog’s textual record

  This answer assumes reflog reconstructs commits from text; the commits were never gone, only unreachable.

• It undid the rebase

  This answer assumes branch creation is a global undo; it only adds one ref (no rebase reversal).

8. [Revisit Step 5] You are about to interactive-rebase a branch. You have uncommitted edits you want to keep but not carry through the rebase. Safest workflow?

• Commit them as WIP then rebase — they will survive

  This answer pollutes history; the question explicitly says “keep but not carry through” — WIP commits get carried through.

• git stash them (Step 4) → rebase → git stash pop when done → same pre-rebase work, cleanly on the rebased branch
• Run rebase with --ignore-uncommitted

  This answer invents a flag; rebase has no --ignore-uncommitted option.

• Git rebase will refuse to start if you have uncommitted changes, so nothing to worry about

  This answer is half-true (rebase does refuse) but doesn’t address how to handle the uncommitted work the question wants preserved.

9. Put in order the steps to squash 4 messy commits on a local branch into one clean commit (assuming you’re using the scripted VM editor). (arrange in order)

1. git log --oneline -5 # inspect what we're rewriting
2. GIT_SEQUENCE_EDITOR="sed -i '2,4s/^pick/squash/'" git rebase -i HEAD~4
3. # Git replays commit 1 as pick, squashes commits 2-4 into it
4. git commit --amend -m "Refactor: cleanup notes in calculator.py"
5. git log --oneline -3 # verify: 4 commits became 1

• git push --force # DANGER: never on shared history
• git rebase -i HEAD~4 --squash-all # not a real flag
• git reset --hard HEAD~4 # destroys commits without combining
• git merge --squash HEAD~4 # wrong tool for intra-branch squash

1. What does git merge --squash feature do?

• Creates a merge commit with two parents and the feature’s history intact

  This answer confuses regular merge with squash-merge; squash deliberately avoids the second parent.

• Stages the cumulative diff of the feature branch on main without committing, so you can create one combined commit
• Deletes the feature branch

  This answer assumes squash-merge cleans up the source; the feature branch is untouched.

• Rebases the feature onto main

  This answer confuses squash (one combined commit) with rebase (replays each commit).

2. After git merge --squash feature; git commit, what is true of the feature branch?

• It no longer exists — squash deleted it

  This answer assumes squash deletes the source branch; squash leaves it intact.

• It still exists, unchanged; its commits are not on main (only a new combined commit is)
• It points at the new squash commit on main

  This answer assumes branches got rewired; squash only adds a commit to the current branch.

• Its commits have been rewritten

  This answer assumes squash modifies the feature’s history; only the current branch gets a new commit.

3. [Compare with Step 8] You have a 3-commit feature. You merge it three ways. Which output is correct?

• plain merge → 1 new commit on main; rebase + merge → 3 new commits on main; --squash + commit → 3 new commits on main

  This answer gets squash backwards (squash produces 1 commit, not 3) and confuses plain merge’s parent count.

• plain merge → 1 merge commit (3 parents); rebase + merge → 3 new commits; --squash + commit → 1 new commit

  This answer invents a 3-parent merge commit; standard merges have exactly 2 parents.

• plain merge → 1 merge commit with 2 parents; rebase + merge → 3 replayed commits on main (linear, ff); --squash + commit → 1 new commit on main
• All three approaches produce identical history

  This answer ignores the actual differences between strategies — they produce visibly different histories.

4. Why might a team reject squash merge as a default policy?

• It forces a merge commit which they dislike

  This answer is backwards; squash avoids merge commits.

• Losing individual commit granularity hurts git bisect precision within a feature and erases authorship signal on intermediate commits
• Git rejects squash merges on main

  This answer invents a Git restriction; squash works on any branch.

• It requires a paid GitHub subscription

  This answer confuses Git mechanics with hosting service pricing.

5. You squash-merged feature-stats into main. The next day you discover one of the three internal commits had a bug. How do you fix only that part?

• Git tracks internal commits automatically — run git revert --internal <sha>

  This answer invents a flag; revert has no --internal, and Git doesn’t track squash-internal commits on main.

• You cannot isolate it from main alone. The original commits still exist on the feature branch (or in reflog) — cherry-pick, revert, or rewrite from there
• Use git bisect run to revert automatically

  This answer combines two unrelated tools; bisect doesn’t auto-fix or auto-revert.

• Delete main and re-merge with git merge --no-squash

  This answer ignores that the squashed commit is already on main; you can’t unmerge a commit.

6. [Revisit Step 7] A regression is reported on main three months after a feature was squash-merged in. git bisect on main narrows the culprit to the squash commit. What is your next move?

• Declare the feature author guilty and revert the whole squash commit

  This answer is too broad; the question asks for fine-grained resolution, not whole-feature reversion.

• Switch to the (still-existing) feature branch and run git bisect there — its internal commits give you the fine-grained resolution squash destroyed on main
• Bisect is unreliable after squash — read every line of the squash commit’s diff

  This answer ignores the available finer-grained source on the feature branch.

• Re-run bisect with --squash-aware

  This answer invents a bisect flag; bisect operates on commits, and the feature branch already has the granularity.

7. [Revisit Step 3] After git merge --squash feature; git commit, the new squash commit on main is a Git commit object like any other. What are its parents?

• Two parents: the tip of main and the tip of feature (like a merge commit)

  This answer treats squash as a merge; squash deliberately gives only one parent (the prior HEAD), not two.

• Three parents: main, feature, and their common ancestor

  This answer invents a three-parent commit type; standard merges are 2-parent and squash is 1-parent.

• One parent: the tip of main (before the squash). The feature branch tip is NOT a parent — that is what makes it a squash rather than a merge
• Zero parents — squash commits are parentless root commits

  This answer treats squash as a root commit; it has the prior HEAD as parent.

8. Put in order the commands to squash-merge a 3-commit feature-stats branch into main, then clean up. (arrange in order)

1. git switch main # target branch
2. git merge --squash feature-stats # stages combined diff; NO commit yet
3. git status # verify: staged changes, no commit
4. git commit -m "Add statistics module (mean, variance, stddev)"
5. git branch -D feature-stats # force-delete (not ff-merged in Git's view)

• git merge feature-stats # creates a merge commit — wrong strategy
• git branch -d feature-stats # refuses: the branch's commits aren't on main
• git cherry-pick feature-stats # only copies the tip commit, not combined
• git push --force # unneeded and dangerous

1. Why is git revert safe on shared branches where git reset --hard + push --force is not?

• Revert doesn’t actually change anything

  This answer is too strong; revert does change history (adds a new commit), it just doesn’t rewrite existing SHAs.

• Revert is additive — it appends a new anti-matter commit. Existing SHAs are unchanged, so teammates’ clones stay consistent. Reset + force-push rewrites history, forcing every collaborator to reconcile.
• Revert is encrypted

  This answer invents encryption; revert is plain commit semantics.

• GitHub blocks force-push by default

  This answer relies on remote-side enforcement; the safety property is intrinsic to revert vs. reset, not a platform policy.

2. What does git revert <sha> physically add to history?

• Nothing — it just hides the commit

  This answer treats revert as visibility-only; revert adds a real commit that changes the working tree.

• A new commit on the current branch whose patch reverses <sha>’s patch (every + becomes - and vice versa). The revert’s parent is the prior HEAD — not necessarily <sha>, since you can revert any historical commit.
• A deletion marker

  This answer invents a “tombstone” object type; Git has none — revert is a regular commit.

• A tag named revert/<sha>

  This answer confuses commits with tags; revert produces a commit on the branch, not a tag ref.

3. You accidentally pushed a bad commit to main. Three teammates have pulled. Best move?

• git reset --hard HEAD~1 + git push --force (or --force-with-lease)

  This answer rewrites shared history; teammates with the old SHAs will see divergence and their pulls will fail.

• git revert HEAD + git push
• git rebase -i HEAD~1 with drop, then force-push

  This answer also rewrites shared history (rebase-drop is a rewrite); same breakage as reset + force.

• Delete the whole repository and re-clone

  This answer is the “burning down the repo” antipattern — needlessly destructive.

4. [Revisit Step 9] Rebase-drop and revert both “undo” a commit. Which is correct about their effect on SHAs?

• Both create new SHAs for all later commits

  This answer ignores that revert leaves all existing commits’ SHAs unchanged; only one new commit is added.

• rebase-drop rewrites every subsequent commit’s SHA. revert appends one new commit and changes nothing existing.
• Both are non-destructive

  This answer ignores rebase-drop’s rewriting of every subsequent commit’s SHA.

• Revert rewrites SHAs; rebase-drop doesn’t

  This answer reverses the additive/destructive distinction — revert is the additive one.

5. You want to revert a merge commit (one with two parents). What additional flag do you need?

• --merge

  This answer invents a flag; revert has no --merge option.

• -m 1 or -m 2 to tell Git which parent is the mainline
• --force

  This answer invents a flag; revert has no --force option.

• None — it just works

  This answer ignores that merge commits have two parents and revert needs to know which side is mainline.

6. Put in order the safe public-undo workflow after discovering a bad commit on shared main. Distractors rewrite history. (arrange in order)

1. git log --oneline -5 # find the bad SHA
2. git revert --no-edit # create the anti-matter commit
3. git log --oneline -3 # verify: both bad + revert are there
4. git push # succeeds — no history rewrite

• git reset --hard ^ # rewrites main, breaks teammates
• git push --force-with-lease # overwrites remote
• git rebase -i ^ drop # rewrites downstream commits
• rm -rf .git && git clone # "burning down the repo" antipattern

1. What does a Git submodule actually store in the outer repository?

• A full copy of the submodule’s files tracked like normal files

  This answer confuses submodule working tree content with outer-repo gitlink state; the outer repo only stores a SHA + URL, never the files.

• A gitlink — a 40-character commit SHA pinning which commit of the submodule’s repo should be checked out at that path, plus a .gitmodules entry with the URL
• Nothing — submodules are purely a runtime concept

  This answer assumes submodules are runtime-only; the outer repo records the gitlink and .gitmodules persistently.

• A symbolic link to the submodule’s directory

  This answer confuses a gitlink (mode 160000) with a filesystem symlink — the gitlink is a tree entry, not a symlink.

2. A teammate clones your repo normally with git clone <url>. What do they see at the submodule path?

• The submodule’s full contents, checked out automatically

  This answer assumes plain git clone fetches submodules; it doesn’t, by default — only --recursive (or a follow-up submodule update) populates them.

• An empty folder — they need git submodule update --init --recursive (or originally clone with --recursive) to populate it
• An error preventing the clone from finishing

  This answer assumes the clone fails; plain clone succeeds, the submodule folder is just empty.

• A warning but the content downloads lazily on first access

  This answer invents lazy fetching; submodule content fetches require explicit submodule update.

3. Which statements about submodules are true? (Select all that apply) (select all that apply)

• A submodule is a full Git repository nested inside another
• git clone --recursive <url> clones both outer and submodules
• The outer repo stores full copies of the submodule’s files

  This answer confuses submodule working tree content with outer-repo gitlink state; the outer repo only stores the SHA pin, not file copies.

• The outer repo tracks a submodule with a special gitlink entry (mode 160000) containing the pinned commit SHA

4. [Synthesis — revisits Steps 1, 3] Why is it internally consistent that a submodule is ‘just a pinned commit SHA’?

• Because every Git object is ultimately addressed by a SHA (blobs, trees, commits), the outer repo only needs to point at the submodule’s commit SHA to uniquely identify its entire snapshot — no file duplication needed
• Because submodules cannot have their own branches

  This answer is irrelevant — submodules can have branches; the question is about content addressing.

• Because submodules are always read-only

  This answer invents a constraint; submodules can be edited and committed to like any nested repo.

• Because Git stores submodules separately in a proprietary database

  This answer invents a separate database; submodules use the same Git object format as everything else.

5. [Revisit Step 8] A submodule’s pinned SHA is 40 characters, just like a regular commit SHA. In terms of Git objects, what kind of object does it point to?

• A blob object

  This answer confuses commit objects with blob objects; gitlinks pin commits, which then resolve to trees and blobs.

• A tree object

  This answer confuses commit objects with tree objects; only a commit captures parents, author, and message.

• A commit object — in the submodule’s separate repository’s object database
• A tag object

  This answer confuses commit objects with tag objects; tags reference commits, they aren’t stored in gitlinks.

6. Put in order the commands a teammate runs to add a submodule, commit it, and set up a colleague’s workstation so the submodule files appear. Distractors are verb-variants that look right but fail. (arrange in order)

1. cd /tutorial/myproject
2. git submodule add /tutorial/math-utils.git vendor/math-utils
3. git commit -m "Add math-utils submodule at v0.1.0"
4. cd /tutorial && git clone --recursive myproject colleague-clone

• git submodule init /tutorial/math-utils.git vendor/math-utils # init alone does not fetch
• git clone myproject colleague-clone # submodule folder empty
• git submodule fetch /tutorial/math-utils.git # not a valid subcommand
• git merge /tutorial/math-utils.git # confuses a nested repo with a branch

1. You bumped a submodule to v0.2 and pushed. A teammate pulls your change and reports tests failing because quadruple does not exist. Most likely cause?

• The submodule’s remote is down

  This answer blames infrastructure; the submodule’s pinned SHA is fine, the working tree just needs submodule update.

• They forgot git submodule update --init --recursive after pulling — their submodule working directory still has v0.1 while main’s code expects v0.2
• Their Git is too old

  This answer blames version; standard pull semantics have always required explicit submodule sync.

• The .gitmodules file is corrupt

  This answer assumes file corruption; the symptom is normal post-pull behavior, not corruption.

2. Upgrading a submodule requires how many git commit calls in total (inside + outside)?

• Zero — git submodule update commits for you

  This answer assumes submodule update commits for you; it only resets working state, never commits.

• One — only in the outer repo

  This answer omits the inner-commit case (when you’re authoring upstream changes yourself before bumping the pin).

• Two — if the submodule itself needed new commits (e.g., you wrote a patch inside it), commit there first; then the outer repo commit bumps the SHA. If the new upstream commit already exists, only the outer commit is needed.
• Three — submodule, .gitmodules, and outer tree

  This answer adds a .gitmodules commit; that file changes only when adding/removing a submodule, not when updating one.

3. git status in the outer repo shows modified: vendor/math-utils (new commits). What does it mean?

• The .gitmodules file has been edited

  This answer confuses submodule SHA changes with .gitmodules config edits.

• The submodule’s checked-out HEAD differs from the pinned SHA — either you updated the submodule, or it drifted
• The submodule is broken

  This answer assumes corruption; new commits is normal divergence between pinned and actual HEAD.

• Git is about to garbage-collect the submodule

  This answer invents a GC warning; git status doesn’t report on gc operations.

4. [Revisit Step 1] Why doesn’t git pull automatically update submodule working directories — what Git principle is respected by this design?

• Pull is inherently broken for submodules

  This answer assumes a tool defect; the design is intentional separation between outer and inner repos.

• Submodules are independent Git repos; respecting the outer/inner separation means outer operations don’t silently modify the inner repo’s HEAD. Same separation-of-concerns as detached HEAD (Step 1) — Git is conservative about moving HEAD without explicit instruction
• Pull is always read-only

  This answer is wrong on its face — pull writes to local refs and the working tree.

• It would violate the SHA-1 collision resistance guarantee

  This answer invents a cryptographic justification; the design is about repo-boundary respect, not hash collisions.

5. [Revisit Step 3] The outer repo’s diff for a submodule change is always just one line: -Subproject commit <old> / +Subproject commit <new>. Why is that enough?

• Git is being lazy

  This answer treats minimal diff as laziness; it’s the maximally accurate representation given that a SHA is equivalent to a full snapshot.

• Because a commit SHA uniquely identifies a snapshot (commit → tree → blobs), the SHA bump is exactly equivalent to a full content change — no additional diff data is needed in the outer tree
• Because Git compresses submodule diffs

  This answer invents compression; the diff is genuinely a one-line SHA bump, not compressed-then-expanded.

• Because submodules don’t actually change content

  This answer ignores that the SHA pin’s change is equivalent to a content change.

6. [Evaluate] A teammate says: ‘After every git pull I always run git submodule update --init --recursive, even on repos without submodules. Paranoia, or sensible?’

• Waste of time — it does nothing on repos without submodules

  This answer assumes the command fails or churns on non-submodule repos; it’s a fast no-op.

• Sensible. The command is a no-op on non-submodule repos (instant exit) and catches all submodule-state drift. Adding it to muscle memory costs nothing and prevents the most common submodule bug
• Harmful — it can corrupt non-submodule repos

  This answer assumes the command is dangerous; it’s strictly safe on any repo.

• Only useful on teams larger than 10 people

  This answer scopes the command to team size; it works regardless of how many collaborators are involved.

7. Upstream publishes a v0.2 commit. Put in order the commands that land it as a pinned version bump in your outer repo. Distractors are verb-variants that look right but fail or do the wrong thing. (arrange in order)

1. cd /tutorial/myproject/vendor/math-utils
2. git fetch # pulls new commits into submodule
3. git checkout origin/HEAD # move submodule HEAD to new SHA
4. cd /tutorial/myproject # back to outer repo
5. git add vendor/math-utils # stage the gitlink SHA change
6. git commit -m "Bump math-utils to v0.2.0"

• git pull # ambiguous in detached-HEAD submodule
• git submodule update # resets TO pinned SHA — opposite of what we want
• git commit -am "Bump" # would sweep in unrelated WD changes
• git merge origin/HEAD # creates a merge commit inside submodule

1. You see modified: vendor/math-utils (modified content) in the outer git status. What caused it?

• The submodule’s HEAD differs from the pinned SHA

  This answer confuses “modified content” (dirty inner working tree) with “new commits” (HEAD/pin divergence).

• The submodule’s working directory has uncommitted changes (untracked or unstaged)
• The .gitmodules file was edited

  This answer confuses submodule status messages with .gitmodules file edits.

• The submodule’s remote has new commits

  This answer requires a fetch first; remote state isn’t reflected without one, and even then status would show “new commits”, not “modified content”.

2. You see modified: vendor/math-utils (new commits) in the outer git status. What caused it?

• A file inside the submodule was edited but not committed

  This answer describes “modified content” (dirty inner working tree), not “new commits” (HEAD/pin divergence).

• The submodule’s HEAD has moved to a commit different from the one pinned by the outer repo’s tree
• The outer repo’s branch pointer moved

  This answer is irrelevant; this status compares pinned SHA vs. submodule HEAD, not the outer branch pointer.

• The submodule is corrupted

  This answer assumes corruption; the symptom is normal pin-divergence, not a broken repo.

3. You run git diff vendor/math-utils in the outer repo after making and committing a change in the submodule. What do you see?

• A full line-by-line diff of what changed inside the submodule

  This answer assumes the outer repo can show inner content diffs; it can’t — the inner repo owns those diffs.

• One line: -Subproject commit <old> / +Subproject commit <new> — the SHA bump is the only diff the outer repo stores
• An error message

  This answer assumes failure; outer diff works, it’s just minimal (one SHA-bump line).

• The diff of .gitmodules

  This answer confuses the gitlink-SHA diff with config-file edits.

4. Which commands reset a submodule’s working directory and HEAD to exactly the SHA the outer repo pins?

• git submodule update --init --recursive (and --force if local changes)
• git pull in the outer repo

  This answer updates the pinned SHA but doesn’t touch the submodule working tree.

• git reset --hard in the outer repo

  This answer resets the outer tree but doesn’t reach into submodule HEADs (Git keeps the boundary strict).

• rm -rf vendor/math-utils && git clone

  This answer is destructive when submodule update does the same job non-destructively.

5. [Revisit Step 3] Why is it consistent that the outer repo records ONLY a pinned SHA for each submodule — not the submodule’s files?

• Because file content inside a submodule is always confidential

  This answer assumes a privacy reason; the design is about deduplication, not confidentiality.

• Because a commit SHA uniquely identifies a snapshot (commit → tree → blobs), so one SHA is enough to reconstruct the submodule’s entire content — duplicating files would waste space
• Because submodules are always read-only

  This answer invents a constraint; submodules are read-write like any nested repo.

• Because Git uses a separate database for submodules

  This answer invents a separate storage system; submodules use the same Git object format.

6. [Evaluate] You edited vendor/math-utils/utils.py and saved. Your teammate pulls your branch and sees a clean git status. Why didn’t your edit get to them?

• Git hid the change because it was inside a submodule

  This answer assumes Git silently drops submodule edits; it doesn’t, you just have to publish them via the two-step ceremony.

• You modified the submodule’s working directory but never (a) committed inside the submodule and pushed, NOR (b) bumped the pinned SHA in the outer repo — so nothing in shared history carries the change
• Your teammate’s Git is out of date

  This answer blames version; the issue is missing publish steps, not tooling.

• Submodules never sync changes between collaborators

  This answer overstates the problem; submodule changes do sync once properly published.

7. [Revisit Step 1] You edit a file inside a submodule, run git add && git commit inside the submodule, then git push. Git errors with something like fatal: You are not currently on a branch. What Step-1 concept explains this?

• Detached HEAD — git submodule update normally checks out submodules in detached HEAD at the pinned SHA. Commits there are orphaned relative to any branch; push needs a branch
• Merge conflicts

  This answer invents a conflict; the issue is detached-HEAD’s lack of branch context for push.

• Missing upstream

  This answer is partial; even with an upstream, detached HEAD can’t push without a branch.

• Submodules are read-only by default

  This answer invents a permission model; submodules are writable.

8. [Revisit Step 8] You ran git rebase main inside a submodule and rewrote three of its commits. The outer repo’s git status says modified: vendor/math-utils (new commits). Is anything wrong with this?

• No issue — rebase inside a submodule is business as usual

  This answer ignores that the outer repo may still pin pre-rebase SHAs that need pushing for teammates’ historical clones to work.

• Rebase inside a submodule is fine in isolation, but the submodule’s old SHAs (still pinned by the outer repo’s older commits) now point to orphaned commits — teammates pulling older outer-repo history may fail to fetch them if they were never pushed. Treat submodule rebases with the same ‘safe zone’ rule as any other rebase
• Git prevents rebase inside submodules

  This answer assumes Git blocks rebase in submodules; it doesn’t.

• Rebase deletes the submodule

  This answer invents destructive semantics; rebase doesn’t delete repos.

9. The full “publish a submodule change” ceremony. Put the six required commands in order. Distractors are verb-variants that break one or more of the ceremony’s causal invariants. (arrange in order)

1. cd vendor/math-utils # (1) enter the submodule
2. git switch -c update-halve # (2) attach HEAD to a branch (NOT detached)
3. git commit -am "Add halve helper" # (3) create the commit inside submodule
4. git push -u origin update-halve # (4) publish the submodule SHA to its remote
5. cd ../.. # (5) return to outer repo
6. git add vendor/math-utils && git commit -m "Bump math-utils: add halve" # (6) pin new SHA and push outer

• git commit -am "..." # BEFORE switching to a branch — detached HEAD, un-pushable
• git submodule update --init --recursive # resets inner HEAD, losing your new commit
• git push --force origin update-halve # unneeded; no history to overwrite
• git rebase origin/main # rewrites SHAs you just created; defeats (4)

1. Match each scenario to the single best tool. Which option correctly pairs all four?

• (a) Backport one bug-fix commit to three release branches → git merge; (b) Integrate 50 commits of a long feature into main → git cherry-pick each one; (c) Clean up 10 WIP commits before opening a PR → git rebase -i; (d) Land a feature branch as one commit on main → git merge --no-ff

  This answer rejects cherry-pick’s canonical use case (one-commit backports) and uses merge for WIP cleanup, which doesn’t collapse history.

• (a) Backport one bug-fix commit to three release branches → git cherry-pick; (b) Integrate 50 commits of a long feature into main → git merge (or git rebase for linear history); (c) Clean up 10 WIP commits before opening a PR → git rebase -i; (d) Land a feature branch as one commit on main → git merge --squash
• (a) All four → git merge

  This answer collapses all distinctions into one tool; the four scenarios genuinely call for different verbs.

• (a) Backport → git rebase; (b) Feature integration → git cherry-pick; (c) WIP cleanup → git merge; (d) One-commit landing → git rebase

  This answer reverses the typical scope-to-tool mapping (rebase for surgery, cherry-pick for bulk).

2. [Interleaves Steps 3, 5, 8, 9, 10] Which of these operations create commits with new SHAs even when the patch is identical to an earlier commit? Select all that apply. (select all that apply)

• git cherry-pick <sha> onto a different branch
• git rebase main (non-interactive) on a feature branch
• git rebase -i HEAD~5 that reorders commits
• git merge --squash feature followed by git commit
• git merge feature (fast-forward) — just moves the branch pointer

  This answer treats fast-forward merge as creating commits; it only advances a ref pointer — no new SHAs.

• git branch feature — creates a branch pointer at the current commit

  This answer treats git branch as creating commits; it only writes a 41-byte ref file — no new SHAs.

3. [Interleaves Steps 2, 9, 1] You performed three destructive-feeling operations in sequence: git reset --hard HEAD~3, then git rebase -i dropping a commit, then entering detached HEAD and making a throwaway commit. Which single tool can recover commits lost in all three cases?

• git revert — it reverses any recent operation

  This answer ignores that revert applies to one commit’s effects, not arbitrary HEAD movements; reflog is the cross-cutting tool.

• git reflog + git branch <name> <sha> — reflog logs every HEAD movement regardless of which operation moved it, so the recovery recipe is identical across all three cases
• git stash pop — stash tracks destructive operations automatically

  This answer confuses stash (working-tree shelving) with reflog (HEAD-position history).

• Nothing — destructive operations are final

  This answer ignores reflog’s universal HEAD-position record; “destructive” only means refs moved, not data deleted.

4. [Interleaves basic tutorial Step 11 + advanced Step 8] You hit a conflict during git rebase main. You edit the file, remove all <<<<<<< / ======= / >>>>>>> markers, and run git add. Which command finishes this one commit’s resolution?

• git commit — identical to finishing a merge

  This answer treats rebase like merge; rebase needs --continue, not commit — commit would leave the rebase half-done.

• git rebase --continue — rebase is replaying commits one at a time; you are telling Git to resume the replay, not create a standalone commit
• git merge --continue

  This answer uses the wrong verb; this is a rebase, not a merge.

• git push --force

  This answer skips finalizing the rebase entirely.

5. [Interleaves Steps 6, 7] A bug appeared because someone removed a line of validation that used to prevent it. Which investigation tool finds the commit that introduced the bug?

• git blame — it shows the author of every existing line

  This answer ignores blame’s deletion blind spot; absent lines are invisible to blame.

• git bisect — it binary-searches based on behavior, which is the only signal available when the culprit is a deletion (blame cannot see a line that isn’t there)
• git log --grep="delete" — it finds commits with “delete” in the message

  This answer assumes the commit message reliably announces deletions; messages don’t index by content.

• git show HEAD — it shows the most recent commit

  This answer shows only the most recent commit, not the historical regression spanning many commits.

6. [Interleaves Steps 3, 11, 13] A submodule is stored in the outer repo as a gitlink entry (mode 160000) containing a 40-character SHA. That SHA references which kind of Git object?

• A blob object containing the submodule’s files

  This answer confuses commit objects with blob objects; gitlinks pin commits, which then resolve to trees and blobs.

• A tree object for the submodule’s root directory

  This answer confuses commit objects with tree objects; only a commit captures the snapshot identity.

• A commit object in the submodule’s own object database
• A tag object

  This answer confuses commit objects with tag objects; tags reference commits but aren’t stored in gitlinks.

7. [Interleaves Steps 8, 9, 10] Which of these operations are forbidden on a branch that has been pushed and is shared with teammates? Select all that apply. (select all that apply)

• git rebase main on the shared branch (rewrites its SHAs)
• git rebase -i HEAD~5 on the shared branch (rewrites its SHAs)
• git commit --amend on the tip of the shared branch (new SHA)
• git push --force (or --force-with-lease) to overwrite the remote
• git revert <sha> (appends an anti-commit, rewrites nothing)

  This answer correctly classifies revert as additive; selecting it would overstate revert’s risk on shared branches.

• git merge feature into the shared branch (appends a merge commit)

  This answer correctly classifies merge as additive; selecting it would conflate adding history with rewriting it.

8. [Interleaves Steps 2, 8] You rebased feature locally, then git push was rejected because teammate Alice had pushed to feature in the meantime. What is the safe recovery sequence? (arrange in order)

1. git reflog # find the pre-rebase SHA of `feature`
2. git reset --hard # undo your rebase locally
3. git pull # merge Alice's changes into your (unrebased) branch
4. git push # succeeds — no history was rewritten

• git push --force
• git rebase --abort
• git revert HEAD
• rm -rf .git && git clone

9. [Interleaves Steps 4, 7] You are mid-edit on a feature when a teammate asks you to bisect a regression on main. Your working tree has uncommitted changes you want to keep. Two tools from this tutorial compose to solve this cleanly — which pair?

• git commit -m "WIP" then git bisect — commit your WIP so bisect has a clean tree

  This answer pollutes history if pushed; the question prefers a private alternative for in-progress work.

• git stash then git bisect, then git stash pop when bisect is done and you are back on a named branch — keeps your WIP private and the tree clean for bisect’s HEAD movements
• git restore . then git bisect — discards your WIP so bisect has a clean tree

  This answer destroys the WIP that the question wants to preserve.

• git bisect then git stash — stash shelves the bisect state

  This answer reverses the order; stash must come before bisect to give it a clean tree to walk.

10. [Interleaves Steps 7, 10] Three months ago your team squash-merged the feature-stats branch into main. A regression has surfaced that bisect on main narrows down to the squash commit. The squash commit changed 800 lines. What is your next move?

• Revert the whole squash commit from main and re-investigate later

  This answer is too broad; the question asks for fine-grained resolution, not whole-feature reversion.

• Read every line of the 800-line squash diff until you find the bug

  This answer ignores the available finer-grained source on the feature branch’s preserved commits.

• git bisect on the (still-existing) feature-stats branch — its internal commits were preserved, giving fine-grained resolution that the squash on main destroyed
• Give up — squash merge permanently discards internal commits

  This answer assumes squash discards internal commits; it only flattens main’s history, the feature branch keeps them.

11. [The unifying insight] After working through the whole advanced tutorial, which statement best captures what every command you learned actually does?

• Git commands either delete old state or create new state; they never do both

  This answer is the old “either creates or moves, never both” simplification; most operations do both, the real invariant is that existing commits aren’t rewritten.

• Existing commit objects are immutable. Every command either creates new immutable objects (commits/trees/blobs), moves one or more refs, updates the index, updates the working tree, or transfers objects/refs to a remote — usually some combination of these. Nothing rewrites old commits in place; “destructive” commands only abandon refs, leaving the objects in .git/objects for reflog to find.
• Git commands are magical; the best strategy is to memorize the most common ones

  This answer abandons the underlying invariant for rote learning; the schema is what makes Git predictable.

• Commands behave unpredictably depending on remote configuration

  This answer mistakes per-command behavior for a remote-config sensitivity that doesn’t exist.

12. [Evaluate — meta] A junior teammate says: “Destructive Git commands like rebase and reset are too dangerous to use; I’ll stick with merge and revert only.” Evaluate this position.

• Correct — rebase and reset should be avoided by anyone who isn’t a Git expert

  This answer absolutizes a context-dependent rule; rebase/reset are routine on local branches.

• Partially correct — on shared branches, they really are dangerous, and revert/merge are the right tools there. On local/unpushed branches, rebase and reset are routine safe tools because reflog recovers anything within the configured retention window. Avoiding them entirely trades safety for history-quality and is a real cost on teams that value clean history
• Incorrect — there is no difference between local and shared branches

  This answer denies the very local/shared distinction that resolves the safety question.

• Incorrect — reflog auto-recovers destructive operations immediately in all cases

  This answer overstates reflog’s reach; it works within retention windows on local repos, not as a universal undo.