{"meta":{"title":"Wichtige Unterschiede zwischen Azure DevOps und GitHub","intro":"Kernworkflows wie Repositoryzugriff, Authentifizierung und Pullanforderungen unterscheiden sich nach dem Wechsel von Azure DevOps zu GitHub.","product":"Migrationen","breadcrumbs":[{"href":"/de/migrations","title":"Migrationen"},{"href":"/de/migrations/ado","title":"Migrieren von Azure DevOps"},{"href":"/de/migrations/ado/key-differences-between-azure-devops-and-github","title":"Wichtige Unterschiede"}],"documentType":"article"},"body":"# Wichtige Unterschiede zwischen Azure DevOps und GitHub\n\nKernworkflows wie Repositoryzugriff, Authentifizierung und Pullanforderungen unterscheiden sich nach dem Wechsel von Azure DevOps zu GitHub.\n\nWenn Sie Mitglied einer Organisation sind, die von Azure DevOps zu GitHub migriert wurde, werden in diesem Leitfaden die Änderungen in Ihren Workflows erläutert, um die Migration so reibungslos wie möglich zu gestalten.\n\n## Struktur\n\nIn Azure DevOps werden Repositorys in **teamprojekten** geschachtelt, sodass die Struktur Ihrer Umgebung wie folgt aussieht:\n\n* Organisation\n  * Teamprojekt\n    * Repositorien\n  * Teamprojekt\n    * Repositorien\n\nBerechtigungen und Sichtbarkeit leiten sich aus dem Teamprojekt ab.\n\nGitHub ist anders strukturiert. Repositories werden direkt in **Organisationen** eingebettet, die auch Teams enthalten.\n\n* Unternehmenskonto\n  * Organisation\n    * Mannschaften\n    * Repositorien\n  * Organisation\n    * Mannschaften\n    * Repositorien\n\nBerechtigungen und Sichtbarkeit werden durch eine Kombination aus Organisationsmitgliedschaft, Teammitgliedschaft und individuellen Berechtigungen bestimmt.\n\nDas Konzept eines Teamprojekts, das zum Gruppieren von Repositorys in Azure DevOps verwendet wird, existiert in GitHub nicht. Es wird nicht empfohlen, Organisationen in GitHub als Äquivalent von Teamprojekten zu behandeln.\n\nObwohl Sie zunächst feststellen mögen, dass jede migrierte Organisation auf GitHub über eine lange, unorganisierte Liste von Repositories verfügt, können Sie Zugriff und Berechtigungen über Teams von Organisationsmitgliedern verwalten, was die Navigation in den Repositories der Organisation erheblich erleichtert.\n\n## Authentifizierung, Berechtigungen und Teams\n\nEs gibt zwei Methoden zur Authentifizierung bei GitHub. Welche Methode Sie verwenden, hängt davon ab, wie das Unternehmenskonto konfiguriert ist.\n\nWenn Ihr Unternehmenskonto Enterprise Managed Users verwendet, melden Sie sich über Ihren Identitätsanbieter (z. B. Entra ID) bei GitHub an und verwenden ein **provisioned** Konto, das mit dem Unternehmenskonto verknüpft ist.\n\nAndernfalls verwenden Sie ein **persönliches**GitHub Konto. Dieses Konto wird zum Unternehmenskonto und zu allen Organisationen eingeladen, in denen Sie tätig sein werden. Wenn das Unternehmenskonto mit zusätzlichen SAML-Zugriffsbeschränkungen konfiguriert ist, wird Ihr persönliches Konto mit Ihrem IdP **verknüpft** . Sie werden aufgefordert, sich beim IdP zu authentifizieren, wenn Sie auf Ressourcen innerhalb des Unternehmenskontos zugreifen müssen.\n\nIn einem Unternehmen GitHubkönnen Repositorys öffentlich, privat oder intern sein. Private Repositorys sind nur für Personen und Teams mit expliziten Zugriff sichtbar, und interne Repositorys sind für alle Mitglieder Ihres Unternehmens sichtbar, aber nicht für Personen außerhalb des Unternehmens. Interne Repositorys sind nützlich, wenn mehrere Organisationen im selben Unternehmen Code ermitteln und wiederverwenden müssen. Wenn Ihr Unternehmen verwendet Enterprise Managed Users, können Benutzerkonten keine öffentlichen Repositorys oder andere öffentliche Inhalte erstellen.\n\n## Git verwenden\n\nUm mit Git weiter an Ihren Repositorys zu arbeiten, müssen Sie einige Änderungen vornehmen.\n\n1. Aktualisieren Sie die Remote-URLs so, dass sie auf GitHub. Weitere Informationen findest du unter [Remote-Repositorys verwalten](/de/get-started/git-basics/managing-remote-repositories).\n2. Aktualisieren Sie, wie Sie sich authentifizieren.\n   * Um die HTTPS-Authentifizierung zu verwenden, müssen Sie eine personal access token. Weitere Informationen findest du unter [Verwalten deiner persönlichen Zugriffstoken](/de/authentication/keeping-your-account-and-data-secure/managing-your-personal-access-tokens).\n   * Um die SSH-Authentifizierung zu verwenden, müssen Sie entweder einen vorhandenen SSH-Schlüssel erstellen oder hinzufügen.GitHub Weitere Informationen findest du unter [Herstellen einer Verbindung mit GitHub mit SSH](/de/authentication/connecting-to-github-with-ssh).\n3. Wenn Ihr Unternehmen oder Ihre Organisation SAML Single Sign-On (SSO) verwendet, müssen Sie Ihren personal access token oder SSH-Schlüssel autorisieren, bevor sie auf Ressourcen zugreifen kann.\n\n## Pull-Request-Flow\n\nDa Ihre Codebasis nun auf GitHub gehostet ist, schlagen Sie Änderungen mithilfe von Pull Requests vor, die in Ihren GitHub-Repositorys erstellt werden.\n\nWenn Ihr Unternehmen Azure Boards und Pipelines integriert hat, funktionieren beide mit GitHub. Sie können weiterhin auf Arbeitsaufgaben in Ihren Commit-Nachrichten und Pull-Requests verweisen. Beispiel: `Fix login bug (AB#1234)`.\n\nSie können Ihre Arbeitsaufgaben weiterhin auf Azure Boards anzeigen und verwalten. Sie können auch Branches, Commits und Pull-Requests mit Arbeitsaufgaben in Azure verknüpfen. Weitere Informationen finden Sie unter [Verknüpfen von Commits, Pull-Requests, Branches und Issues von GitHub mit Arbeitselementen in Azure Boards](https://learn.microsoft.com/en-us/azure/devops/boards/github/link-to-from-github) auf Microsoft Learn.\n\n## Branchschutz\n\nPersonen mit Administratorzugriff auf ein Repository können **Branchenschutzregeln** auf GitHub konfigurieren. Diese ähneln **Branch-Richtlinien** für Azure DevOps und legen Regeln wie eine Mindestanzahl von genehmigenden Prüfern, erfolgreichen Statusüberprüfungen und das Erfordern von signierten Commits fest.\n\nGitHub unterstützt außerdem das automatische Zuweisen von Prüfern basierend auf den Datei-, Ordner- und Globmustern in der CODEOWNERS-Datei eines Repositorys. Weitere Informationen findest du unter [Informationen zu Code-Eigentümern](/de/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners).\n\n## Pakete und Artefakte\n\nIn Azure DevOps haben Sie möglicherweise Azure Artifacts zum Veröffentlichen und Nutzen von Paketen (z. B. NuGet-Pakete, npm-Pakete oder Maven-Pakete) und zum Speichern von Buildartefakten verwendet, die von Azure Pipelines erstellt werden.\n\nOn GitHub werden Pakete typischerweise in GitHub Packages veröffentlicht und einem Repository oder einer Organisation zugeordnet. Je nachdem, wie Ihr Unternehmen die Migration abgeschlossen hat, können Sie weiterhin Pakete in Azure Artifacts veröffentlichen, Pakete in GitHub Packages verschieben oder eine Kombination aus beiden verwenden.\n\nWenn Sie Abhängigkeiten nach der Migration nicht mehr wiederherstellen können, überprüfen Sie die Paketquellkonfiguration. Beispielsweise müssen Sie möglicherweise eine Registrierungs-URL oder Anmeldeinformationen in Dateien wie `nuget.config`, `.npmrc`, , `settings.xml`oder in Ihrer Pipelinekonfiguration aktualisieren.\n\nWeitere Informationen finden Sie unter [Einführung in GitHub-Pakete](/de/packages/learn-github-packages/introduction-to-github-packages).\n\n## GitHub Copilot\n\nDas Hosten Ihrer Repositorys auf GitHub schaltet die volle Leistungsfähigkeit von Copilot frei. Ihre Codebasis stellt Copilot den gesamten Kontext zur Verfügung, den es benötigt, um Fragen Copilot Chat zu beantworten, Überprüfungen und Vorschläge in Ihren Pull-Requests vorzunehmen und sogar Änderungen in Ihrem Auftrag Copilot cloud agent durchzuführen.\n\nWeitere Informationen findest du unter [Schnellstart für GitHub Copilot](/de/copilot/get-started/quickstart)."}