Git & Version Control Core Git Workflow Flashcards

24 sample cards from the Core Git Workflow deck

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

1. What does plain `git diff` (no arguments) show?

   The differences between the working directory and the staging area (index) — i.e., changes you have made but not yet staged.

2. What does `git diff --staged` (or `--cached`) show?

   The differences between the staging area (index) and the last commit (HEAD) — i.e., the changes that are staged and will go into the next commit.

3. What does `git diff HEAD` show?

   All differences between the working directory and the last commit, combining both staged and unstaged changes.

4. How do you see the differences between two commits with `git diff`?

   `git diff <commit1> <commit2>`, which shows the changes needed to transform the first commit's tree into the second's.

5. What does `git show <commit>` display?

   The metadata and content of a single object; for a commit it shows the author, date, message, and the full diff (patch) introduced by that commit.

6. What does `git blame <file>` show?

   A line-by-line annotation of the file indicating, for each line, the commit hash, author, and date of the last revision that modified that line.

7. What is the difference between `git blame` and `git log`?

   `git log` shows commits chronologically (history of the repo/file), whereas `git blame` maps each individual line of a file to the specific commit and author that last changed it.

8. How do you unstage a file that you have added with `git add` (modern syntax)?

   `git restore --staged <file>` (or the older `git reset HEAD <file>`). This removes it from the index while keeping the working-directory changes intact.

9. How do you discard unstaged changes to a tracked file, reverting it to the last committed version?

   `git restore <file>` (or the older `git checkout -- <file>`). This is destructive: the uncommitted changes are lost.

10. What does `git revert <commit>` do?

    It creates a NEW commit that applies the inverse of the changes introduced by the specified commit, undoing its effect while preserving history. It is the safe way to undo a commit that has already been shared/pushed.

11. How does `git revert` differ from `git reset` conceptually?

    `git revert` undoes changes by adding a new inverse commit, keeping history intact (non-destructive, safe for shared branches). `git reset` moves the branch pointer backward, rewriting/removing history (destructive, best for local/unshared commits).

12. What does the `-n` / `--no-commit` option do with `git revert`?

    It applies the inverse changes to the working tree and index but does not create the revert commit automatically, letting you combine or edit before committing yourself.

13. What are the three modes of `git reset` and how do they differ?

    `--soft` moves HEAD only (changes stay staged); `--mixed` (default) moves HEAD and resets the index (changes become unstaged but kept in working dir); `--hard` moves HEAD and resets both index and working directory (changes are discarded).

14. What does `git reset --hard HEAD~1` do?

    It moves the current branch back by one commit and discards all changes from that commit in both the index and working directory. This is destructive and permanently drops those uncommitted changes.

15. What does `git reset --soft HEAD~1` accomplish?

    It undoes the last commit but keeps its changes staged in the index, effectively letting you re-commit them (e.g., to combine or rewrite the commit message).

16. What is the reflog and what does `git reflog` show?

    The reflog is a local log recording every update to the tips of branches and HEAD (commits, resets, checkouts, rebases, etc.). `git reflog` lists these movements with their hashes, enabling recovery of commits that seem lost.

17. How can you recover a commit after an accidental `git reset --hard`?

    Find the lost commit's hash in `git reflog`, then restore it, e.g. `git reset --hard <hash>` or `git checkout <hash>` (or create a branch at it). The reflog retains the reference even though no branch points to it.

18. What does `git stash` do?

    It saves your uncommitted changes (staged and unstaged tracked modifications) onto a stack and reverts the working directory to a clean state matching HEAD, so you can switch context without committing.

19. How do you reapply the most recent stash, and what is the difference between `git stash pop` and `git stash apply`?

    `git stash pop` reapplies the top stash and removes it from the stash stack; `git stash apply` reapplies it but keeps it on the stack so it can be applied again.

20. How do you view the list of saved stashes and inspect one?

    `git stash list` shows all stashes as `stash@{0}`, `stash@{1}`, etc.; `git stash show [-p] stash@{n}` displays its summary or full diff.

21. How do you apply or drop a specific (non-top) stash from multiple stashes?

    Reference it by index, e.g. `git stash apply stash@{2}` to apply it or `git stash drop stash@{2}` to delete it. `git stash clear` removes all stashes.

22. How do you include untracked files when stashing?

    `git stash -u` (or `--include-untracked`) also stashes untracked files; `git stash -a` (`--all`) additionally includes ignored files.

23. What does `git clean` do, and why does it require a force flag?

    It removes untracked files from the working directory. Because deletion is irreversible, Git requires `-f` (`--force`) to actually delete; without it (or a dry-run) it refuses for safety.

24. What is the difference between `git clean -n`, `git clean -f`, and `git clean -fd`?

    `-n` (`--dry-run`) lists what would be removed without deleting; `-f` force-deletes untracked files; `-fd` force-deletes untracked files AND untracked directories. Adding `-x` also removes ignored files.

What this deck covers

Core Git Workflow flashcards FAQ