GitHub GH-900: Foundations of Git and Collaboration

GH-900, GitHub Foundations, is aimed at people who need to collaborate confidently with Git and GitHub, including developers, project managers and technical contributors. Microsoft's January 2026 exam update covers Git concepts, repositories, pull requests, modern development practices, project tools, security and open-source communities. The credential is foundational, and Microsoft's certification page states that GitHub Foundations does not require renewal. The most effective learning begins with practical repository work rather than memorizing the names of menu items.

Version control records how a project changes and who proposed each change. Git manages commits, branches and history locally, while GitHub adds hosted collaboration, review, issues and security features. The distinction becomes obvious when a developer makes a commit without an internet connection: the commit exists in the local repository even though no remote branch has been updated. Understanding that separation prevents common mistakes when pushing, pulling, merging or restoring work.

Understand commits, branches and remotes

A Git commit captures a snapshot of tracked changes with metadata and a parent relationship in the history graph. The staging area allows a contributor to select which changes belong in the next commit. A branch is a movable reference to a commit, not an isolated copy of the entire codebase. A remote such as origin identifies a repository location whose branches may be fetched or updated. These concepts explain why a local branch may diverge from its remote counterpart and why a pull can require a merge or rebase.

Suppose an engineer fixes a typo while another contributor changes the same documentation section. Both commits may be valid, but combining them can create a conflict. The conflict is not necessarily an error; it is Git asking for a human decision about the intended final content. Review both sides, resolve the document, run suitable checks and commit the result. Avoid treating conflict markers as text to delete automatically without understanding what each contributor intended.

Commit messages should describe a coherent change. A single commit mixing a dependency upgrade, a security policy change and unrelated formatting makes review and rollback harder. Keeping commits focused helps teams bisect a regression and identify the change that introduced it. Rewriting published history can disrupt collaborators, so use it deliberately and understand the difference between amending a local commit and changing a branch already shared with others.

Use pull requests for decisions, not just code transfer

A pull request proposes integrating a branch into a target branch. Reviewers can inspect the diff, discuss changes, request revisions and see status checks. Merge strategies differ in how they represent history, but all should preserve a traceable decision. A good description states what problem is solved, how it was tested and what operational risk remains. Even documentation changes benefit from clear context, especially when they update a procedure people follow during incidents.

Code review is a technical conversation rather than an approval ritual. A reviewer should inspect behavior, dependencies, maintainability and risk; the author should respond to concerns with evidence. For example, a new access-control check might pass a basic unit test but fail when the user belongs to multiple teams. Ask for an edge-case test before approving. Status checks are useful, but a green check does not replace understanding the business requirement.

Branch protection or repository rulesets can require approvals, prevent force pushes and insist on certain checks. The policy has to reflect the repository's importance and contribution model. Open-source projects may accept many external pull requests with limited permissions; internal release repositories often enforce stricter review paths. GH-900 candidates need to recognize why the controls exist, even though GH-100 explores enterprise administration in far more depth.

Keep issues and projects connected to delivered work

Issues can track bugs, tasks, ideas and discussions. Labels, milestones, assignees and templates help organize work, but they should express a real workflow rather than become administrative clutter. A bug report needs a reproduction, expected behavior, actual behavior and relevant environment details. A feature proposal benefits from acceptance criteria and a clear reason for the change. Link pull requests to the issues they address so reviewers and future maintainers can trace why a decision was made.

GitHub Projects can organize work across views and fields, helping teams see status and dependencies. A project board with dozens of ambiguous labels creates the illusion of control while hiding blocked work. Keep statuses understandable and ensure that important updates are reflected in the actual issues and pull requests. For distributed teams, written review history is often more valuable than a meeting remembered differently by each attendee.

A volunteer project might accept a bug report from someone who does not write code. Providing respectful issue templates and contribution instructions makes it possible for that person to participate without learning every Git command. Good collaboration includes documentation and moderation, not just merging successful pull requests. This is one reason GitHub Foundations applies to nondevelopers as well as programmers.

Understand security and open-source responsibilities

Public repositories can expose secrets, customer information or internal URLs if contributors are careless. Files committed to a repository can remain in Git history even after they are deleted in a later commit. Treat accidental credential exposure as an incident: revoke the secret, assess its use, and remove or restrict affected content through the proper response process. Repository visibility and permissions determine who can read and write, but the platform also offers scanning and alerting features whose scope should be understood.

Open-source licenses describe conditions for reuse, modification and distribution. A public repository is not necessarily public domain; read its license before borrowing significant content or adding a dependency. A contributor should also understand project codes of conduct, maintainers' responsibilities and respectful issue discussions. Forks allow independent development and contribution, while templates help start a new project without implying an ongoing history relationship.

Organizations use InnerSource to apply open-source collaboration practices across internal teams. The benefits can include clearer ownership, reusable components and better documentation, but sensitive repositories still need intentional access controls. Broad visibility is a policy choice, not an automatic entitlement. Discuss intellectual property, customer obligations and security before moving private code into a publicly discoverable area.

See how automation fits into everyday collaboration

GitHub Actions can run tests, builds and other tasks after events such as a push or pull request. At the foundational level, recognize the purpose of a workflow, job, runner and artifact. A status check might test a project against several runtime versions, while a deployment requires stronger permissions and approval. Automation is useful only when users understand what the result means. A skipped workflow does not prove the code passed tests; it may mean its trigger filters did not match.

A GitHub release, tag and package are related but distinct concepts. A tag identifies a revision; a release can publish notes and assets; packages distribute build outputs according to registry rules. Verify what artifact users will receive and whether it corresponds to the tested commit. More advanced GH-200 work covers authoring and securing the underlying Actions workflows. GH-900 simply builds the vocabulary to participate responsibly.

When a build fails, read the job logs, identify the failing command and reproduce in a suitable local environment. Avoid pushing random code changes just to make the status green. If a failure depends on an unavailable external service, record the distinction between an infrastructure problem and a code defect. Strong team habits use these incidents to improve diagnostics and reduce uncertainty.

A practical branching failure illustrates the value of understanding Git history. A contributor accidentally commits a generated file containing credentials and later removes it in a second commit. The current working tree is clean, but the secret may remain accessible in history and clones. Revoke the credential immediately and follow the project's incident process; do not assume that an ordinary deletion rewrites history everywhere. Git records changes intentionally, which is valuable for accountability but makes accidental disclosure harder to reverse.

Release documentation is another strong exercise. Create a tag for a tested commit, attach a release note describing fixes and verify which artifact users will download. Now amend a documentation file on the main branch and observe that the old tag still references the original revision. A release should remain reproducible even as the project evolves. This distinction helps contributors understand why source branches, tags, releases and package versions serve different purposes.

For collaborative teams, rehearse an issue escalation. A reporter submits a bug without a reproduction, the maintainer requests details, and another contributor proposes a fix. Record expected behavior, link the pull request, review tests and close the issue only when the agreed condition is met. This lifecycle teaches respectful collaboration and traceable decision-making. GitHub Foundations is not merely a set of commands; it is a way to make work understandable to people who were not present when the change was made.

Practice with a real contribution cycle

Create a repository containing a short document and a small application, clone it locally, create two branches and make independent changes. Open a pull request, invite review and intentionally introduce a conflict to resolve. Add an issue whose acceptance criteria lead to another pull request, then link the change to the issue. Experiment with repository visibility in a safe test organization and observe which actions a reader, contributor and administrator can perform.

Explore a public project by reading its license, contribution guidelines and issue history before proposing a small improvement. Use Microsoft's GH-900 objectives as the coverage checklist. The most valuable skill is understanding how a change moves from an idea to a reviewed, traceable contribution and why permissions, communication and history matter along the way.