Examius
🌍 DevOps · flashcards
DevOps Version Control Systems Flashcards
49 question-and-answer cards covering Version Control Systems as it is examined in DevOps. 24 of them are printed below, taken from across the deck — no signup, no paywall on the preview.
24 sample cards from the Version Control Systems deck
Sampled from the end of the deck, so these are different cards from the ones shown on the syllabus page.
State the core conceptual difference between merging and rebasing.
Merge is non-destructive: it preserves the true branch history and creates a merge commit joining two lines. Rebase rewrites history to produce a linear sequence, moving commits onto a new base and giving them new hashes.
Why should you avoid rebasing commits that have already been pushed/shared?
Rebasing rewrites commit hashes and history. If others have based work on the original commits, rewriting them causes divergence and forces disruptive history reconciliation (the 'golden rule of rebasing': never rebase public/shared branches).
What is the command to interactively rebase the last 3 commits?
git rebase -i HEAD~3, which opens an editor to reorder, squash, edit, or drop those commits.
What is the trade-off summarized as merge vs rebase for history?
Merge keeps complete, true history but adds merge commits (more cluttered, non-linear). Rebase yields clean linear history but rewrites commits and loses the exact context of when work diverged.
What does git cherry-pick do?
It applies the changes introduced by one (or more) specific existing commit(s) onto the current branch, creating a new commit with the same content but a different hash.
Give a typical use case for cherry-picking.
Applying a specific bug-fix commit from one branch to another (e.g., backporting a hotfix to a release branch) without merging the entire source branch.
What is the command to cherry-pick a commit without immediately committing it?
git cherry-pick -n <commit> (or --no-commit), which applies the changes to the working tree/index but lets you commit manually.
What does git stash do?
It temporarily shelves (saves) uncommitted changes in the working directory and index, reverting the working tree to a clean HEAD state, so you can switch context without committing.
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 most recent stash and removes it from the stash list. git stash apply reapplies it but keeps it in the stash list for reuse.
How do you list saved stashes and apply a specific one?
git stash list shows all stashes (e.g., stash@{0}, stash@{1}). Apply a specific one with git stash apply stash@{n} (or pop stash@{n}).
By default, does git stash include untracked files? How do you include them?
No, by default git stash only saves tracked, modified files. Use git stash -u (--include-untracked) to also stash untracked files, or -a (--all) to include ignored files as well.
What does git clean do, and why is the -n flag important?
git clean removes untracked files from the working directory. The -n (--dry-run) flag previews what would be deleted without removing anything, which is important because the deletion is not recoverable via Git.
What does git clean -fd do?
It forcibly (-f) removes untracked files and also removes untracked directories (-d). The -f flag is required because Git refuses to clean by default for safety.
What is a Git hook?
A Git hook is a script that Git automatically executes when certain repository events occur (e.g., committing, merging, pushing), allowing you to automate or enforce custom actions and policies.
Where are Git hooks stored, and are they shared via the repository by default?
They live in the .git/hooks directory of a repository. By default they are local and NOT copied/cloned with the repo, so they are not shared automatically (tools like a tracked hooks dir or pre-commit framework are used to share them).
What is the difference between client-side and server-side hooks?
Client-side hooks run on the developer's machine for actions like committing and merging (e.g., pre-commit, prepare-commit-msg, post-merge). Server-side hooks run on the remote receiving pushes (e.g., pre-receive, update, post-receive) to enforce policies.
What does the pre-commit hook do and a common use for it?
It runs before a commit is finalized; if it exits non-zero, the commit is aborted. It is commonly used to run linters, formatters, or tests to reject substandard commits.
What does the commit-msg hook do?
It runs after the commit message is entered and receives the path to the message file; it can validate or enforce message format (e.g., requiring a ticket number or conventional-commit style) and abort the commit if invalid.
What must a hook script have to actually run?
It must be named exactly the hook name (no extension, e.g., pre-commit) inside .git/hooks and must be executable (chmod +x). Sample hooks ship with a .sample suffix, which disables them.
What is the difference between git reset and git revert?
git reset moves the branch pointer (and optionally the index/working tree) to a previous commit, rewriting/removing later history locally. git revert creates a new commit that undoes a previous commit's changes, preserving history (safe for shared branches).
What do git reset --soft, --mixed, and --hard each affect?
--soft moves HEAD only (keeps index and working tree, changes left staged). --mixed (default) moves HEAD and resets the index (changes left unstaged). --hard moves HEAD and resets both index and working tree, discarding changes.
What is HEAD in Git?
HEAD is a reference (pointer) to the currently checked-out commit, normally pointing to the tip of the current branch. A 'detached HEAD' means it points directly at a commit rather than a branch.
What is the purpose of a .gitignore file?
It specifies intentionally untracked file patterns that Git should ignore (e.g., build artifacts, secrets, logs), preventing them from being staged or committed. It does not affect files already tracked.
How can you view the commit history compactly as one line per commit?
git log --oneline, which shows each commit as an abbreviated hash plus the commit summary; adding --graph --all visualizes branch and merge structure.
What this deck covers
The Version Control Systems deck follows the DevOps Version Control Systems syllabus — 2 chapters and 8 topics — so questions land on material that is genuinely examinable rather than trivia around it. That works out to roughly 24.5 cards per chapter.
Answers are written to be recallable, not just readable — averaging about 188 characters, which is long enough to carry the reasoning and short enough to say out loud.
A deck like this earns its keep on the second and third pass. Read the syllabus first so you know the shape of the subject, then use the cards to find the specific facts that have not stuck.
Version Control Systems flashcards FAQ
How many Version Control Systems flashcards are in this DevOps deck?
49 cards. This page previews 24 of them, sampled evenly across the deck so you can judge the difficulty before installing anything.
Are these DevOps flashcards free?
Yes. The preview here is free to read with no signup, and the full 49-card deck is free inside the Examius app.
What do the Version Control Systems cards cover?
They follow the DevOps Version Control Systems syllabus — 2 chapters and 8 topics — so the questions track what is actually examinable.
How should I use these flashcards?
Read the syllabus first so you know the shape of the subject, then drill the deck. Examius schedules each card with spaced repetition, so cards you keep missing come back sooner and ones you know drift further apart.