Microsoft GH-900: Collaborating Through Git and GitHub Fundamentals

The GH-900 GitHub Foundations exam checks foundational knowledge of Git, repositories, collaboration, projects and basic security administration on GitHub. It is designed for users beyond specialist software developers, including project participants who need to understand how work moves through a repository. Within Microsoft certifications, GH-900 provides the vocabulary for later focus on GH-200 Actions automation, GH-100 enterprise administration or GH-300 Copilot workflows. A learner should not confuse beginner-level understanding with an ability to design enterprise-scale CI/CD or manage every security feature, but fundamentals matter because errors in basic collaboration can create expensive delivery problems.

GitHub is both a code-hosting platform and a place where teams review work, manage discussions and connect changes to tasks. A repository's history allows people to see how a change evolved, but only when contributors use branching and review practices meaningfully. A pull request with no explanatory context or a commit containing generated files and unrelated configuration changes can obscure risk even when every Git command succeeds. GH-900's enduring value is learning to make technical work inspectable, recoverable and collaborative rather than seeing version control as a cloud folder that stores the latest copy of a file.

Distinguish Git concepts from GitHub features

Git is a distributed version-control system with commits, branches and history; GitHub hosts Git repositories and adds collaboration, automation and governance capabilities. Cloning creates a local repository copy; a commit records a snapshot with an author and message; pushing sends local references and objects to a remote. These steps do not inherently prove that code works or that it has been approved. A beginner should practise the difference between local and remote state, especially when a teammate pushes new commits while another person is working. Understanding this distinction prevents many avoidable overwrites and confused merge attempts.

Branches allow teams to develop changes independently from the main line of work. They are not copies that remain entirely unrelated: developers eventually integrate changes through merges, rebases or other controlled approaches. Merge conflicts occur when Git cannot combine differences automatically. Resolving one requires understanding intended behavior, not merely choosing whichever line appears newer. A well-written commit should represent a coherent change with a descriptive message. Reviewing history becomes difficult when dozens of unrelated edits are bundled into one ambiguous commit or a repository frequently rewrites shared history without clear coordination.

Repositories can be public, private or internal under supported enterprise configurations, with visibility affecting who can discover and access content. Forks are useful for proposing changes to projects one does not directly maintain, but their relationship to the original repository differs from a local branch. A fork may have its own permissions and independent history. Contributors should know when to open a pull request from a feature branch and when a fork is more appropriate. Changes to visibility or ownership should be assessed because source code, issues and historical commits can contain information whose exposure matters.

GitHub Releases, tags and package-related features help identify software versions, but a tag alone does not guarantee that an artifact was built from that source or passed tests. The foundational lesson is traceability: which commit corresponds to a release, what changed and how to find the relevant discussion. GH-900 candidates should recognize how a repository's README, contributing guide and license communicate a project's purpose and collaboration expectations. Clear project documentation reduces avoidable misunderstandings for new contributors and provides essential context for maintenance after original authors leave.

Use pull requests as a review and learning process

A pull request makes a proposed change visible for discussion before it is integrated into a target branch. Reviewers can inspect diffs, comment on specific lines and request changes. The description should explain why the change is needed, which behavior it affects and how it was tested. A pull request titled "fix stuff" with fifty unrelated edits forces reviewers to reconstruct intent. Small, coherent changes make defects easier to spot and rollback safer. Even non-code work, such as documentation corrections or project templates, benefits from a review trail where responsibility is visible.

Branch protection and rulesets can require reviews or checks before merging. These controls are not guarantees of correctness: automated checks can miss business-logic defects, and a rushed approval can overlook security issues. They do establish a process that makes some risks harder to bypass accidentally. Beginners should learn how review status, required checks and merge conflicts influence the merge button. If a branch cannot merge, the correct response is to understand the failing condition rather than seek a way to disable protection. This habit provides the foundation for later engineering and platform administration roles.

Issues support discussion of bugs, features and tasks. Useful issues state an observed problem, expected behavior and reproduction steps; a vague demand without context is difficult to act on. Labels, milestones and assignees help organize work, but excessive workflow complexity can make a simple backlog burdensome. GitHub Projects adds planning views and fields that teams can tailor to their process. It is important to distinguish tracking work from implementing work: closing an issue may represent a completed outcome, while a linked pull request describes the code change. The team should know what the status actually means.

Notifications, mentions, discussions and review requests can improve coordination, but they also create noise. Teams need conventions for who should be alerted, who owns triage and when a conversation belongs in an issue rather than a direct message. Repository discussions can be useful for open-ended ideas, while issues suit actionable tasks. A clear communication path helps maintainers discover relevant decisions months later. Beginner GitHub proficiency includes knowing how to find historical context and ask an effective question, not just how to produce activity on the platform.

Recognize security and ownership responsibilities

Access control affects who can read, write, administer or maintain a repository. An organization member's role may differ from permissions on a specific project. Least privilege applies even to small teams: someone who only needs to report a bug does not need repository-owner permissions. Multifactor authentication protects accounts, while token scopes and integrations introduce separate risks. A compromised token can perform operations within its permissions even if the account owner normally signs in securely. Understand the difference between a personal account credential, a GitHub App permission grant and a secret used by a workflow.

Secrets belong in approved credential-management mechanisms, not source files. Accidentally committing an API key is not repaired by deleting the current line; the credential may still exist in commit history or other copies. Rotate exposed keys and investigate their use rather than treating repository cleanup as the complete response. Learn basic security features such as dependency alerts and secret detection, while recognizing that advanced operation belongs to security-focused roles. The fundamentals exam asks candidates to understand safe habits and when to involve an administrator or security team, not to become vulnerability researchers overnight.

Open-source participation involves licenses, codes of conduct and maintainers' contribution guidelines. A public repository is not automatically free of every usage restriction. Before reusing code, check the applicable license and understand the contribution process. An effective first contribution may be a documentation improvement or a reproducible bug report rather than a complex feature. Respectful collaboration includes testing requested changes, responding to review comments and acknowledging when an issue falls outside a project's goals. Governance conventions help maintainers work with diverse contributors without reducing every disagreement to a technical argument.

Basic GitHub Actions familiarity helps explain why commits and pull requests may trigger automated checks. A workflow can run tests, format code or build an artifact, but the presence of a green status is not a universal proof of security or correctness. The idea behind reviewable GitHub and repository delivery is that source changes and release evidence should remain connected. GH-900 candidates need to identify the role of automation and its permissions, while more detailed configuration and runner security appear in specialist exams such as GH-200.

Practise the complete collaboration loop

A useful GH-900 exercise starts with a small repository containing a README and an intentionally incomplete example application. Clone it locally, create a descriptive branch and make one focused improvement. Commit with a meaningful message, push the branch and open a pull request explaining the change. Ask a reviewer to request an adjustment and respond with a new commit. Merge only after reviewing the diff and checks, then inspect the merged history. This sequence clarifies the distinction between files in a working directory, committed history and the collaboration state shown in GitHub.

Next create a mock bug issue with steps to reproduce, assign a label and link the relevant pull request. Explore a Project board to see how the issue appears in a planning workflow. Practise reverting a safe example change so rollback is understood as a normal engineering technique, not a crisis action. Use an intentionally synthetic string to understand why storing a real secret in source would be dangerous, without creating or publishing any genuine credentials. Try changing a repository's access role in a controlled training environment and observe what operations a less privileged user can perform.

Candidates should also learn to read a repository before contributing. Examine its license, contribution instructions, existing issues and release notes. A project with an active main branch, CI checks and clear maintainers has different collaboration expectations from a personal sandbox. Determine which questions to ask before creating new branches or opening issues. Respectful technical communication means describing reproducible evidence and offering a scoped change rather than assuming maintainers share all the context that a newcomer has assembled privately.

GH-900 preparation should use the current GitHub Foundations objectives and practise basic operations in a disposable repository. The important result is fluency in the collaboration lifecycle: branch, change, commit, review, merge and trace release history. That understanding supports developers, analysts, managers and technical writers who work with software teams. It also prepares a learner to recognize when a problem calls for deeper security or automation expertise. GitHub skills become valuable when they make work understandable and recoverable for other people, not when every activity produces more notifications.