GH-900: GitHub Foundations for Modern Collaboration

GH-900, GitHub Foundations, validates an understanding of version control, repositories, collaboration, project management, security, and the GitHub community. The January 2026 objectives include Git basics, working with repositories, pull-request workflows, development practices, project organization, access and privacy concepts, and open-source engagement. The credential is designed for developers and non-developers alike, so its purpose is to establish a dependable mental model rather than test advanced CI/CD engineering. A GitHub contributor should understand where a change lives, how others review it, what happens when work conflicts, and why access rules and repository visibility matter. These practices apply to documentation, data configuration, and other collaborative work as well as software code.

Understand Git history before using a graphical interface

Git is a distributed version-control system that records snapshots and relationships between commits. GitHub hosts repositories and layers collaboration, reviews, access controls, and other services on top of Git. A repository contains versioned content and metadata; a clone gives a local copy with its own history, and a branch points to a line of development. A commit represents a recorded change with associated identity and message information, not necessarily a released product version. The distinction matters when troubleshooting: a commit can exist locally without being pushed, and a remote branch can change without an old local checkout reflecting it automatically.

A contributor should know the purposes of clone, status, add, commit, fetch, pull, and push, along with basic diff and log inspection. The most important habit is checking exactly which changes are staged and where they will be published. Git's staging area lets a contributor separate related updates instead of accidentally committing an unrelated secret or temporary file. Git and GitHub commands offer practical context, but foundational competence means being able to explain what a command changes in the working directory, local history, and remote repository.

Manage branches and resolve collaboration conflicts

Branches let contributors develop changes without directly editing a shared protected branch. A pull request proposes merging work and provides a place for review, automated checks, and discussion. A merge conflict occurs when Git cannot automatically reconcile certain changes; resolving it requires understanding the intended final content, not just selecting “ours” or “theirs” without reading. Teams should use branch names and commit messages that help reviewers understand purpose. Extremely large pull requests can hide defects and create slow feedback; small, coherent changes are easier to test and discuss. Branches are coordination tools, not complete security boundaries.

Review decisions should be documented in context. A reviewer may request changes, approve a contribution, or leave comments without approval, depending on repository policy. An approval proves a human reviewed a proposed change under defined conditions; it is not a guarantee that the software contains no defect. Status checks can reinforce testing, but a failing check should be investigated rather than bypassed reflexively. Protected branch rules and rulesets help prevent unauthorized direct pushes or merges that fail required checks. For a non-developer, this workflow may apply equally to a technical manual, website content, or infrastructure policy maintained in version control.

Distinguish issues, discussions, and project planning

Issues can track defects, features, improvements, or other work items. Labels, assignees, milestones, and relationships help a team organize progress, but each field has value only when it is maintained consistently. A project board provides a view of work across defined stages and can support custom fields and automation. Discussions are often better for open-ended questions, community proposals, or knowledge sharing that has not yet become a bounded task. A contributor should understand which space fits a particular activity rather than treating every communication as an issue with a due date.

Project hygiene depends on clear acceptance criteria and ownership. An issue titled “fix website” provides little context, while one describing the user impact, expected behavior, reproduction steps, and validation method makes collaboration more effective. Closing an issue should reflect an agreed outcome, not merely that a branch was merged. A project view is useful when it reveals blockers and priorities, but a dashboard that nobody updates quickly loses value. GH-900 asks users to navigate and describe these collaboration mechanisms, not to design an elaborate management framework for a small team.

Recognize repository structure and documentation practices

A README explains purpose and entry points, while contribution guidance, issue templates, pull-request templates, and codes of conduct help establish consistent behavior. A license governs permitted use and distribution of code; making a repository public does not automatically grant every reuse right. A security policy can describe how researchers report vulnerabilities without publishing sensitive exploits through ordinary issues. Repositories may also use releases, tags, project documentation, and automated checks to explain the state of a project. A newcomer should know where to find these signals before opening a contribution or relying on a library.

Forking creates an independent copy under another account or organization in supported contexts, useful for certain open-source contribution models. A repository template offers a different starting mechanism: it creates a new project based on a scaffold without preserving the same contribution relationship. Cloning makes a local working copy. These concepts sound similar but lead to different collaboration and history expectations. InnerSource applies selected open-source practices within an organization, promoting discoverability and contributions while maintaining internal access controls. The right model depends on ownership, review requirements, and the intended relationship between projects.

Understand authentication, authorization, and visibility

Public, private, and internal repository visibility models affect who can discover and access content under the applicable account and enterprise setup. Visibility should be selected according to data classification and collaboration needs; hiding a repository is not a substitute for reviewing which users and apps have access. Two-factor authentication protects interactive accounts, but personal access tokens, SSH keys, and installed applications create additional access paths. A contributor should use the supported authentication mechanism, avoid committing secrets, and understand how to revoke credentials that are lost or no longer needed.

Organization and repository roles define capabilities that differ from a user's identity. Being a member of an organization does not always mean a person may administer every repository. Branch protection can limit writes to sensitive branches even when a contributor may propose changes elsewhere. New users should inspect access requirements before copying private content into issues, gists, or external tools. The foundations exam does not demand the detailed enterprise architecture of GH-100, but it does expect a basic understanding that platform collaboration operates inside permission and policy boundaries.

Interpret GitHub Actions and modern development concepts

GitHub Actions can execute automation in response to events such as pushes and pull requests. At the foundations level, users should recognize a workflow, job, step, runner, and status check without needing to author sophisticated custom actions. Automated testing provides timely feedback, while continuous integration encourages frequent verification of shared work. Continuous delivery and deployment relate to producing and releasing software through controlled steps, but a passing build is not automatically an approved production release. These concepts help non-specialists understand why a pull request may be blocked until checks complete or a deployment needs additional approval.

Security and responsible software development also touch dependencies, code review, and vulnerability disclosure. A repository can expose a bad secret even if no source-code vulnerability exists, and a third-party dependency can contain flaws not created by the project team. Strong practices involve reviewing updates, restricting credentials, and responding to security alerts appropriately. GitHub Actions and Azure Pipelines give context for broader automation choices, but GH-900 remains concerned with recognizing the collaboration model rather than solving enterprise delivery architecture problems.

Participate responsibly in the GitHub community

Open-source collaboration involves more than submitting code. Contributors may improve documentation, report reproducible bugs, answer questions, or help maintain translations. Before opening a pull request, read the project's contribution instructions and license and check whether an existing issue already covers the change. Respect maintainers' review capacity and avoid flooding repositories with untested or low-context changes. Security-sensitive issues should follow the documented private reporting channel when available. A useful issue report explains environment, expected behavior, observed result, and minimal reproduction without exposing personal or confidential data.

A practical GH-900 exercise is to create a small documentation repository, open an issue for a correction, make a focused branch, commit the change, and propose it through a pull request. Ask a teammate to review, resolve a deliberate merge conflict, and inspect the final history and automated checks. Then adjust repository visibility in a safe test environment and observe how access differs for collaborators. This journey links Git concepts, reviews, projects, and permissions into one comprehensible workflow. It demonstrates the purpose of GitHub Foundations: making work traceable, reviewable, and collaborative without needing advanced systems-administration expertise.

Another foundational distinction is the relationship between a release and a branch. A release commonly identifies a version intended for users, often associated with a tag and published notes or artifacts. A branch may contain ongoing work that is not ready for distribution. If a contributor reports a defect in a named release, a maintainer should be able to locate the corresponding revision and distinguish it from changes that landed afterward. This traceability supports debugging, communication, and safe patch preparation. It also explains why simply sharing the URL of a default branch may be inadequate when colleagues need to reproduce a historic result.

For teamwork, notification habits matter as well. Watching a repository, subscribing to an issue, and being mentioned in a discussion lead to different kinds of awareness. Excessive notifications can make important review requests easy to miss, while complete silence can leave a pull request blocked for days. Participants should use descriptive titles, timely status updates, and respectful comments that focus on observable behavior. GH-900 is not a communications exam, but the collaboration tools are effective only when contributors use them intentionally and understand the social expectations surrounding changes to shared work.