GitHub Foundations: den Ort zertifizieren, an dem unsere Software tatsächlich entsteht

Im Juni 2025 habe ich die GitHub-Foundations-Prüfung (GH-900) abgelegt und bestanden. Ich führe einen Microsoft-Stack-Laden in Ibbenbüren, und so nehmen manche an, dass alle meine Zertifikate ein Microsoft-Logo tragen. Dieses hier ist ein wenig anders – es ist GitHubs eigenes Einsteiger-Zertifikat – und ich finde es lohnt zu erklären, warum ich es gemacht habe, denn die Begründung sagt etwas darüber aus, wie moderne Software wirklich entsteht.

Ich schreibe lange genug beruflich Software, um mich an Versionskontrolle zu erinnern, bevor sie gut war. Das sage ich nicht, um angegraut zu klingen – ich sage es, weil es einordnet, warum GitHub mir etwas bedeutet. Die Plattform ist kein nettes Extra über der Arbeit; für die meisten Teams, auch unseres, ist sie der Ort, an dem die Arbeit lebt. Mein Verständnis davon zu zertifizieren fühlte sich weniger nach Abzeichen-Sammeln an als nach dem Anerkennen des Bodens, auf dem ich jeden Tag stehe.

Was GitHub Foundations ist

GitHub Foundations ist das Einsteiger-Zertifikat in GitHubs Zertifizierungsprogramm. Dieses Programm gehört GitHub selbst – es steht neben, ist aber getrennt von den rollenbasierten und Fundamentals-Zertifikaten von Microsoft, die ich besitze. (GitHub ist eine Microsoft-Tochter, und die Prüfung wird über die Microsoft-Learn-Zertifizierungsplattform als GH-900 ausgeliefert – daher kommt ein Teil der Überschneidung –, aber das Zertifikat ist eindeutig ein GitHub-Zertifikat.)

Es ist als Einsteiger-Credential auf Grundlagenniveau positioniert. Das offizielle Zielgruppenprofil ist erfrischend breit: Kandidaten „sollten grundlegendes Wissen über GitHub und seine Kernfunktionen haben", und die Prüfung ist „für Nicht-Entwickler, Entwickler und alle GitHub-Nutzer konzipiert, die ihre Kompetenz in den GitHub-Grundlagen verbessern wollen". Dieser letzte Teil ist wichtiger, als er aussieht. GitHub hat schon vor Jahren aufgehört, ein reines Entwicklerwerkzeug zu sein. Product Manager verfolgen darin ihre Arbeit, technische Redakteurinnen liefern Dokumentation daraus aus, Designer reviewen Pull Requests darin. Ein Grundlagen-Zertifikat, das ausdrücklich auch Nicht-Entwickler einschließt, ist GitHubs Anerkennung der eigenen Schwerkraft.

Die Prüfung ist beaufsichtigt (proctored) und wird über Pearson VUE gebucht, mit beiden Optionen: Präsenz im Testzentrum oder online beaufsichtigt. Sie wird in mehreren Sprachen angeboten – Englisch, Spanisch, brasilianisches Portugiesisch, Koreanisch und Japanisch –, und nach bestandener Prüfung ist das Zertifikat zwei Jahre gültig.

Was es tatsächlich zertifiziert

Bei diesem Teil möchte ich präzise sein, denn „GitHub-Zertifikat" könnte fast alles heißen, und die Realität ist konkret. Die Prüfung misst sieben Kompetenzbereiche mit den Gewichtungen, die GitHub im GH-900-Studienleitfaden veröffentlicht hat:

• Git- und GitHub-Grundlagen verstehen (25–30 %) – mit Abstand der größte Bereich. Grundlagen der Versionskontrolle, der Unterschied zwischen Git und GitHub, Kernkonzepte wie Repositories, Commits und Branches, dazu GitHub-Accounts, Organisationen, Enterprise-Optionen, GitHub Flow und Markdown.
• Mit GitHub-Repositories arbeiten (10–15 %) – Repository-Struktur und die Schlüsseldateien (README, LICENSE, CONTRIBUTING, CODEOWNERS, SECURITY), Repositories anlegen und organisieren, Dateien verwalten und Repository-Insights lesen.
• Mit GitHub zusammenarbeiten (10–15 %) – Issues, Pull Requests, Discussions, PRs mit Issues verknüpfen, Templates, Benachrichtigungen sowie der Einsatz von Gists, Wikis und GitHub Pages.
• Moderne Entwicklungspraktiken anwenden (10–15 %) – und hier hört es auf, eine reine „Git-Prüfung" zu sein. Der Bereich deckt ausdrücklich den Zweck von GitHub Actions ab, wie GitHub Copilot mit KI-gestützten Vorschlägen unterstützt (inklusive Copilot-Agenten, Agent Mode und Multi-Model-Unterstützung), den Unterschied zwischen Copilot für Individuals, Business und Enterprise sowie Codespaces und Dev Containers.
• Projekte mit GitHub verwalten (5–10 %) – GitHub Projects, Labels, Milestones, Workflows und Projekt-Insights.
• Datenschutz, Sicherheit und Administration verstehen (10–15 %) – Zwei-Faktor-Authentifizierung und Passkeys, Zugriffsberechtigungen und Rollen, Enterprise Managed Users, Repository-Sichtbarkeit und Branch-Protection-Regeln.
• Die GitHub-Community erkunden (5–10 %) – die Vorteile von Open Source, GitHub Sponsors, der Marketplace und wie InnerSource Open-Source-Prinzipien innerhalb einer Organisation anwendet.

Zum Format: Die Prüfung ist Multiple Choice, man hat 100 Minuten Zeit, und zum Bestehen ist ein Ergebnis von 700 (auf der Standardskala) oder mehr nötig. Es gibt eine öffentliche Sandbox, in der man die Fragetypen vorab erleben kann – eine Kleinigkeit, die ich schätze, denn Überraschungen am Prüfungstag kommen selten aus dem Inhalt.

Was ich an diesem Prüfungsplan gut abgewogen finde, ist die Balance. Ein Viertel des Gewichts liegt auf echten Grundlagen – Dingen, die man nicht vortäuschen kann –, und der Rest verteilt sich auf die Teile von GitHub, die leise unverzichtbar geworden sind: Automatisierung, KI-Unterstützung, Sicherheit und die soziale Mechanik von Open Source und InnerSource. Es ist eine ehrliche Landkarte dessen, was GitHub 2025 ist, nicht ein nostalgischer Schnappschuss dessen, was es war.

Warum ich es zertifiziert habe

Ich bin ehrlich: Das meiste davon wusste ich bereits. Ich nutze GitHub jeden Arbeitstag, seit Jahren. Warum also eine Einsteiger-Prüfung ablegen?

Drei Gründe, und keiner davon ist Eitelkeit.

Erstens: GitHub ist das Rückgrat, über das wir ausliefern. Jedes Projekt, das wir bei ThreeBIT betreiben, lebt auf GitHub. Nicht „wird dorthin gesichert" – es lebt dort. Das Repository ist die Quelle der Wahrheit, im Pull Request werden Entscheidungen getroffen und festgehalten, und die Actions-Pipeline ist das, was aus einem gemergten Commit etwas Laufendes in Azure macht. Wenn ein Werkzeug so zentral ist, ist „ich kenne es im Grunde" nicht dasselbe wie „ich habe verifiziert, dass ich es richtig verstehe, auch die Teile, die ich seltener nutze". Die Zertifizierung zwang mich, das Handbuch zu den Ecken zu lesen, um die ich herum improvisiert hatte – Branch-Protection-Regeln, die ich nach Gefühl konfiguriert hatte, die genauen Unterschiede zwischen Copilots Lizenzstufen, die Sicherheitsfunktionen, die ich halb aktiviert hatte. Eine Prüfung abzulegen ist ein günstiger, strukturierter Weg, diese Lücken zu schließen.

Zweitens: Copilot- und Actions-Kompetenz gehört jetzt zum Job, nicht zum Extra. Ich schreibe viel, hier und anderswo, darüber, dass KI-gestützte Entwicklung real ist und nicht Hype. Es wäre ein schlechtes Bild, das zu vertreten und dann vage zu sein, wie die Werkzeuge, auf die ich mich stütze, tatsächlich lizenziert, gesteuert und betrieben werden. Der GitHub-Foundations-Plan behandelt Copilot und Actions als Kernwissen, und ich finde das richtig. Wenn man KI-Agenten und CI/CD ins Zentrum stellt, wie ein Unternehmen baut – so wie wir es getan haben –, sollte man sie präzise erklären können, auch dem Sicherheitsteam eines Kunden.

Drittens, und leiser: Es ist ein faires Credential, das ich von meinem eigenen Team verlangen kann. Ich verlange ungern Dinge von Menschen, die ich nicht selbst getan habe. Wenn ich GitHub-Sicherheit für eine vernünftige Grundlinie für jemanden halte, der zu ThreeBIT kommt, ist das Mindeste, dass ich dieselbe Grundlinie selbst halte, mit demselben Nachweis. Ein Gründer, der „zu senior für die Zertifizierung der Grundlagen" ist, ist meist ein Gründer, der sich von der Arbeit entfernt hat.

Wie es sich in unserer Arbeit bei ThreeBIT zeigt

Nichts davon hätte Gewicht, wäre es abstrakt, also hier die konkrete Fassung – die GitHub-Foundations-Bereiche, abgebildet auf eine normale Woche bei ThreeBIT.

Jedes Projekt lebt auf GitHub. Xircuit, Outastory, diese Website, unser internes Tooling – jedes ist ein Repository, mit Branch-Protection auf dem Default-Branch und einer CODEOWNERS-Datei, die Reviews an die richtige Person leitet. Der Bereich „Repository-Struktur und Schlüsseldateien" ist für uns keine Trivia; die README-, LICENSE-, CONTRIBUTING- und SECURITY-Datei ist das Erste, was eine neue Mitwirkende oder ein neugieriger Kunde liest.

Pull Requests sind, wie Entscheidungen getroffen werden. Wir pushen nicht auf main. Arbeit passiert auf einem Feature-Branch, öffnet einen Pull Request, wird reviewt und mergt erst, wenn die Checks grün sind – genau der GitHub Flow, den die Prüfung beschreibt. Der PR-Thread ist auch unser Entscheidungs-Logbuch: Ein halbes Jahr später steht das Warum hinter einer Änderung genau dort, verknüpft mit dem Issue, das sie ausgelöst hat.

Actions erledigen die unglamouröse, verlässliche Arbeit. Build, Test, Lint und Deploy nach Azure laufen alle als GitHub Actions. Für die Branchen, die wir bedienen – wo ein Bug keine kosmetische Macke ist, sondern ein verpasster Export oder eine fehlgeschlagene Zahlung –, ist eine Pipeline, die jedes Mal gleich läuft, mehr wert als das Heldentum eines Einzelnen. Das Prüfungsziel „Zweck und Fähigkeiten von GitHub Actions" ist für uns schlicht eine Beschreibung des Dienstags.

Copilot-Agenten und isolierte Worktrees sind, wie wir heute arbeiten. Wir betreiben KI-gestützte Entwicklung im Ernst: Copilot für Vorschläge und Agenten, die in isolierten Worktrees arbeiten, damit parallele Aufgaben nicht kollidieren – jeder Agent bekommt seinen eigenen Checkout des Repos, arbeitet unabhängig, und gemergt wird, wenn die Checks durchlaufen. Copilots Agent-Modi zu verstehen und den Unterschied zwischen den Lizenzstufen – direkt aus dem Prüfungsplan – ist das, was mir nüchterne Entscheidungen darüber erlaubt, wo KI in den Workflow eines Kunden gehört und wo ein Mensch den Merge weiterhin freigibt.

Sicherheit und Zugriff sind keine nachträglichen Gedanken. Zwei-Faktor-Authentifizierung, sinnvolle Repository-Sichtbarkeit und saubere Rollen über unsere Organisation hinweg sind Basishygiene. Wenn wir einem Kunden sagen, dass sein Code und seine Daten verantwortungsvoll behandelt werden, ist der Bereich GitHub-Administration und -Sicherheit ein Teil dessen, was diesen Satz wahr statt bloß ambitioniert macht.

Das ist der ehrliche Grund, warum eine erfahrene Person eine Einsteiger-Prüfung ablegt. Das Credential ist Einsteigerniveau; die Plattform, die es zertifiziert, ist alles andere als das. GitHub ist der Ort, an dem unsere Software tatsächlich entsteht, und ich bin lieber nachweislich firm in der Grundlage, als leise anzunehmen, dass ich es bin.

Verify: https://www.credly.com/badges/4d591f69-7b8e-43a7-9c15-af4e00cbc2c6/public_url

Quellen & weiterführende Links

• Microsoft Learn – GitHub Foundations Zertifizierung (Prüfung GH-900): https://learn.microsoft.com/en-us/credentials/certifications/github-foundations/
• Microsoft Learn – Study guide for Exam GH-900: GitHub Foundations (gemessene Kompetenzen und Gewichtungen): https://learn.microsoft.com/en-us/credentials/certifications/resources/study-guides/gh-900
• GitHub Education – GitHub Foundations Certification: https://education.github.com/experiences/foundations_certificate
• GitHub Docs – Get started with Git and GitHub: https://docs.github.com/get-started
• GitHub Docs – GitHub Actions: https://docs.github.com/actions
• GitHub Docs – GitHub Copilot: https://docs.github.com/copilot

Bildnachweise

Alle Bilder werden unter ihren jeweiligen Creative-Commons- oder Public-Domain-Bedingungen verwendet; wir danken den Urhebern.

• cmd.exe — © *n3wjack's world in pixels, CC BY-SA 2.0, via Flickr (source).
• On the big screen — © Disgwylfa, CC BY 2.0, via Flickr (source).
• Processed Mango Fruit Juice been conveyed from one place to another in the factory 01 — © Samsule2, CC BY-SA 4.0, via Wikimedia Commons (source).