GitHub GH-900: Collaboration Beyond the Commit

A designer fixes a typo in a website repository while a developer changes the navigation. Both edits are correct, but one person uploads an old copy of the entire project and accidentally removes the other’s work. Version control exists to avoid precisely that kind of loss, and GitHub supplies the collaboration layer that helps teams review, discuss and integrate changes.

GitHub GH-900, GitHub Foundations, assesses Git basics, repositories, collaboration, modern development practices, project tracking, security and the GitHub community. Its January 2026 objectives are not limited to command-line experts. The GitHub GH-900 practice test page should be used while working with an actual repository so the differences among commits, branches, issues and pull requests become concrete.

A commit is a recorded change, not a backup strategy

Git tracks changes across a repository’s history, allowing contributors to understand what changed and to recover from mistakes. A commit represents a snapshot of tracked content with associated metadata. A branch provides a movable line of development where work can proceed without immediately changing the default branch. GitHub hosts repositories and adds permissions, collaboration features and automation around that history; Git and GitHub are related but not interchangeable terms.

Create a small Markdown project, commit one change and inspect the diff. Then create a branch, edit the same paragraph on another branch and attempt to combine the work. When a conflict appears, examine what each version means instead of accepting a conflict-resolution button blindly. Understand the difference between fetching remote updates and merging them into a local line of work. These skills explain why source history helps collaboration without eliminating the need for judgment.

Pull requests make proposed work inspectable

An issue describes a problem, request or discussion; a pull request proposes a change to a repository. Linking the two creates useful traceability but does not make them the same object. Good pull requests explain the intent, affected files, tests and risks. Reviewers can comment on the diff, request revisions or approve it under repository policy. A green status check is evidence that selected automation succeeded, not proof that every requirement was met. When a proposed change moves from pull request to automated checks, GitHub GH-200 workflow automation explains how workflow triggers and artifacts affect the result.

Practise opening a pull request for a small documentation fix. Reference the issue, ask for review and resolve feedback through another commit. Inspect how the proposed diff changes before merging. Use a code owners file or review requirement in a controlled sample to see how repository governance affects who should approve changes. Record which conversations belong in the issue and which belong next to a particular line of changed code.

Repository files communicate how to collaborate

A README explains the project; CONTRIBUTING documents how work should be proposed; LICENSE sets legal conditions for reuse; SECURITY tells people how to report vulnerabilities. These files serve different purposes, and a repository may require only some of them depending on its audience. Templates can standardize issues and pull requests, reducing missing context. Discoverability through tags, topics and documentation helps people find the correct repository before creating duplicate projects.

Choose a real-looking open-source example and evaluate its onboarding experience. Could a newcomer run tests, find ownership information and report a defect without guessing? Examine the difference between a fork, which creates another copy of a repository under separate ownership, and a branch within the same repository. Fork-based contributions are common in public projects but involve permissions and trust constraints that should not be overlooked.

Projects organize work beyond a list of issues

GitHub Projects can help track tasks through different views and fields, while milestones, labels and assignees provide organization inside repositories. Use these features to make workflow visible rather than to generate busywork. A task’s status should reflect a real decision or completion criterion. Discussions are useful for open-ended conversations that are not yet concrete defects or code changes; notifications help participants follow relevant updates.

Build a simple board for a release with a documentation task, a defect and an accessibility improvement. Connect each to an issue and attach pull requests where code changes exist. Then explain how a stakeholder can distinguish pending work, active review and completed work. The exam emphasizes recognizing each collaboration feature’s purpose, not memorizing the location of every interface control.

Privacy and automation need basic literacy

Public, private and organization repositories differ in who can view and contribute. Two-factor authentication, repository roles and protected branches help limit unauthorized changes. GitHub Actions can run tests or deployments, while Codespaces provides development environments and Copilot can assist with code generation. Each feature addresses a different need and adds configuration choices; candidates should understand the broad distinction before advancing into specialist certifications.

For GH-900 practice, follow one change from idea to merge: raise an issue, create a branch, commit a revision, open a pull request, run a status check and review the result. Explain the visibility and permission settings that protect each step. A foundation is useful when it lets a contributor participate confidently without accidentally sharing a secret, overriding another person’s work or mistaking an automated check for human approval.