SaveMyCert
Log in
5 of 5 free questions left today·for 30 a day
GH-900 · Domain 1

Understand Git and GitHub basics practice questions

Understand Git and GitHub basics is worth 28% of the GH-900 exam — the heaviest of the 7 domains. Version control and Git fundamentals, how GitHub relates to Git, accounts, organizations and enterprises, the GitHub Flow, Markdown, and GitHub Desktop and Mobile. Official weight range 25–30%. 6 fully worked examples are further down this page, answers included.

Exam weight
28%
the heaviest of the 7 domains
Questions
68
across 2 topics
Free, no account
5/day
a free account allows 30 a day
Explanations
Every option
right and wrong

Build a practice session

5 free questions left today.

Domains

How many?

Mode

Ready when you are

10 fresh questions drawn across 1 of 7 domains, in Learn mode.

Focused review

Every question you answer incorrectly, and every question you flag while practising, is saved here automatically. Finish a session and you can come back to re-drill just those.

6 sample Understand Git and GitHub basics questions, fully explained

Questions from the GH-900 bank mapped to domain 1, with the answer key and the reasoning behind every option. None of them repeat the examples on the main GH-900 practice page.

Question 1Understand Git and GitHub basics

A configuration file is tracked in a Git repository. A change committed last week broke the website, and the team wants the file exactly as it was before that change. What does version control make possible?

Choose one.

  • a
    Restoring the file's contents from a commit made before last week's change Correct

    Every commit is a stored snapshot, so the file can be brought back from any commit made before the faulty change, and the history of what happened is kept.

  • b
    Recovering the version from before last week's change from a backup outside Git

    No separate backup is needed: Git keeps every committed version of the file, not just the newest one, so the earlier version is already in the repository.

  • c
    Rebuilding the version from before last week's change from the commit messages

    Commit messages describe changes, but Git also stores the full contents of every committed version, so nothing has to be rebuilt by hand.

  • d
    Restoring the version from before last week's change from GitHub, not a clone

    A local clone holds the full history too; the earlier version can be restored on any clone without GitHub.

The concept

Version control lets you return a file or a whole project to any earlier committed state.

Why that’s the answer

Each Git commit stores a snapshot of the tracked files, so the version from before last week's change is still in the repository and can be restored (for example by reverting the faulty commit or checking out the old file). The distractors assume the earlier contents are missing, recoverable only from messages, or held only on GitHub; in Git every clone holds every committed version.

How to reason it out
  1. Note that the file is tracked and the faulty change was committed.
  2. Recall that every commit is a full snapshot kept in the history.
  3. Recall that the local repository holds that history, not just GitHub.
  4. Choose restoring the file from an earlier commit.

Exam tip: Committed means recoverable: any earlier commit can be brought back.

Git vs GitHub: Version Control Fundamentals for GitHub Foundations (GH-900) — the lesson that teaches this.

Question 2Understand Git and GitHub basics

Four developers need to change the same codebase during the same week without overwriting each other's work. Which benefit of version control helps them most?

Choose one.

  • a
    Each file can be edited by just one person at a time until that person saves and closes it

    File locking is how some older centralised systems avoided conflicts. It serialises the work instead of letting four people change the codebase at once, and Git does not work this way.

  • b
    Each change is tested by a build server before anybody else can save a file

    Automated testing is continuous integration, a separate practice. It does not keep developers from overwriting each other's changes.

  • c
    Each person's changes are recorded separately and can later be merged into one version Correct

    Version control lets each developer work on their own line of changes and then combines those changes, so nobody's work is overwritten.

  • d
    Each person's edits are synced live into one shared copy while they are typing

    Live co-editing of a single copy is how online document editors work. Version control instead keeps separate, recorded changes and merges them.

The concept

Version control supports parallel work: people change the same project at the same time and their changes are merged.

Why that’s the answer

The team needs parallel work without lost changes. In Git, each developer commits changes on their own branch or clone, and the changes are merged; Git flags the rare case where two people changed the same lines. Locking files serialises work, automated testing checks quality rather than protecting changes, and live co-editing of one shared copy is a different model with no separate recorded changes to combine.

How to reason it out
  1. Identify the need: several people, same codebase, same time, nothing overwritten.
  2. Recall that version control records each person's changes separately.
  3. Recall that separate changes are combined by merging.
  4. Choose separate recorded changes that are merged.

Exam tip: Version control lets many people change one project at once: work separately, then merge.

Git vs GitHub: Version Control Fundamentals for GitHub Foundations (GH-900) — the lesson that teaches this.

Question 3Understand Git and GitHub basics

A small team keeps a project in a cloud drive that already saves an automatic version history for each file. The team now wants to build two alternative versions of the whole project at the same time and later combine the best parts. Which benefit of Git is the strongest reason to move?

Choose one.

  • a
    A version history that keeps each earlier copy of a file so it can be restored

    Git does keep full history, but the cloud drive already provides per-file version history, so this is not a reason to move.

  • b
    Shared access that lets the whole team open the same project files online

    The cloud drive already gives the team shared access. Sharing files is not the gap described in the scenario.

  • c
    An off-site copy of the project files that is kept if a laptop is ever lost

    The cloud drive already keeps the files off the laptops. Protecting against a lost device is not the new requirement.

  • d
    Branches that let separate lines of work develop side by side and be merged Correct

    This is the requirement the cloud drive cannot meet: Git branches let two versions of the entire project evolve side by side, and merging combines them later.

The concept

Branching and merging: separate lines of work for a whole project that can be developed in parallel and combined.

Why that’s the answer

Several benefits of version control are real here, but the stem says the drive already gives per-file history, shared access and an off-site copy. The new requirement is two alternative versions of the whole project developed in parallel and combined later. That is exactly what Git branches and merges provide: each branch is an independent line of work across all files, and a merge brings the changes together while keeping the history of both.

How to reason it out
  1. List what the current tool already does: per-file history, sharing, off-site storage.
  2. Isolate the new requirement: parallel versions of the whole project, combined later.
  3. Match it to the Git concept: branches for parallel lines of work, merge to combine.
  4. Discard benefits the team already has, however true they are of Git.

Exam tip: Per-file history is common; project-wide branching and merging is what version control like Git adds.

Git vs GitHub: Version Control Fundamentals for GitHub Foundations (GH-900) — the lesson that teaches this.

Question 4Understand Git and GitHub basics

Which statement correctly describes the relationship between Git and GitHub?

Choose one.

  • a
    GitHub is a version control system; Git is the desktop app that is used to reach it

    The roles are reversed. Git is the version control system, and the desktop app for GitHub is called GitHub Desktop.

  • b
    Git is a version control system; GitHub is a platform that hosts Git repositories Correct

    Git is the open-source version control tool that tracks changes. GitHub is a cloud service that hosts Git repositories and adds collaboration features around them.

  • c
    Git and GitHub are two names for one tool, one used offline and one used online

    They are different things: Git is software you install, GitHub is a hosting service built around Git.

  • d
    Git is GitHub's command-line tool and needs a GitHub account to record a change

    Git is an independent open-source project and records changes locally without any GitHub account.

The concept

Git is the version control system; GitHub is a hosting and collaboration platform for Git repositories.

Why that’s the answer

Git is a free, open-source, distributed version control system that runs on your computer and records the history of a project. GitHub is a cloud platform that stores Git repositories and adds features such as pull requests, issues, GitHub Actions and access control. The tempting swap reverses the roles; GitHub Desktop, not Git, is the GitHub desktop app.

How to reason it out
  1. Ask which one tracks changes: Git.
  2. Ask which one hosts repositories and adds collaboration features: GitHub.
  3. Reject statements that merge the two or make Git depend on GitHub.
  4. Choose the version-control-system plus hosting-platform pairing.

Exam tip: Git tracks the changes; GitHub hosts the repositories and adds collaboration.

Git vs GitHub: Version Control Fundamentals for GitHub Foundations (GH-900) — the lesson that teaches this.

Question 5Understand Git and GitHub basics

A consultant installs Git on a laptop that has no internet connection, and she has no GitHub account. What can she do with Git on that laptop?

Choose one.

  • a
    Commit changes after the repository has been published to GitHub for the first time

    Commits are recorded in the local repository. Git does not need GitHub, or any server, to commit.

  • b
    Commit and branch in a new repository, but not share work until adding a remote Correct

    Git is a complete version control system on its own. Creating a repository, committing and branching all happen locally; only sharing the work needs a remote such as GitHub.

  • c
    Commit changes, but creating a branch needs a connection to a remote server

    Branches are created locally; they are just pointers in the local repository. A remote is only needed to share them.

  • d
    Create a repository whose history is stored on GitHub's servers by default

    A Git repository's history lives in its local .git directory. Nothing is stored on GitHub unless it is pushed there.

The concept

Git is a standalone tool: repositories, commits and branches all work locally without GitHub or a network.

Why that’s the answer

Git was designed as a distributed version control system, so every operation that creates history (init, add, commit, branch, merge, log) works on the local repository. GitHub, or any remote, is needed only to share work with others through push, fetch or pull. Each distractor wrongly moves one local operation onto a server.

How to reason it out
  1. Note the constraints: no internet, no GitHub account.
  2. Recall that Git keeps the repository and its history on the local disk.
  3. Recall that commit and branch are local operations.
  4. Choose the option where everything happens locally.

Exam tip: Git needs no network and no GitHub account; you only need a remote to share.

Git vs GitHub: Version Control Fundamentals for GitHub Foundations (GH-900) — the lesson that teaches this.

Question 6Understand Git and GitHub basics

A company decides to keep its Git repositories on a plain Git server on its own network instead of on GitHub. What does that mean for the developers who use Git?

Choose one.

  • a
    They can commit locally, but creating branches needs GitHub's servers to be reachable

    Branching is a local Git operation and works with any host, or no host at all.

  • b
    They need to convert each repository into a format the internal server can read

    A Git repository has the same format wherever it is hosted; no conversion is needed.

  • c
    They use the same Git commands, but GitHub pull requests and issues are unavailable Correct

    Git works with any Git server, so clone, commit, branch and push work exactly as before. What a plain Git server lacks is the GitHub platform layer, such as pull requests and issues.

  • d
    They can clone the repositories, but each push needs a separate GitHub user account

    Pushing to an internal server uses that server's accounts. A GitHub account is not involved.

The concept

Git does not depend on GitHub; repositories can be hosted on GitHub, another service or a self-managed server.

Why that’s the answer

GitHub is one of several places that can host Git repositories. Because Git is an independent open-source tool, developers use the same commands (clone, commit, branch, push, pull) against any Git remote. Only the GitHub-specific collaboration features, such as GitHub pull requests and issues, are unavailable when the repositories are not on GitHub.

How to reason it out
  1. Separate the tool (Git) from the host (GitHub or another server).
  2. Recall that Git commands work against any Git remote.
  3. Reject options that make branching, format or accounts depend on GitHub.
  4. Choose standard Git working the same way.

Exam tip: GitHub is one host for Git, not a requirement of Git.

Git vs GitHub: Version Control Fundamentals for GitHub Foundations (GH-900) — the lesson that teaches this.

What GH-900 domain 1 tests, topic by topic

The official exam guide breaks Understand Git and GitHub basics into 2 topics. The question bank follows the same split, so a weak topic shows up as a cluster of misses you can go back and read.

Published GH-900 practice questions per topic in Understand Git and GitHub basics
TopicWhat it coversQuestions
Version control fundamentalsOfficial GH-900 study guide, "Understand Git and GitHub basics" › "Version control fundamentals" (skills as of January 2026): Describe the purpose and benefits of version control; Explain the difference between Git and GitHub; Identify key Git concepts such as repositories, commits, and branches.34
Working with GitHubOfficial GH-900 study guide, "Understand Git and GitHub basics" › "Working with GitHub" (skills as of January 2026): Describe GitHub accounts, organizations, and enterprise options; Explain the GitHub Flow for collaboration; Identify uses of Markdown for clear communication in issues and pull requests; Recognize when to use GitHub Desktop and GitHub Mobile.34
Total68

Revise Understand Git and GitHub basics before you drill it

Git vs GitHub: Version Control Fundamentals for GitHub Foundations (GH-900)Expect short scenarios rather than definitions alone. Questions describe a team problem (overwritten files, a broken change, parallel work) and ask which benefit of version control addresses it; others sort capabilities into Git versus GitHub, often using a near-twin such as merging (Git) versus pull request review (GitHub). Git concept items probe the states a change passes through (modified, staged, committed, pushed), what a commit contains and how its ID is derived, what a branch is compared with a tag or fork, what still works on a clone when the server is down, and the direction and effect of clone, push, fetch and pull. Harder items combine two facts, so read each scenario for exactly which steps happened locally and which reached the remote.Working with GitHub: Accounts, Plans, the GitHub Flow, Markdown, Desktop and Mobile (GitHub Foundations GH-900)Questions are short practical scenarios: a group that needs shared ownership, a developer changing jobs, a team that needs a feature on private repositories, a company with a data-location or self-hosting rule, a step in the middle of a change, a piece of text to format in an issue, or a person who needs a tool for a situation. The options are usually near-twins that each exist on GitHub, so you need to know exactly what each one is for: personal versus organization plans, Team versus Enterprise, Enterprise Cloud versus Server versus data residency, a draft pull request versus other ways of flagging unfinished work, revert versus force-push, #number versus owner/repo#number versus @mentions, collapsed sections versus HTML comments, and Desktop versus Mobile versus CLI. Watch for the stated constraint (must stay private, lowest cost, no servers to run, without rewriting history, phone only) that rules out an otherwise workable choice. Some items ask you to select two.

Other GH-900 domains

All GH-900 practice questionsMixed sessions across all 7 domains — the way the real exam interleaves them.

Understand Git and GitHub basics: your questions

Understand Git and GitHub basics is domain 1 of the GH-900 exam guide and carries 28% of the scored content — the heaviest of the 7 domains. On a 60-question paper that works out to roughly 17 questions, though GitHub does not publish an exact per-domain count and individual exam forms vary.

Source

The domain weight and topic list on this page come from the official GH-900 exam guide.