GH-900: Learning GitHub Through Real Collaboration

Version control becomes useful when a change made today can be explained, reviewed, and revisited months later. GH-900, GitHub Foundations, examines that collaborative discipline through Git basics, repositories, issues, pull requests, development practices, project organization, privacy, security, and open-source participation. It is designed for a broad audience, including contributors who do not write application code daily. The value of the credential is understanding how people coordinate work safely, not mastering a long collection of terminal commands.

Microsoft's GH-900 study guide was revised for January 2026. GitHub Foundations is a fundamentals-level certification that Microsoft says does not require renewal, unlike many higher-level credentials. The exact examination logistics and feature examples should still be checked with the provider, but the underlying mental model is durable: a repository contains versioned work, a branch isolates a proposed change, and a pull request provides a reviewable path toward integration.

Understand what Git records and what GitHub adds

Git is a distributed version-control system. A local repository contains history and references that allow work to continue even when a hosted service is temporarily unavailable. GitHub is a collaboration and hosting platform built around Git repositories, adding access controls, pull requests, issues, discussions, projects, automation, and community features. Confusing the two leads to errors such as assuming that every Git operation must pass through a GitHub webpage.

Commits capture changes as part of a history and should represent understandable units of work. A branch points to a sequence of commits so an experiment or feature can evolve without immediately changing the default branch. Merging or rebasing integrates histories through different approaches that affect commit structure. A beginner need not memorize advanced internals, but should understand why two contributors editing the same lines can create a conflict that requires a deliberate resolution.

A common workflow begins by creating a branch, changing a file, committing with a useful message, pushing the branch, and opening a pull request. Reviewers can inspect the diff, ask questions, and request changes. The author may push additional commits before the work is merged. The pull request keeps the rationale and discussion near the code or document change, creating evidence that a change was considered rather than merely delivered.

Git history is not a backup strategy for every kind of data. Large generated files, environment-specific secrets, and binary assets may need different handling. A secret committed once can remain in historical revisions even after its latest appearance is removed. The basic lesson is to decide what belongs in the repository, maintain a suitable .gitignore, and follow credential-handling rules before committing.

Create repositories that others can understand and maintain

A useful repository explains why it exists, how to use it, and how to contribute. A README should introduce purpose and setup. A LICENSE file can clarify rights for shared work. CONTRIBUTING describes the contribution process; CODEOWNERS can route reviews; SECURITY explains how to report vulnerabilities. These files are practical coordination mechanisms and should reflect the project rather than a collection of copied boilerplate statements.

Repository visibility is a deliberate choice. Public repositories can support open collaboration but expose code and metadata broadly. Private repositories restrict normal access to authorized users, yet permissions, forks, integrations, and security practices still matter. Teams should understand organization membership and repository roles so that contributors can work without gaining unnecessary administrative control. Private does not mean immune to accidental disclosure or token compromise.

Templates provide a way to start new repositories with common project structure. Forks create a copy used in some contribution models, whereas branches typically support collaboration within the same repository. Choose according to ownership and permissions: an external contributor to an open-source project often works through a fork, while an internal development team may use branches in an organization repository. There is no universal rule that every project should use the same model.

Inspect repository insights and activity before making governance decisions. A quiet repository may be stable rather than abandoned; a popular project may still have unresolved maintenance risks. Stars and activity indicators can help discovery, but they are not guarantees of quality. Review documentation, release practices, ownership, and issue responsiveness when deciding whether to depend on or contribute to a project.

Collaborate through pull requests, issues, and discussions

Pull requests make proposed changes reviewable. A good pull request explains the problem, approach, testing evidence, and user-visible impact. It should be small enough for meaningful review when possible. A reviewer should examine functionality, security, tests, and maintainability rather than clicking approve solely because automated checks are green. The conversation is part of the record, especially when a design decision might not be obvious from the final diff.

Issues track bugs, enhancements, and other work that needs attention. Labels, assignees, milestones, and templates help organize the queue, but categories become useful only when maintained consistently. A bug report should include expected behavior, observed behavior, and a reproducible example. A request for enhancement benefits from explaining the user problem before prescribing an implementation. Good triage reduces confusion and avoids duplicate work.

Discussions serve broader questions, ideas, and community exchange, while issues are often better for actionable tasks. Projects can provide custom views, fields, and status tracking across work. Do not let a board's column position substitute for evidence that a change has been implemented and tested. The tool is a way to coordinate work, not proof of delivery or business value.

Notification management matters as repositories grow. Watching every repository and thread may generate so much noise that important reviews are overlooked. Set participation and notification preferences to match responsibility, and use mentions deliberately. In a mature workflow, a pull request review request has a clear expected owner; a discussion is not treated as an urgent production alert unless the team has explicitly defined that convention.

Recognize modern development tools without mistaking them for prerequisites

GitHub offers more than repository hosting. Actions can automate tests and deployments, Codespaces provides cloud development environments, and GitHub Copilot offers AI assistance. Foundations candidates should recognize what these tools do and when they help, without assuming that familiarity with them makes someone an automation engineer or an AI specialist. Those responsibilities have deeper technical and security requirements.

For example, a repository might run unit tests whenever a pull request is opened. A contributor needs to understand what a red status check means and where results appear, not necessarily how to design a complex reusable workflow. GitHub Actions covers the implementation discipline in more depth. Similarly, knowing that Copilot can suggest code is different from evaluating its data protections, prompt context, and agent behavior.

A basic Git workflow for collaboration explains branching, review, and change history as concepts even when the underlying project manages network automation rather than a website. The transferable lesson is that version control helps teams reason about who changed what and why. An approved process should not be bypassed simply because an automated tool can modify many files quickly.

Candidates should also understand Markdown for useful documentation, code review comments, and issue descriptions. A concise reproduction recipe or a clear table in a README often improves collaboration more than a complicated project board. Tool proficiency should support communication rather than bury it beneath interface conventions that only experienced users recognize.

Apply access, security, and privacy fundamentals

Basic repository security begins with authentication and permission management. Multi-factor authentication, access tokens, appropriate repository roles, and attention to external collaborators all matter. Do not share personal tokens in messages or commit them as configuration. A developer may be able to create a repository while lacking permission to change organization-level policies; that separation is intentional and protects shared environments.

A common risk scenario is a credential mistakenly included in a public commit. Deleting the visible line is insufficient because the credential may remain in history. Alert the owner, revoke or rotate the key, and investigate exposure according to the organization's process. GitHub provides security features that can help detect certain secrets and vulnerable dependencies, but those tools supplement rather than replace safe development habits.

A protected pull request workflow illustrates why approval and automated checks can provide meaningful safeguards. Protection should not be confused with a guarantee of correctness: a merged pull request can still contain a bug. Its value is creating a consistent opportunity to review risk and test changes before they become part of a shared branch.

Privacy applies to profiles, repository visibility, issue content, discussions, and automation output. Do not paste customer data into a public issue to demonstrate a defect. Create a synthetic example that preserves the technical behavior. Understand that an organization may impose stricter rules than a personal repository, and consult the appropriate owners before changing access or exposing artifacts.

Participate responsibly in open-source communities

Open-source collaboration often involves discovering projects, reading contribution instructions, reporting defects, proposing changes, and respecting maintainers' time. A good first contribution may improve documentation or add a reproducible test rather than introduce a large feature. Review the project's license, expected conduct, and issue process. Opening a large unsolicited pull request without understanding the project's direction can create more work than value.

A fork-based contribution flow lets an external contributor propose changes without direct write permission to the upstream project. The maintainer may request revisions or decline the proposal for scope reasons. This is normal collaboration rather than a judgment on the contributor's worth. Clear issue discussion and modest, testable changes improve the chance that work can be reviewed and maintained.

InnerSource applies similar collaboration principles inside an organization. Teams can share reusable components, publish clear contribution instructions, and maintain ownership boundaries even when repositories are private. The same practices that help open-source work—readable documentation, transparent review, traceable decisions—also help large enterprises reduce duplicated development efforts.

Community features such as stars, follows, and project discussions aid discovery, but they should be used critically. Popularity does not guarantee long-term maintenance or security. New contributors should evaluate documentation, release activity, license terms, and available support channels before depending on a project in a production application.

Practice GH-900 by contributing to a small fictional project

Create a repository for a simple documentation site or sample application. Write a useful README and contribution instructions. Open an issue describing a missing feature, create a branch, make a small change, commit it, and open a pull request. Review the diff with a second account or collaborator if available, and practice responding to feedback before merging.

Next, create a conflicting change on another branch and resolve it deliberately. Inspect commit history to explain how the final state was produced. Configure a basic status check and see what happens when it fails. Explore project boards, notifications, and issue labels without creating unnecessary fields simply because the platform supports them. Focus on whether another person could follow the work without verbal explanation.

Finally, perform a permission exercise: identify which users may read, write, administer, and merge in the repository, and consider what changes when the project moves into an organization. Review why GH-100 enterprise administration is a separate discipline. A beginner should understand the boundary and know when to seek administrator help rather than granting broad access to solve a short-term problem.

GitHub Foundations rewards coherent understanding of collaboration. Successful preparation leaves a learner able to explain version history, propose changes safely, communicate through issues and pull requests, protect repository information, and engage respectfully with other contributors. Those habits underpin far more specialized GitHub work, even when the tools and product interface continue to evolve.