Git & Version Control Advanced Git Syllabus

Advanced Git syllabus — full chapter and topic list

Expand any chapter to see its topics and sub-topics. This is the whole examinable outline for Advanced Git in Git & Version Control, not a summary of it.

1. 1

   Rewriting History

   4 topics

   • Amending and Squashing Commits
   • Filtering History
   • Cherry-Picking Commits
   • Reverting vs Resetting on Shared History
2. 2

   Debugging with Git

   3 topics

   • Finding Bugs with git bisect
   • Tracing Code with git blame
   • Searching History with git log -S and -G
3. 3

   Submodules and Subtrees

   4 topics

   • Adding and Updating Submodules
   • Cloning Projects with Submodules
   • Subtree Merging
   • Submodules vs Subtrees Trade-offs
4. 4

   Worktrees and Sparse Checkout

   3 topics

   • Multiple Working Trees with git worktree
   • Sparse Checkout for Large Repos
   • Managing Monorepos
5. 5

   Hooks and Automation

   3 topics

   • Client-Side Hooks
   • Server-Side Hooks
   • Managing Hooks with Frameworks
6. 6

   Handling Large Files and Performance

   3 topics

   • Git Large File Storage (LFS)
   • Repository Maintenance
   • Packfiles and Garbage Collection

Advanced Git flashcards for Git & Version Control

20 of 54 cards from the Advanced Git deck — real questions with worked answers.

1. What does `git commit --amend` do, and what happens to the commit's SHA?

   It replaces the most recent commit with a new one that combines the staged changes and (optionally) a new message. Because commit content/metadata change, it produces a brand-new commit with a different SHA-1 hash; the old commit is discarded (orphaned).

2. How do you amend only the commit message of the last commit without changing its content?

   Run `git commit --amend -m "new message"` (or `git commit --amend` and edit in the editor) with nothing staged. Use `git commit --amend --no-edit` to keep the same message when you only added files.

3. What is interactive rebase and which command starts it for the last 3 commits?

   Interactive rebase lets you rewrite a series of commits (reorder, edit, squash, drop, reword). Start it with `git rebase -i HEAD~3`.

4. In an interactive rebase, what is the difference between the `squash` and `fixup` actions?

   `squash` combines the commit into the previous one AND lets you edit/merge the commit messages. `fixup` also combines it into the previous commit but discards the fixup commit's message, keeping only the earlier one's.

5. Why is amending or squashing already-pushed commits dangerous, and what is required to publish the result?

   Rewriting published history changes SHAs, diverging your branch from the remote. Collaborators' history breaks. Publishing requires a force push (`git push --force` or safer `--force-with-lease`).

6. What does `git commit --fixup=<commit>` combined with `git rebase -i --autosquash` accomplish?

   `--fixup=<commit>` creates a specially-labeled commit; `rebase -i --autosquash` then automatically reorders and marks it as a fixup for the target commit, so you don't hand-edit the todo list. You can set `rebase.autosquash true` to make it default.

7. What is `git filter-repo` and why is it preferred over `git filter-branch`?

   `git filter-repo` is the recommended tool for rewriting history at scale (e.g., removing a file/secret from all commits). It is far faster and safer than the deprecated `git filter-branch`, which is slow and error-prone.

8. Which `git log` options filter commits by author and by date range?

   `--author=<pattern>` filters by author; `--since=<date>`/`--after` and `--until=<date>`/`--before` filter by date. Example: `git log --author="Ann" --since="2 weeks ago"`.

9. How do you list only the commits that touched a specific file, including across renames?

   `git log -- <path>` shows commits touching that path; add `--follow` to track history through renames: `git log --follow -- <path>`.

10. What does the `git log --grep=<pattern>` option match against?

    It filters commits whose commit message matches the given regular expression. Combine multiple with `--all-match` to require all patterns.

11. What does `git cherry-pick <commit>` do?

    It applies the changes introduced by an existing commit onto the current branch as a NEW commit (with a new SHA), without merging the branches. It replays that single commit's diff on top of HEAD.

12. How do you cherry-pick a range of commits, and does the range include the first endpoint?

    `git cherry-pick A..B` applies commits after A up to and including B (A is excluded). Use `git cherry-pick A^..B` to include A itself.

13. What is the purpose of `git cherry-pick -x`?

    It appends a standardized line `(cherry picked from commit <sha>)` to the new commit's message, recording the source commit for traceability.

14. How do you resolve a conflict during cherry-pick and continue or abort?

    Fix the conflicting files, `git add` them, then `git cherry-pick --continue`. To stop and restore the pre-pick state, use `git cherry-pick --abort`; to skip the current commit, `git cherry-pick --skip`.

15. On shared/public history, why should you prefer `git revert` over `git reset`?

    `git revert` creates a new commit that undoes changes, preserving history so collaborators' clones stay consistent (no force push needed). `git reset` rewrites/moves the branch pointer, deleting commits from the line of history, which requires a destructive force push on shared branches.

16. What does `git revert <commit>` produce?

    A new commit whose diff is the inverse of the specified commit, effectively undoing its changes while keeping both commits in history.

17. Compare the three modes of `git reset`: `--soft`, `--mixed`, and `--hard`.

    All move HEAD (the branch pointer). `--soft`: leaves index and working tree unchanged (changes staged). `--mixed` (default): resets the index but not the working tree (changes unstaged). `--hard`: resets index AND working tree, discarding all changes permanently.

18. What does `git bisect` do and what search strategy does it use?

    It finds the commit that introduced a bug by binary search over the commit history. You mark a known-good and known-bad commit; Git checks out the midpoint repeatedly until it isolates the first bad commit.

19. What is the complexity of git bisect, i.e., roughly how many test steps for N commits?

    Because it is a binary search, it needs about $\log_2(N)$ steps. For example, $\sim 10$ tests can isolate a bug among $\sim 1000$ commits since $2^{10}=1024$.

20. Give the sequence of commands to start and run a manual git bisect session.

    `git bisect start`, then `git bisect bad` (current is broken), `git bisect good <old-sha>`. Git checks out a midpoint; test it and mark `git bisect good` or `git bisect bad`. Repeat until it reports the culprit, then `git bisect reset`.

See more Advanced Git flashcards →

Planning Advanced Git for Git & Version Control

Advanced Git (Git & Version Control) FAQ