Examius
🌍 Git & Version Control · flashcards
Git & Version Control Best Practices and Troubleshooting Flashcards
50 question-and-answer cards covering Best Practices and Troubleshooting as it is examined in Git & Version Control. 24 of them are printed below, taken from across the deck — no signup, no paywall on the preview.
24 sample cards from the Best Practices and Troubleshooting deck
Sampled from the end of the deck, so these are different cards from the ones shown on the syllabus page.
How do you preserve work made in a detached HEAD state?
Create a branch pointing to the current commit before switching away: 'git switch -c <new-branch>' (or 'git branch <name>' followed by checkout).
How do you leave a detached HEAD without keeping any new commits?
Simply check out an existing branch, e.g., 'git switch main' (or 'git checkout main'); the detached commits become unreferenced.
How do you undo a merge that has NOT yet been pushed or shared?
Use 'git reset --hard ORIG_HEAD' (or the pre-merge commit hash) to move the branch back to its state before the merge.
How do you safely undo a bad merge that has already been pushed to a shared branch?
Use 'git revert -m 1 <merge-commit-hash>', which creates a new commit reversing the merge while preserving history; '-m 1' selects the mainline parent.
Why does reverting a merge commit require the '-m' (mainline) option?
Because a merge commit has two parents, Git cannot infer which parent's state to revert to, so '-m <parent-number>' specifies which parent line to keep as the mainline.
How do you abort a rebase that is in progress and running into conflicts?
Run 'git rebase --abort', which restores the branch to its original state before the rebase started.
How can you undo a rebase that has already completed, returning to the pre-rebase state?
Use the reflog to find the pre-rebase tip and reset to it: 'git reset --hard HEAD@{n}' (or the specific hash shown before the rebase).
What does it mean for two branches to have 'diverged'?
Both the local and remote (or two) branches have unique commits the other lacks since their common ancestor, so neither can be fast-forwarded to the other.
What are the two main strategies to reconcile a diverged local and remote branch during a pull?
Merge ('git pull --no-rebase', creating a merge commit) or rebase ('git pull --rebase', replaying local commits on top of the remote tip).
After branches diverge, why can a 'git push' be rejected, and what is the safe fix?
The push is rejected because the remote has commits you lack (non-fast-forward). The safe fix is to integrate remote changes first via 'git pull --rebase' (or merge), then push—avoid blind force-push.
What is the safer alternative to 'git push --force' when updating a rewritten branch, and why?
'git push --force-with-lease', which refuses to overwrite the remote if it has been updated since you last fetched, protecting against clobbering others' commits.
Describe a typical solo developer Git workflow.
Often a single main branch (or short-lived feature branches) with direct commits, frequent local commits, optional rebasing to keep history clean, and pushing to a single remote for backup—minimal ceremony since there is no review process.
Describe the core of a small team Git workflow (feature branch / GitHub Flow).
Each feature is developed on a short-lived branch off main, opened as a pull request for review and CI, then merged back to a always-deployable main; releases come directly from main.
What is Git Flow, and what long-lived branches does it define?
A branching model for scheduled releases using two permanent branches—'main' (production) and 'develop' (integration)—plus supporting 'feature/', 'release/', and 'hotfix/' branches.
Compare trunk-based development with Git Flow for enterprise scale.
Trunk-based development keeps all developers committing to a single main trunk with very short-lived branches and feature flags, favoring continuous integration; Git Flow uses multiple long-lived branches suited to versioned, scheduled releases but adds merge overhead.
What is the 'forking workflow' commonly used in large open-source/enterprise projects?
Each contributor forks the central repository into their own copy, pushes to their fork, and submits pull requests to the upstream; maintainers review and merge, keeping the canonical repo protected from direct pushes.
What are protected branches and branch protection rules in enterprise workflows?
Rules on key branches (e.g., main) that enforce policies like required reviews, passing status checks, up-to-date branches, signed commits, and disallowing force-pushes or deletions before merging.
Which tool is the standard bidirectional bridge for migrating from SVN to Git?
'git svn', which can clone an SVN repository into Git and sync commits in both directions.
What does 'git svn clone -s <url>' do, and what does the '-s' flag assume?
It clones an SVN repository into a Git repo; '-s' (--stdlayout) assumes the standard SVN layout of trunk/, branches/, and tags/ directories.
Why is an authors mapping file important when migrating from SVN to Git?
SVN records only usernames, so an authors file maps each SVN username to a proper Git 'Name <email>' identity, ensuring correct attribution in the migrated history.
How do you create a portable bundle of a repository for import/export or transfer without a network remote?
Use 'git bundle create <file.bundle> <refs>' to package commits into a single file, then clone or fetch from it with 'git clone <file.bundle>' or 'git fetch <file.bundle>'.
What is the difference between a normal 'git clone' and 'git clone --mirror'?
A normal clone copies the default branch and sets up a working tree; '--mirror' creates a bare repository copying all refs (branches, tags, remotes) exactly and configures it to mirror the source for backups.
How do you keep a mirror backup repository up to date with its source?
In the bare mirror clone, run 'git remote update' (or 'git fetch --all') periodically; combined with 'git push --mirror' you can also propagate to another remote.
What is the difference between a bare and a non-bare Git repository, and where is each used?
A bare repository (created with 'git init --bare') has no working directory and stores only the Git data; it is used as a shared/central remote and for mirrors/backups, whereas a non-bare repo has a checked-out working tree for development.
What this deck covers
The Best Practices and Troubleshooting deck follows the Git & Version Control Best Practices and Troubleshooting syllabus — 4 chapters and 14 topics — so questions land on material that is genuinely examinable rather than trivia around it. That works out to roughly 12.5 cards per chapter.
Answers are written to be recallable, not just readable — averaging about 169 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.
Best Practices and Troubleshooting flashcards FAQ
How many Best Practices and Troubleshooting flashcards are in this Git & Version Control deck?
50 cards. This page previews 24 of them, sampled evenly across the deck so you can judge the difficulty before installing anything.
Are these Git & Version Control flashcards free?
Yes. The preview here is free to read with no signup, and the full 50-card deck is free inside the Examius app.
What do the Best Practices and Troubleshooting cards cover?
They follow the Git & Version Control Best Practices and Troubleshooting syllabus — 4 chapters and 14 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.