Wichtige Unterschiede zwischen Azure DevOps und GitHub

Wenn 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.

Struktur

In Azure DevOps werden Repositorys in teamprojekten geschachtelt, sodass die Struktur Ihrer Umgebung wie folgt aussieht:

• Organisation
  • Teamprojekt
    • Repositorien
  • Teamprojekt
    • Repositorien

Berechtigungen und Sichtbarkeit leiten sich aus dem Teamprojekt ab.

          GitHub ist anders strukturiert. Repositories werden direkt in **Organisationen** eingebettet, die auch Teams enthalten.

• Unternehmenskonto
  • Organisation
    • Mannschaften
    • Repositorien
  • Organisation
    • Mannschaften
    • Repositorien

Berechtigungen und Sichtbarkeit werden durch eine Kombination aus Organisationsmitgliedschaft, Teammitgliedschaft und individuellen Berechtigungen bestimmt.

Das 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.

Obwohl 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.

Authentifizierung, Berechtigungen und Teams

Es gibt zwei Methoden zur Authentifizierung bei GitHub. Welche Methode Sie verwenden, hängt davon ab, wie das Unternehmenskonto konfiguriert ist.

Wenn 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.

Andernfalls verwenden Sie ein persönlichesGitHub 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.

In 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.

Git verwenden

Um mit Git weiter an Ihren Repositorys zu arbeiten, müssen Sie einige Änderungen vornehmen.

1. Aktualisieren Sie die Remote-URLs so, dass sie auf GitHub. Weitere Informationen findest du unter Remote-Repositorys verwalten.
2. Aktualisieren Sie, wie Sie sich authentifizieren.
   • Um die HTTPS-Authentifizierung zu verwenden, müssen Sie eine personal access token. Weitere Informationen findest du unter Verwalten deiner persönlichen Zugriffstoken.
   • 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.
3. 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.

Pullanforderungsfluss

Da Ihre Codebasis nun auf GitHub gehostet ist, schlagen Sie Änderungen mithilfe von Pull Requests vor, die in Ihren GitHub-Repositorys erstellt werden.

Wenn 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).

Sie 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 GitHub-Commits, Pull-Anfragen, Branches und Issues mit Arbeitsaufgaben in Azure Boards verknüpfen auf Microsoft Learn.

Branchschutz

Personen mit Administratorzugriff auf ein Repository können Branchenschutzregeln auf GitHub konfigurieren. Diese ähneln branch-Richtlinien für Azure DevOps und Festlegen von Regeln wie einer Mindestanzahl von Genehmigungsprüfern, erfolgreichen Statusüberprüfungen und Erfordern von signierten Commits.

          GitHub 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 [AUTOTITLE](/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners).

Pakete und Artefakte

In 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.

On 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.

Wenn 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.xmloder in Ihrer Pipelinekonfiguration aktualisieren.

Weitere Informationen finden Sie unter Einführung in GitHub-Pakete.

GitHub Copilot

Das 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 Cloudagent durchzuführen.

Weitere Informationen findest du unter Schnellstart für GitHub Copilot.