Git & Version Control Advanced Git Flashcards

24 sample cards from the Advanced Git deck

Sampled from the end of the deck, so these are different cards from the ones shown on the syllabus page.

1. How do you update a submodule to the latest commit of its tracked remote branch?

   `git submodule update --remote <path>` fetches and checks out the newest commit of the configured branch. You must then commit the updated gitlink in the superproject to record the new pointer.

2. Why does a freshly cloned superproject have empty submodule directories, and how do you avoid it?

   `git clone` does not populate submodules by default — it only records them. Either run `git submodule update --init --recursive` afterward, or clone with `git clone --recurse-submodules <url>` to fetch everything at once.

3. What does the `--recurse-submodules` flag do on `git clone` and `git pull`?

   On clone it fetches and checks out all nested submodules automatically. On pull/checkout it updates submodule working trees to match the superproject's recorded commits, keeping them in sync.

4. In which state is a submodule's HEAD after `git submodule update`, and why does it matter?

   It is in a DETACHED HEAD at the recorded commit. Commits made there aren't on any branch, so to develop inside a submodule you must first check out a branch, otherwise new work can be lost.

5. What is subtree merging in Git?

   A strategy for embedding one project inside another by merging the second repo's contents into a subdirectory of the first, so its files live directly in the parent's tree/history with no separate metadata (no `.gitmodules`, no gitlink).

6. How do you add an external project into a subdirectory using `git subtree`?

   `git subtree add --prefix=<dir> <repo-url> <ref> --squash`. `--prefix` is the target directory; `--squash` collapses the imported history into a single commit.

7. How do you pull upstream updates into an existing subtree?

   `git subtree pull --prefix=<dir> <repo-url> <ref> --squash`, which merges the latest upstream changes into the subdirectory.

8. Contrast submodules and subtrees on where the external code's history and files live.

   Submodule: external repo stays a separate repository; the parent stores only a pointer (gitlink) + `.gitmodules`, and files aren't in the parent's commits. Subtree: external files and (optionally squashed) history are merged directly INTO the parent repo's tree and history.

9. Give two advantages of subtrees over submodules for consumers.

   1) A plain `git clone` gets all code with no extra commands (no `submodule update` step). 2) Contributors don't need to learn submodule commands — the files are just part of the repo. Trade-off: pushing changes back upstream and keeping history clean is more awkward than with submodules.

10. Give two advantages of submodules over subtrees.

    1) Exact version pinning with a small footprint — the parent stores only a commit pointer, not duplicated files/history. 2) Contributing back upstream is straightforward since the submodule is a real, independent repo you can commit and push from.

11. What problem does `git worktree` solve?

    It lets you check out multiple branches simultaneously in separate working directories that all share ONE underlying repository (.git), avoiding a full second clone and letting you work on several branches in parallel without stashing.

12. Which command creates a new linked worktree checking out a branch, and where does its directory live?

    `git worktree add <path> <branch>` creates a new working directory at <path> with that branch checked out. It's a linked worktree sharing the main repo's object database; use `-b <new-branch>` to create a branch at the same time.

13. Can two worktrees of the same repo have the same branch checked out simultaneously? How do you clean up worktrees?

    No — Git forbids checking out the same branch in two worktrees at once (prevents conflicting updates). Remove a worktree with `git worktree remove <path>`, and prune stale administrative entries with `git worktree prune`.

14. What is sparse checkout and what problem does it address for large repos?

    Sparse checkout populates the working directory with only a selected subset of files/directories instead of the whole tree, reducing on-disk size and speeding operations in very large repositories/monorepos where you only need part of the tree.

15. How do you enable and configure a cone-mode sparse checkout for a directory?

    `git sparse-checkout init --cone`, then `git sparse-checkout set <dir1> <dir2>` to choose the directories to materialize. Cone mode restricts patterns to whole directories, which is faster than the general non-cone pattern matching.

16. What is a partial clone and which flag creates a blobless clone often paired with sparse checkout?

    A partial clone omits some objects at clone time, fetching them on demand. `git clone --filter=blob:none <url>` creates a blobless clone (skips file blobs until needed); `--filter=tree:0` is even more aggressive. Combined with sparse checkout it makes huge monorepos usable.

17. Name three Git features commonly used to make large monorepos performant.

    1) Sparse checkout (cone mode) to limit working-tree files. 2) Partial/blobless clone (`--filter`) to limit downloaded objects. 3) The commit-graph file (`git commit-graph write`) and/or the built-in filesystem monitor (`core.fsmonitor`) to speed up history and status operations. Scalar is a wrapper that bundles these.

18. What are Git hooks and where are client-side hooks stored by default?

    Hooks are scripts Git runs automatically on certain events. Client-side (local) hooks live in `.git/hooks/` as executable files named after the event (e.g., `pre-commit`). They are NOT copied by clone, so they aren't shared through the repo by default.

19. Name three client-side hooks and when each fires.

    `pre-commit` runs before a commit is created (e.g., lint/test; a nonzero exit aborts the commit). `commit-msg` runs after the message is entered, to validate/format it. `pre-push` runs before pushing, to run final checks before updating the remote.

20. Name the key server-side hooks and their roles.

    `pre-receive` runs once before any refs are updated — can reject the entire push. `update` runs once PER ref being updated, allowing per-branch acceptance/rejection. `post-receive` runs after all refs are updated, for notifications/deployment/CI triggers.

21. How do you make a hook shared across a team, since `.git/hooks` isn't versioned?

    Store hook scripts in a tracked directory and point Git at it with `git config core.hooksPath <dir>`, or use a hook-management framework (e.g., pre-commit, Husky, Lefthook) that installs the hooks from versioned config so every clone gets them.

22. What is Git LFS and what problem does it solve?

    Git Large File Storage replaces large binary files in the repo with small text POINTER files, storing the actual file contents on a separate LFS server. This keeps the Git repo small and fast because large binaries don't bloat every clone's history.

23. Which commands set up Git LFS and start tracking `.psd` files, and what file records the rule?

    `git lfs install` (one-time setup), then `git lfs track "*.psd"`. The tracking rule is written to `.gitattributes` (which must be committed), telling Git to route matching files through LFS filters.

24. What does a Git LFS pointer file actually contain in the repository?

    A small text stub with metadata: the LFS spec version, the object's SHA-256 OID, and its size — for example lines like `version https://git-lfs.github.com/spec/v1`, `oid sha256:<hash>`, and `size <bytes>`. The real bytes are fetched from the LFS store on checkout.

What this deck covers

Advanced Git flashcards FAQ