Wenn Sie Mitglied einer Organisation sind, die von Azure DevOps zu GitHub migriert wurde, erläutert dieser Leitfaden die Änderungen in Ihren Workflows, um die Migration so reibungslos wie möglich zu gestalten.
Struktur
In Azure DevOps sind Repositorys in Teamprojekten geschachtelt, sodass die Struktur Ihrer Umgebung wie folgt aussieht:
- Organisation
- Teamprojekt
- Repositorien
- Teamprojekt
- Repositorien
- Teamprojekt
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
- Organisation
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, und es wird nicht empfohlen, Organisationen in GitHub als Entsprechung von Teamprojekten zu behandeln.
Obwohl Sie möglicherweise anfangs jede migrierte Organisation auf GitHub mit einer langen, unorganisierten Liste von Repositorys vorfinden, können Sie den Zugriff und die Berechtigungen über Teams von Organisationsmitgliedern gewähren, was die Navigation in den Repositorys der Organisation erheblich erleichtert.
Authentifizierung, Berechtigungen und Teams
Es gibt zwei Methoden zum Authentifizieren von 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 Sie ein bereitgestelltes Konto, das mit dem Unternehmenskonto verknüpft ist.
Andernfalls 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.
In einem Unternehmen mit 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 Enterprise Managed Users verwendet, können Benutzerkonten keine öffentlichen Repositories oder anderen öffentlich zugänglichen Inhalte erstellen.
Git verwenden
Um mit Git weiter an Ihren Repositorys zu arbeiten, müssen Sie einige Änderungen vornehmen.
- Aktualisieren Sie die Remote-URLs so, dass sie auf GitHubzeigen. Weitere Informationen findest du unter Remote-Repositorys verwalten.
- Aktualisieren Sie, wie Sie sich authentifizieren.
- Um die HTTPS-Authentifizierung zu verwenden, müssen Sie ein personal access token erstellen. 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 zu GitHub erstellen oder hinzufügen. Weitere Informationen findest du unter Herstellen einer Verbindung mit GitHub mit SSH.
- Wenn Ihr Unternehmen oder Ihre Organisation SAML Single Sign-On (SSO) verwendet, müssen Sie Ihre personal access token oder SSH-Schlüssel autorisieren, bevor sie auf Ressourcen zugreifen kann.
Pullanforderungsfluss
Nachdem Ihre Codebasis jetzt auf GitHub gehostet wurde, schlagen Sie Änderungen mithilfe von Pullanforderungen vor, die in Ihrem GitHub Repositorys erstellt wurden.
Wenn Ihr Unternehmen Azure Boards und Pipelines integriert hat, funktionieren diese 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 auf Azure Boards weiterhin anzeigen und verwalten. Sie können auch Branches, Commits und Pullanforderungen mit Arbeitsaufgaben innerhalb von Azure verknüpfen. Sehen Sie GitHub-Commits, Pull-Anfragen, Branches und Issues mit Arbeitselementen in Azure Boards verknüpfen auf Microsoft Learn.
Branchschutz
Personen mit Administratorzugriff auf ein Repository können Verzweigungsschutzregeln für GitHubkonfigurieren. Diese sind mit Zweigrichtlinien für Azure DevOps vergleichbar und legen Regeln fest, z. B. eine Mindestanzahl von Genehmigungsprüfern, erfolgreiche Statusprüfungen und das 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 Informationen zu Code-Eigentümern.
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 wurden.
Auf GitHub werden Pakete in der Regel 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 Repositories 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 in Copilot-Chat zu beantworten, Vorschläge bei Ihren Pull-Requests zu überprüfen und vorzunehmen und sogar Änderungen in Ihrem Auftrag mit Copilot Codierungsassistent vorzunehmen.
Weitere Informationen findest du unter Schnellstart für GitHub Copilot.