Practice status

{{ summaryValue }}

{{ summaryLine }}

Build a practice round

Practise Git commands and repository state with immediate explanations. These scenarios never run commands or access your repositories.

Optional: leave blank for git-practice-1, or reuse a seed for the same questions and option order.

{{ quizSetupValidation }}

{{ Math.round(progressPercent) }}%
{{ answeredCount }} of {{ questionCount }} answered

{{ progressStatusLine }}

Question {{ quizCursor + 1 }} of {{ questionCount }}

{{ quizPromptText(currentQuestion.stem) }}

{{ currentQuestion.accessible_clue }}

{{ feedbackOutcome === 'correct' ? 'Correct' : 'Incorrect' }}

Correct answer: {{ quizAnswerText(currentResultRow.prompt, currentResultRow.correct_label) }}

{{ currentResultRow.explanation }}

Source: Git command manual · {{ currentResultRow.source.version }} · {{ currentResultRow.source.license }}

Review what to practice next

{{ resultLead }}

Original curated bank v1.0.0 · Git manuals reviewed 10 September 2026. This practice score is not a certification or a measure of job readiness. Saved links include your answers.

Practice review

{{ learningReviewTitle }}

{{ learningReviewLine }}

{{ card.label }}
{{ card.value }}
{{ card.note }}

Missed answer review

  1. {{ quizPromptText(item.prompt) }}

    Your answer: {{ quizAnswerText(item.prompt, item.selected_answer_label) }}

    Correct answer: {{ quizAnswerText(item.prompt, item.correct_answer_label) }}

    {{ item.explanation }}

    Source: {{ item.source.label }} · {{ item.source.version }} · {{ item.source.license }}

Topic performance

Which topics need another look? Counts describe this round only; small samples do not establish proficiency.

Loading topic-performance chart…

{{ quizChartStatus }}

{{ quizChartExportStatus }}

Answer ledger

Question ID Prompt Topic Your answer Correct answer Outcome Explanation Source Copy
{{ row.question_id }} {{ quizPromptText(row.prompt) }} {{ row.category_label }} {{ quizAnswerText(row.prompt, row.selected_answer_label) }} {{ quizAnswerText(row.prompt, row.correct_answer_label) }} {{ row.outcome_label }} {{ row.explanation }} {{ row.source ? row.source.label : '—' }}

{{ quizLedgerExportStatus }}

Git Branch Staleness Analyzer Review a dated Git branch inventory locally to find stale or diverged work, protect important names, and build a safer cleanup queue.
Git Diff Risk Analyzer Rank Git diff files by churn and repository risk signals, with transparent scores that guide owner review without claiming merge safety.
Conventional Commit Messages Checker Check Conventional Commit headers or full messages against repository rules and see each valid message’s release impact before publishing.
.gitignore Generator Build a repository-ready .gitignore from your stack and team setup, with secret-file exceptions and warnings for broad or duplicate rules.

Saving a file, staging it and committing it are different events in Git. A correction can be present in your editor but absent from the next commit, or recorded in a local commit but absent from a teammate's repository. Understanding those differences prevents incomplete commits and mistaken assumptions about what has been shared.

Git records version history as commits, each describing a project snapshot and its relationship to earlier commits. A repository stores that history. In an ordinary clone, the repository is local, so inspecting history and creating commits are separate from contacting a remote server. Three terms explain how an edit becomes part of that history.

Working tree
The checked-out files you edit. Their current contents may differ from both the staged contents and the last commit.
Index, or staging area
The content prepared for the next ordinary commit. Staging captures the selected content at that moment, rather than continuously following later edits.
HEAD
The reference that identifies your current position in history, normally through the checked-out branch. Where a commit exists, commands can use HEAD to refer to that commit.

This separation lets a finished bug fix be committed without including an unfinished experiment. It also explains why editing a file after staging it requires another decision about what to include. A newly created, untracked file needs to be added before it participates in the normal staged-commit workflow.

Branches name lines of development without requiring a separate copy of the entire project for every branch. A branch name is a movable reference to a commit, and several branches can share earlier history. When work diverges, integrating it involves the relationship between those histories as well as the file contents. A conflict means Git needs a decision about the intended result; accepting or staging a resolution does not establish that the program is correct.

Collaboration adds another repository, usually called a remote. Fetching obtains remote history, while pushing asks the remote to accept local commits. Neither action is a substitute for staging and committing your edits. A local commit can normally be made without a network connection, but it has not been published merely because it exists on your computer.

Recovery depends on what should be preserved. Removing an edit from the next commit, discarding an edit from a file and reversing a published commit are different operations. Some commands overwrite uncommitted work, while rewriting shared history can disrupt collaborators. Inspecting the current state and preserving useful work matter more than recognising a familiar command name.

How to Use This Tool:

Choose mixed practice to find gaps, or focus on a particular kind of Git mistake. The default is All fundamentals with six questions.

  1. Choose a Practice set and Question count. All fundamentals offers 3, 6, 12 or 24 questions. Each topic set—State & staging, Branches & merges, Remotes or Recovery—offers 3 or 6. Command choices offers 3, 6 or 11, while State reasoning offers 3, 6, 12 or 13. Changing sets resets the count to six.
  2. Enter an optional Replay seed under Advanced, or keep the default. Blank uses git-practice-1, so leaving it blank does not create a randomly chosen seed. Keep the same set, count, seed and bank version to reproduce the questions and option order. Surrounding spaces are trimmed. Seeds allow at most 128 characters; shorten an overlong seed if its validation message appears.
  3. Select Start practice, then choose one of the four text answers. Selecting an answer records it immediately and locks it for that attempt. There is no separate submission button or opportunity to change that answer after seeing the correction.
  4. Read the Correct or Incorrect feedback, the correct answer and the explanation before selecting Next question. Feedback includes a Git manual reference. After the last answer, select View results. Every selected question must be answered; there is no skipped-question or early-finish result.
  5. Choose a replay after reviewing the completed round. Retry missed starts a new attempt containing only questions answered incorrectly and is absent after a perfect round. Replay same seed repeats the current round's questions and option order. Try a new seed changes the seed but can repeat questions. Each replay starts without inherited answers. Use Change setup to clear the attempt and choose another set or count.

Interpreting Results:

During a round, Practice status reports how many questions you have answered, not how many are correct. After completion, its fraction changes to correct answers out of selected questions. Use Missed answer review to compare your choice with the correction, and the Answer ledger to revisit every answered scenario.

Topic performance shows correct and missed counts for this round. The suggested review focus follows the category with the most misses, not a calibrated measure of your weakest skill. Short mixed rounds need not balance the topics, and an untested topic is not rated. A Perfect round means no misses in that attempt, not demonstrated proficiency. Practise the missed distinction in a disposable repository before relying on it in important work.

The original curated bank contains 24 scenarios, with six in each of the four topics. Bank version 1.0.0 records Git manual reviews dated 10 September 2026. It is not a complete Git curriculum, an official examination, a certification or a measure of job readiness. Its review date does not establish coverage of every subsequent Git release.

Technical Details:

For a tracked file outside a conflict, the working tree, index and current commit can contain different versions. A command's comparison or destination determines whether it inspects an edit, stages it, records it or overwrites it.

Inspecting and recording changes

These commands distinguish the content currently being edited from the content prepared for a commit.

Command Comparison or change Important distinction
git diff Compares tracked working-tree content with the index. Shows unstaged changes, not newly untracked file contents or the already-staged changes.
git diff --cached Compares the index with HEAD by default. Reviews staged changes. --staged is an equivalent spelling.
git status --short Summarises the index and working-tree status of paths. Reports status codes rather than the changed file contents.
git add app.txt Updates the index with the specified file's current content. Later edits are not automatically staged.
git commit Records the prepared index snapshot as a new local commit. This describes an ordinary commit without options or file arguments that change content selection.

For ordinary tracked-file entries in short status, the first column describes the index relative to HEAD, and the second describes the working tree relative to the index. MM therefore means both staged and unstaged modifications exist. Unresolved merge-conflict entries use different meanings and should not be read with that ordinary two-comparison rule.

The -a option in git commit -am "Update" automatically stages modifications and deletions of already tracked files, not new untracked files. Likewise, adding a tracked path to .gitignore does not stop tracking it or erase earlier commits. Previously committed secrets are not removed from history by an ignore rule.

Branches, merges and rewritten commits

With a clean working tree and an unused branch name, git switch -c feature creates and switches to feature at the starting commit. Subsequent commits advance that branch reference. git log --graph --oneline --all inspects a compact graph of history reachable through local references, including remote-tracking references, without moving a branch or rewriting files.

A fast-forward is possible when the current branch tip is an ancestor of the target. If main remains at commit A while feature continues through B to C, main can move to C without creating a merge commit. --no-ff can deliberately request a merge commit instead. Divergent histories normally require a merge commit to join them when using a regular merge.

After a content conflict, editing the file produces a proposed resolution. git add app.txt records that resolution in the index; the merge still needs to be completed after inspecting and testing the result. Rebase takes a different approach by replaying commits onto another base. Different parents normally mean new commit identities, so rewriting commits that others already use requires coordination.

Local history and remote history

A normal non-bare clone creates a local repository with fetched history and a checked-out working tree. Bare, shallow and no-checkout options change those assumptions. Ordinary commits are local operations, although repository-specific hooks—scripts run around Git operations—can impose extra requirements.

Under a normal clone configuration, git fetch origin downloads objects and updates the configured remote-tracking references without merging into the current branch or replacing working-tree files. After fetching, origin/main records the fetched view of the remote branch. It is not a live connection and can become stale when someone else pushes.

With normal branch mappings, git push origin main attempts to update the remote's main from local main. It does not stage or commit uncommitted edits, and acceptance is not guaranteed. When the remote contains new commits, fetching and inspecting its history comes before choosing an appropriate merge or rebase. Force-pushing can replace remote history and is not the default remedy for that rejection.

Recovery choices and preservation limits

These operations are not interchangeable. The examples assume ordinary tracked paths without unresolved conflicts; the unstaging example also assumes that HEAD resolves to an existing commit.

Operation What changes Preservation limit
git restore --staged app.txt Restores the index entry from HEAD by default. Unstages the path while leaving working-tree edits alone, unless working-tree restoration is also requested.
git restore app.txt Restores the working-tree path from the index by default. Can discard unstaged edits. It does not mean “keep the file and merely unstage it”.
git reset --hard HEAD Resets tracked index and working-tree content to HEAD. Discards tracked uncommitted changes and may remove obstructing untracked paths. Preserve useful work first.
git revert <commit> Creates a new commit reversing an earlier ordinary commit's changes. Preserves existing history but can conflict. Reverting a merge requires choosing its mainline parent.
git stash push -u Temporarily saves tracked edits and untracked files. Excludes ignored files. Default stash omits untracked files; -a includes ignored files too.

git reflog can help locate an earlier local branch tip after an accidental move. Reflog entries record local reference updates and expire; they are not shared as a universal recovery record across clones. A stash is also local, not an off-device backup. Neither provides a guarantee that arbitrary discarded edits can be recovered.

Practice score and progress

Each question has one correct choice worth one point. An incorrect choice earns zero, with no partial credit, weighting or negative penalty. Let C be correct answers, A answered questions and N questions selected for the current attempt. The point score S equals the correct count, out of N possible points. C, A and N are whole-question counts, with N > 0.

S=C 0≤C≤A≤N

Accuracy uses the full selected-question count as its denominator, including questions not yet answered during an unfinished attempt.

Accuracy (%)=100× CN

Progress instead measures the share of selected questions that have an answer, regardless of correctness.

Progress (%)=100× AN

Counts remain exact integers. Accuracy is calculated without intermediate rounding. Only the visible progress label rounds to the nearest whole percent, with half-percent ties rounded upward. The completed headline uses the correct/total fraction. Unanswered questions are not classified as incorrect or included in missed-only practice.

For example, one correct and one incorrect answer in a six-question round gives 2/6 answered and 33% displayed progress. Accuracy against the selected round is about 16.67%, not 50%. Four questions remain unanswered, only one is missed, and a final review is not yet available.

There is no pass mark or proficiency band. Selection is seeded and without replacement, so a question appears at most once within a round. A new seed does not add questions to the bank. Selecting an entire pool still includes the same items, and comparing different pools, counts or previously reviewed rounds does not produce a standardised proficiency comparison.

Privacy and Saved Attempts:

The scenarios are text exercises. The quiz does not run Git commands or access your repositories, and it does not request repository files or Git credentials. Scoring happens in the browser, but loading the page or its external chart resources can still make network requests.

Setup choices, the seed, answers and your position in the round are carried in the page URL, including partial attempts. Anyone receiving a saved link can restore those choices. URLs may enter browser history or be transmitted when loaded or shared, so use a non-sensitive Replay seed. Clearing the current attempt does not erase previously saved or shared copies. There is no account-based quiz progress history.

A malformed or incompatible link may produce Saved attempt unavailable rather than restore the old round. Choose an available set and count in setup, then select Start practice to begin a fresh attempt.

Worked Examples:

A staged correction followed by another edit

For the scenario about staging a file and editing it again, suppose tracked app.txt was committed with title=Draft. You change it to title=Final and stage it, then change the working file to title=Review without staging again. Choose the answer saying that a plain commit records the version captured by the last git add. The feedback is Correct. The prepared content is title=Final, while the later edit remains outside that commit. Comparing staged and unstaged differences tells you whether another staging step is appropriate.

One miss in the full bank

Select All fundamentals and 24 questions. Suppose the only wrong answer is the question about editing a file after staging it. The completed score is 23/24, equivalent to about 95.83% accuracy. State & staging has five correct answers and one miss; each other topic has six correct. The missed review identifies the staging distinction to revisit. Selecting Retry missed creates a one-question attempt. Answering it correctly produces 1/1 for that new attempt, not a revised 24/24 score for the original round.

References: