Try 10 focused GitHub Foundations GH-900 questions on Git and Github Basics, with explanations, then continue with IT Mastery.
Open the matching IT Mastery practice page for timed mocks, topic drills, progress tracking, explanations, and full practice.
Try GitHub Foundations GH-900 on Web View full GitHub Foundations GH-900 practice page
| Field | Detail |
|---|---|
| Exam route | GitHub Foundations GH-900 |
| Topic area | Understand Git and Github Basics |
| Blueprint weight | 30% |
| Page purpose | Focused sample questions before returning to mixed practice |
Use this page to isolate Understand Git and Github Basics for GitHub Foundations GH-900. Work through the 10 questions first, then review the explanations and return to mixed practice in IT Mastery.
| Pass | What to do | What to record |
|---|---|---|
| First attempt | Answer without checking the explanation first. | The fact, rule, calculation, or judgment point that controlled your answer. |
| Review | Read the explanation even when you were correct. | Why the best answer is stronger than the closest distractor. |
| Repair | Repeat only missed or uncertain items after a short break. | The pattern behind misses, not the answer letter. |
| Transfer | Return to mixed practice once the topic feels stable. | Whether the same skill holds up when the topic is no longer obvious. |
Blueprint context: 30% of the practice outline. A focused topic score can overstate readiness if you recognize the pattern too quickly, so use it as repair work before timed mixed sets.
These questions are original IT Mastery practice items aligned to this topic area. They are designed for self-assessment and are not official exam questions.
Topic: Understand Git and Github Basics
A student team is working in a shared GitHub repository. One member wants to try a new folder structure for the project, but the team does not want unfinished changes to affect the default branch before others review them. What is the best approach?
Options:
A. Create a new branch, make the changes there, and open a pull request when ready
B. Commit the experimental changes directly to the default branch
C. Create an issue and use it to store the file changes
D. Post the idea in Discussions and wait to edit the default branch later
Best answer: A
Explanation: Branches provide an isolated line of work inside a repository. They let someone try changes safely without changing the default branch, then use a pull request for review before merging.
The core concept is that a branch is a separate line of development. In this scenario, the student wants to experiment without affecting the repository’s default branch, so the safest GitHub workflow is to create a branch, commit changes there, and then open a pull request when the work is ready for review.
This supports a simple beginner workflow:
Committing directly to the default branch skips the protection that branches provide, while Discussions and Issues help communication and tracking but do not isolate code changes.
Topic: Understand Git and Github Basics
A small team already uses a GitHub repository for its marketing website. The team is now starting a separate internal tool with different contributors, its own README, issues, and release history. They want to collaborate on it in GitHub without mixing it with the website codebase.
What is the best action?
Options:
A. Post the tool’s files in a GitHub Gist
B. Create a new branch in the website repository
C. Create a new repository for the internal tool
D. Add the internal tool in a new folder in the website repository
Best answer: C
Explanation: A new repository is appropriate when a new project needs its own codebase, history, documentation, and collaboration tracking. In this scenario, the internal tool is separate from the website and should not share the same repository structure.
A GitHub repository is the main container for a project’s files, commit history, issues, and collaboration. When a team starts a distinct project that will have its own contributors, documentation, work tracking, and release lifecycle, creating a new repository is the clearest choice. That keeps the project organized and avoids mixing unrelated code and history with another product.
A branch is better for temporary or parallel work inside the same project, not for launching a separate shared codebase. A folder inside the existing repository would combine two different projects under one history and workflow. A Gist is useful for sharing small snippets, not for managing a full team project.
The key signal here is that the internal tool is a separate project, so it should have its own repository.
Topic: Understand Git and Github Basics
A developer updates README.md and app.js in a repository, then saves those changes with a message so the exact state can be viewed later in the project’s history. Which Git concept does this describe?
Options:
A. A pull request
B. A branch
C. A commit
D. An issue
Best answer: C
Explanation: This describes a commit. In Git, a commit is a recorded snapshot of changes at a point in time, usually saved with a message so it becomes part of repository history.
A commit is the basic history record in Git and GitHub. When someone saves changes with a commit message, Git records a snapshot of those changes so the repository’s history shows what changed and when. In this scenario, the developer changed files and saved that state for later review, which is exactly what a commit does.
A branch is a separate line of work, while a pull request is used to propose and review changes. An issue tracks work or discussion, not file snapshots.
Topic: Understand Git and Github Basics
A student team stores its website in a GitHub repository. Two members need to update the same project this week, but they do not want to overwrite each other’s work or change the main version until the updates are reviewed.
Which GitHub concept best solves this collaboration problem?
Options:
A. Use Discussions to keep code changes separate
B. Use stars to track who edited the project
C. Use Issues to prevent file conflicts
D. Use branches for separate work, then merge reviewed changes
Best answer: D
Explanation: The core version control benefit here is parallel work without overwriting the main project. Branches let each teammate make changes independently, and those changes can be reviewed and merged later.
This scenario is about a basic version control benefit: allowing multiple people to work on the same project safely. In GitHub, branches support separate lines of work, so each teammate can make changes without directly affecting the main branch.
A common beginner workflow is:
main when readyThat solves both needs in the scenario: teammates avoid overwriting each other’s work, and the main version stays unchanged until review is complete. Tools like Issues and Discussions help communication, but they do not isolate code changes.
Topic: Understand Git and Github Basics
A new contributor joins a GitHub repository after a workflow file starts failing. They want to review what changed in that file during the last few days, in the order the changes were saved, and see who made each change. Which GitHub feature is most useful?
Options:
A. Read the repository’s issues
B. View the file’s commit history
C. Check the repository’s stars
D. Open the repository’s discussions
Best answer: B
Explanation: Commit history is designed to show how a repository or file changed over time. It gives contributors a timeline of saved snapshots, usually with the author and commit message, so they can trace what was modified and when.
A commit is a saved snapshot of changes in a repository, and commit history is the ordered record of those snapshots. In this scenario, the contributor needs a timeline of edits to a specific file, including who changed it and the sequence of changes. That is exactly what commit history provides on GitHub.
By reviewing commit history, a contributor can:
Issues and discussions may explain why work was planned or talked about, but they do not provide the actual version-by-version record of file changes.
Topic: Understand Git and Github Basics
You and another contributor are updating the same file in a GitHub repository. Your teammate is already revising README.md, and the repository normally uses pull requests before changes reach main. You need to add setup instructions without risking another person’s work. What is the best next step?
Options:
A. Edit the main branch directly and notify your teammate later.
B. Open an issue to describe the setup instructions you want added.
C. Create a branch, commit your changes, and open a pull request.
D. Change the repository visibility to private before editing.
Best answer: C
Explanation: Version control supports collaboration by letting contributors work separately and then combine changes in a controlled way. In GitHub, the usual beginner-friendly next step is to make changes on a branch and use a pull request to review and merge them safely.
The core idea is to avoid making competing edits directly on the shared branch. A branch gives you an independent line of work, so your changes stay separate while someone else is editing the same repository. After committing your updates, a pull request lets the team compare changes, discuss them, and merge them into main in an organized way.
This helps collaboration because it:
main stableAn issue is useful for tracking work, but it does not contain code changes. Changing repository visibility does nothing to prevent one contributor from overwriting another. Directly editing main skips the safer collaboration flow.
main directly increases the chance of conflicting changes and bypasses the normal review process.Topic: Understand Git and Github Basics
A developer updates README.md in a repository branch and saves the work with a short message so the change becomes part of the repository’s history. Which GitHub or Git concept does this action represent?
Options:
A. Opening an issue
B. Creating a commit
C. Assigning a project item
D. Starting a discussion
Best answer: B
Explanation: This scenario describes recording file changes in repository history with a message, which is a commit. Issues, discussions, and project assignments track or organize work, but they do not save code or file changes into Git history.
A commit is the basic Git concept for saving a snapshot of changes to a repository’s history. In the scenario, the developer edited a file, added a short message, and wanted that update recorded in the branch history. That is exactly what a commit does.
Issues are for tracking tasks, bugs, or requests. Discussions are for open-ended conversations. Assigning a project item is for organizing work in GitHub Projects. Those features help teams communicate and plan, but they do not store the actual file changes as part of Git history.
The key clue is that the change is being saved into the repository history, not just tracked for follow-up.
Topic: Understand Git and Github Basics
Mina creates a branch, commits documentation changes, pushes the branch, and opens a pull request into main. Her team follows GitHub Flow and wants both collaboration and quality before changes reach the default branch.
What should happen next?
Options:
A. Request a teammate review the pull request before merging
B. Move the conversation to a discussion and stop using the pull request
C. Close the pull request and commit the changes directly to main
D. Merge the pull request immediately because the branch already has commits
Best answer: A
Explanation: In GitHub Flow, opening a pull request is typically followed by review before merge. That review supports collaboration by inviting feedback and improves quality by catching issues before changes reach main.
The core GitHub Flow idea is to make changes on a branch, open a pull request, review the work, and then merge when it is ready. In this scenario, the team explicitly wants collaboration and quality, so the next step is to have another person review the pull request. Review helps teammates understand the change, ask questions, and suggest fixes before the branch is merged into main.
A simple flow is:
Merging immediately skips the collaboration checkpoint, which is the main reason pull request review is valuable in GitHub Flow.
main.main bypasses the branch and pull request workflow that GitHub Flow relies on.Topic: Understand Git and Github Basics
A new contributor is preparing a pull request that updates onboarding instructions. They want both the README change and the pull request description to be easy to scan with headings, bullet lists, and links on GitHub. What should they do next?
Options:
A. Put the instructions only in commit messages.
B. Start a discussion because pull requests cannot show formatted text.
C. Write the content in Markdown in the file and pull request description.
D. Upload the instructions as a screenshot instead of text.
Best answer: C
Explanation: Markdown is the lightweight format GitHub uses to make text readable in places like README files, issues, and pull requests. When someone needs headings, lists, and links, the right next step is to write the content in Markdown directly in those GitHub text areas or files.
The core concept is that Markdown lets contributors add simple formatting without needing a heavy document format or complex HTML. In this scenario, the contributor wants readable onboarding content in two common GitHub places: repository documentation and a pull request description. Markdown is designed for exactly that use.
Using Markdown allows them to:
This fits beginner GitHub workflows because the same lightweight format is commonly used across README files, issues, and pull requests. The closest distractors move the content somewhere less useful or claim GitHub text fields cannot render readable formatting, which is incorrect.
Topic: Understand Git and Github Basics
Rina fixes broken setup instructions in a repository and updates references from master to main. Another maintainer may read the commit history months later without opening the pull request. Rina wants the history itself to make the change easy to understand. What should she do next?
Options:
A. Create a commit with a clear message describing what changed and why
B. Create the commit with a short message like updates
C. Skip the commit message details and rely on the pull request title
D. Add the reason only to the README and use any commit message
Best answer: A
Explanation: Clear commit context helps future maintainers understand the purpose of a change directly from the history. When someone reviews commits later, a specific message is much more useful than a vague label or information stored somewhere else.
A commit is a saved snapshot of changes, and its message is part of the long-term history of the repository. If the message explains both what changed and why, maintainers can understand the intent quickly without needing to open every file diff or find an old pull request. In this scenario, future reviewers may only look at the commit history, so the best next step is to write a descriptive commit message before continuing the workflow.
Good commit context usually helps by:
A pull request can add more detail, but the commit history should still stand on its own as a useful record.
updates does not tell future maintainers what was changed or why.Use the GitHub Foundations GH-900 Practice Test page for the full IT Mastery route, mixed-topic practice, timed mock exams, explanations, and web/mobile app access.
Try GitHub Foundations GH-900 on Web View GitHub Foundations GH-900 Practice Test
Read the GitHub Foundations GH-900 Cheat Sheet on Tech Exam Lexicon, then return to IT Mastery for timed practice.