GitHub GH-900: Working Confidently with Repositories and Teams

GitHub GH-900, the GitHub Foundations exam, checks whether someone can collaborate effectively in a version-controlled environment. Its January 2026 outline covers Git basics, repositories, pull requests, issues, projects, security, modern development features and the open-source community. This is not a software-engineering exam in disguise. A technical writer, designer or project coordinator may use GitHub every day without writing application code, and still needs to understand what a commit, branch or review actually changes.

The strongest foundation is a mental model of shared work, not memorization of buttons. Git records changes to a repository over time; GitHub adds hosting, collaboration, governance and automation around that history. An accessible interface does not eliminate the need to recognize conflict, permission and review boundaries. The more specialized GitHub Actions and GitHub Enterprise administration build on this vocabulary but apply it to different jobs.

Understand Git history before memorizing commands

A repository contains files and their version history. A commit records a snapshot of changes with metadata connecting it to the history. Branches allow work to move independently, while merges combine relevant changes. A fork creates an independent repository relationship that is often useful for external contributions. These concepts answer different questions: where does a proposed change live, who owns the repository and how does the change become part of the shared line of development?

Imagine a documentation editor correcting API examples while an engineer changes the API itself. Each can work on a branch, but merging the documentation without reviewing the code change could publish inaccurate instructions. Version control preserves an opportunity to inspect and coordinate the two updates. A conflict is not necessarily an error with Git; it is a signal that changes to overlapping content need a human resolution.

Working locally and through the website can produce the same repository history using different interfaces. GitHub Desktop simplifies common operations, while command-line Git offers precise control. New users should practice inspecting a diff and understanding which files will be committed before learning obscure commands. Accidentally committing a private configuration or a generated binary is an organizational problem, not an achievement because the push succeeded.

Choose repository files that make collaboration predictable

A README introduces the project and how to use it. CONTRIBUTING explains how to contribute. A LICENSE states permissions for reuse, while SECURITY provides a supported route for reporting vulnerabilities. CODEOWNERS helps identify responsible reviewers for parts of the codebase. These files have distinct purposes; none is universally mandatory for every private repository, but their absence should be an intentional decision.

A new contributor opening an unfamiliar repository needs to know where to begin, how to reproduce the project and what constitutes an acceptable contribution. A clear README may save dozens of individual support messages. A contribution template can request a reproduction, test evidence and linked issue without forcing the user to guess the team's conventions. Documentation is infrastructure for collaboration; it reduces ambiguity and improves the quality of changes under review.

Repository templates and visibility settings help with organization but should be selected carefully. A public repository is accessible to the wider community, while a private one imposes access restrictions. The decision affects intellectual property, sensitive data and who may see historical commits. Turning a repository private after accidentally committing a secret does not by itself remove all copies or undo exposure.

Use issues and pull requests for different kinds of discussion

An issue records a problem, proposed work or question, usually before the solution is ready. A pull request proposes a specific set of changes and creates a venue for review before merging. Discussions can support broader conversations without treating every idea as an actionable task. Good contributors choose the tool that matches the maturity of the work. A feature suggestion can begin as a discussion, become an issue with acceptance criteria and later be implemented through a pull request.

Consider a request to improve error messages for users in another language. The issue should explain the current problem and desired behavior. The pull request should link the issue, show the altered messages and explain how translations were tested. Reviewers may request changes or suggest a different approach; this is part of collaboration, not a rejection of the contributor. A high-quality review focuses on behavior, accessibility, maintainability and risk rather than personal preference.

Notifications, labels, assignees and milestones help large teams coordinate. They can also generate noise when used without discipline. A label should clarify classification or workflow state; an assignee should signal meaningful responsibility. GitHub Projects can organize cards, views and fields around team priorities, but a project board is only useful when its state reflects the work. The tool does not replace decisions about ownership and deadlines.

Protect access without making every contributor an administrator

Two-factor authentication and passkeys help defend personal accounts. Repository roles determine who may read, contribute, review and administer particular resources. Organizations and teams simplify assigning permissions to groups rather than maintaining a separate list for every repository. A new contributor who only needs to suggest documentation changes should not automatically receive privileges to change organization security policies.

Branch protections or rulesets can require reviews and checks before sensitive changes merge. Teams should understand what these controls accomplish and how they fit with pull requests. A branch rule might prevent direct pushes to the primary branch, but it cannot guarantee that every approved change is logically correct. The quality of human review and tests still matters. Treat governance as several complementary boundaries, not one magic switch.

Security awareness includes understanding that external contributions and downloaded tools may be untrusted. The specialist GH-500 exam goes deeper into secret, dependency and code-scanning risk; GH-900 requires recognizing when those risks warrant careful review and escalation. Review proposed workflows, unexpected binaries and dependency changes with the same care as source edits. Never paste access tokens into public issue threads. If a credential leaks, rotation and investigation are necessary; editing a comment later is not sufficient to remove the exposure.

Recognize where Actions, Copilot and Codespaces fit

GitHub Actions automates work triggered by repository activity or schedules. A workflow might run tests after a pull request and create a release package after approval. GitHub Copilot can suggest code and help explore a problem, but it does not replace a developer's validation. Codespaces provides a cloud-hosted development environment, while github.dev offers lighter browser-based editing. GH-900 asks candidates to identify their purposes and appropriate use, not to administer a complex enterprise rollout.

A contributor fixing a typo may be comfortable using the browser editor and a simple pull request. A developer testing a multi-service change may need a Codespace with configured dependencies. An organization that repeatedly runs builds may invest in reusable Actions workflows. The tools should follow the task. Learning a feature in isolation is less valuable than describing how it improves reproducibility or helps a team collaborate without creating unnecessary risk.

AI features also have practical limitations. A Copilot suggestion may contain an invented API or a subtle security defect, and a description it generates may not match the actual diff. The responsible use of GitHub Copilot deserves deeper attention for teams adopting AI-assisted development. For GH-900, recognize that the human contributor remains responsible for reviewing what enters the repository.

Participate in open source with respect for the project

Open-source projects publish code under licenses that govern use, modification and distribution. 'Visible on GitHub' is not the same as 'permission to use however you like.' Before contributing or reusing code, read the license and contribution policy. A fork and pull request can help offer changes without granting external contributors write access to the primary repository. Maintainers may decline work that does not fit the project's scope even if the code is technically functional.

GitHub Discussions, Wikis, Gists, Pages, Sponsors and Marketplace support different aspects of community activity. A Wiki might host evolving reference material, while Pages can publish project documentation. Sponsors gives some contributors financial support. Marketplace includes applications and tools; installing an unfamiliar integration may grant access to organizational data, so popularity alone does not establish trust.

InnerSource applies open-source collaboration practices within an organization. Teams can expose documentation and shared libraries to other internal groups, use pull requests for contributions and establish clear ownership. It makes existing expertise easier to find without automatically making the organization's source public. The governance lesson remains the same: good collaboration combines discoverability with boundaries.

Practice one complete contribution from idea to merge

Create a small repository for documentation or a sample application. Add a useful README, define a simple issue, create a branch, commit a focused change and open a pull request that links the issue. Ask a second person to review the diff, make a revision and merge according to the repository rules. Then identify what changed in the history and how a future contributor would discover why the decision was made.

Repeat the exercise with a conflict and a permission boundary. What happens when two changes edit the same line? How can an outside contributor suggest an improvement without direct write access? What should someone do after posting a secret by mistake? These cases reveal whether the concepts are understood more reliably than a glossary quiz.

GH-900 builds confidence for everyone who participates in a shared repository. A candidate is ready when they can explain not just how to click a control, but why the resulting action makes collaboration more accountable, reviewable and secure.