Git
PowerShell Universal kann die Konfigurationsskripte mit einem Remote-Git-Repository synchronisieren.
Konfiguration
Admin-Konsole
Die Git-Synchronisierung kann in der Datenbank konfiguriert werden, indem die Einstellungen innerhalb der Admin-Konsole angepasst werden. Dies ist der bevorzugte Ansatz. Der Vorteil ist, dass Sie die Git-Synchronisierung nicht erneut konfigurieren müssen, wenn Sie neue Instanzen von PowerShell Universal mit Ihrer SQL-Instanz verbinden.
Um die Git-Synchronisierung zu konfigurieren, navigieren Sie in der Admin-Konsole zu Einstellungen \ Git. Sie können dort auf die Schaltfläche „Create Git Settings“ klicken.
appsettings.json
Sie können auch die Konfigurationseinstellungen verwenden, um die Git-Synchronisierung einzurichten. Dies ist nützlich, wenn Sie eine einzelne PSU-Instanz haben und Ihre appsettings.json-Datei sichern möchten. Das Anpassen von Einstellungen in der Admin-Konsole aktualisiert die appsettings.json-Datei nicht. Sie müssen dies manuell tun und PowerShell Universal nach dem Ändern der Einstellungen neu starten.
Wenn Einstellungen für die Git-Synchronisierung in der Datenbank angegeben sind, werden in appsettings.json definierte Einstellungen ignoriert.
Einstellungen für die Git-Synchronisierung
Branch
Standardmäßig synchronisiert PowerShell Universal mit dem master-Branch. Wenn Sie einen anderen Branch verwenden möchten, geben Sie die Einstellung GitBranch in Ihrer appsettings.json an.
Fehlendes Upstream-Tracking beheben
Wenn der Fehler "There is no tracking information for the current branch" auftritt, ist der lokale Branch nicht mit dem Remote verknüpft. So beheben Sie das Problem:
Öffnen Sie PowerShell in
%ProgramData%\UniversalAutomation\Repository(oder im konfigurierten Repository-Pfad)Führen Sie aus:
Remote
Remotes sind nicht erforderlich. Wenn kein Remote angegeben ist, wird das Git-Repository lokal im Repository-Verzeichnis gespeichert. Wenn eines angegeben ist, synchronisiert PowerShell Universal mit dem Remote. Für den Zugriff auf dieses Remote sind entsprechende Anmeldeinformationen erforderlich.
Azure DevOps-URL-Format
Azure DevOps-Repositories sollten das moderne dev.azure.com-URL-Format anstelle der veralteten visualstudio.com-Domäne verwenden:
Korrektes Format:
Beispiele:
Wenn Ihr Repository-Name Leerzeichen enthält, sollten diese in der URL als %20 codiert werden. Vermeiden Sie URLs mit der älteren visualstudio.com-Domäne, da sie Redirect-Loops oder Authentifizierungsfehler mit dem Fehler "too many redirects or authentication replays" verursachen können.
Für Azure DevOps muss Ihr Personal Access Token den Scope Code (Read & Write) besitzen. Fine-grained Tokens funktionieren, es werden jedoch klassische PATs empfohlen, um die Kompatibilität über PSU-Versionen hinweg zu gewährleisten.
Hinweis für GitLab-Benutzer: Wenn Ihre GitLab-Instanz eine Header-basierte Authentifizierung erfordert, müssen Sie möglicherweise die Option „External Git Client“ verwenden und Git-Credential-Helper konfigurieren, da der in PSU integrierte Git-Client HTTP Basic Authentication mit dem PAT als Passwort verwendet. Einige GitLab-Konfigurationen erwarten stattdessen einen Private-Token-Header.
Authentifizierung
Sie müssen die Authentifizierung für Ihr Remote-Git-Repository konfigurieren. Wir empfehlen ein Personal Access Token.
Externer Git-Client
Sie können einen externen Git-Client verwenden, anstatt die in PowerShell Universal integrierte Bibliothek zu nutzen. Dies bietet Ihnen zusätzliche Konfigurationsmöglichkeiten, wie zum Beispiel die Verwendung der SSH-Authentifizierung. PowerShell Universal verwendet bei Aktivierung dieser Methode keine konfigurierten Benutzernamen, Passwörter oder PATs. Sie müssen einen Git-Client installiert haben.
SSH-Schlüssel verwenden
Sie können PowerShell Universal verwenden, um SSH-Schlüssel zu generieren und zu verwalten. Klicken Sie in der Admin-Konsole auf Platform \ SSH Keys. Generieren Sie einen neuen SSH-Schlüssel. Klicken Sie anschließend auf die Kopieren-Schaltfläche neben dem SSH-Schlüssel, um den öffentlichen Schlüssel zu erhalten.
Registrieren Sie den öffentlichen Schlüssel beim Ziel-Repository oder -Konto. Sie können beispielsweise diesem GitHub-Leitfaden folgen.
Wählen Sie im Fenster „Git Settings“ den SSH-Schlüssel aus, den Sie für die Git-Synchronisierung verwenden möchten. Stellen Sie bei Verwendung von SSH-Schlüsseln sicher, dass zum Klonen Ihres Repositories die SSH-URL ausgewählt ist.
Anmeldeinformationen festlegen
Bei Verwendung des externen Git-Clients sind Sie dafür verantwortlich, die Anmeldeinformationen vor der Durchführung einer Synchronisierung zu konfigurieren.
Sie können Anmeldeinformationen über die Git-Konfiguration oder über die an PowerShell Universal übergebene URL konfigurieren.
Der folgende Befehl speichert die Anmeldeinformationen im Klartext auf dem PowerShell Universal-Server. Sie müssen diesen Befehl als Dienstkonto-Benutzer ausführen, damit dieser Zugriff auf die Anmeldeinformationen hat. Dadurch wird eine .git-credentials-Datei erstellt, die bei der Authentifizierung gegenüber der Ziel-URL verwendet wird. Je nach Ihrem Git-Remote müssen Sie die URL möglicherweise ändern.
Sie können Anmeldeinformationen auch direkt in der an PowerShell Universal übergebenen URL speichern.
Beispiel: Benutzername und PAT
Um einen externen Git-Client zu verwenden und einen Benutzernamen sowie ein PAT zur Authentifizierung zu übergeben, können Sie diese in der Git-Remote-URL angeben. Zum Beispiel:
Beispiel: SSH und GitHub
Zunächst müssen Sie Ihren lokalen ssh-agent und Ihr GitHub-Konto mit SSH-Schlüsseln konfigurieren.
Sie können deren Leitfaden hier befolgen.
Anschließend geben Sie in PowerShell Universal eine SSH-URI als Git-Remote-URL an. Der konfigurierte SSH-Schlüssel wird für die Verbindung verwendet.
SSL-Zertifikatsproblem
SSL Certificate problem: unable to get local issuer certificate
Wenn Sie unter Windows arbeiten und ein SSL-Zertifikatsproblem erhalten, müssen Sie möglicherweise sicherstellen, dass Sie die schannel-Unterstützung aktiviert haben.
Persistenz von Anmeldeinformationen
Unable to persist credentials with the 'wincredman' credential store.
Wenn Sie unter Windows arbeiten und einen Fehler bezüglich der Persistenz von Anmeldeinformationen in wincredman erhalten, müssen Sie möglicherweise die Persistenz der Anmeldeinformationen auf DAPI setzen. Sie können hier erfahren, wie das geht.
Manueller Modus
Im manuellen Modus müssen Benutzer, die die PowerShell Universal-Instanz bearbeiten, auf „Edit“ klicken, um Änderungen im System vorzunehmen.
Sobald die Änderungen abgeschlossen sind, kann der Benutzer auf „Save Changes“ klicken, um einen Commit zu starten
Auf der Git-Commit-Seite können Sie die geänderten Dateien anzeigen und eine Commit-Nachricht eingeben.
Sobald Änderungen committet wurden, werden sie an das Remote gepusht und der Dienst beginnt erneut mit der Synchronisierung mit Git. Es besteht zu diesem Zeitpunkt auch die Möglichkeit, dass ein Git-Merge-Konflikt auftritt. Weitere Informationen finden Sie unter Umgang mit Konflikten.
Der manuelle Modus kann in den Git-Einstellungen innerhalb der Admin-Konsole oder in appsettings.json festgelegt werden.
Methode eins: Lokale Dateien an das Remote pushen
Sie müssen sicherstellen, dass Ihr lokaler Ordner kein bereits vorhandenes Git-Repository ist. Ihr Repository-Verzeichnis sollte einfach ein Ordner mit Ihren PowerShell Universal-Dateien sein. Wenn ein .git-Ordner vorhanden ist und Sie dieses Repository nicht verwenden möchten, sollten Sie ihn löschen, und PowerShell Universal erstellt ein neues Repository.
Wenn Sie ein neues Git-Repository füllen, müssen Sie sicherstellen, dass das Remote keine Dateien enthält. Es sollte ein vollständig leeres (bare) Repository sein. Wählen Sie beispielsweise beim Erstellen eines Repositories auf GitHub nicht aus, dass eine Lizenz- oder readme.md-Datei erstellt wird.
Sobald das Repository erstellt wurde, können Sie die Git-Remote-URL abrufen und in der appsettings.json-Datei von PowerShell Universal angeben.
Sobald Sie den Branch, die Git-Remote-URL und die Anmeldeinformationen haben, können Sie diese in Ihrer appsettings.json-Datei angeben, und das Git-Remote wird mit Ihren lokalen Dateien gefüllt.
Methode zwei: Von einem Git-Remote pullen
Sie können PowerShell Universal so konfigurieren, dass es von einem Git-Remote pullt. Bei dieser Konfiguration müssen Sie sicherstellen, dass Ihr lokaler Repository-Ordner vollständig leer ist. Alle Dateien innerhalb des Ordners führen zum Fehlschlagen der Git-Synchronisierung und verhindern eine Wiederherstellung.
Konfigurieren Sie die appsettings.json-Datei so, dass sie den Branch, die Anmeldeinformationen und die Git-Remote-URL enthält, die Sie klonen. Sobald die Felder festgelegt sind, können Sie den PowerShell Universal-Dienst starten. Das Erste, was der Dienst tut, ist das Klonen des Repositories und dessen lokale Konfiguration.
Timeout der Git-Synchronisierung
Die Git-Synchronisierung läuft ab, wenn das Remote nach 60 Minuten nicht erreicht werden kann. Dies lässt Zeit zum Herunterladen großer Repositories oder für Verzögerungen bei langsamen Netzwerken. Möglicherweise sehen Sie, dass der PowerShell Universal-Dienst beim Start bei "Synchronizing with git" hängt, während der Server darauf wartet. Wenn Sie diese Zeit verkürzen möchten, können Sie die folgende appsetting.json-Einstellung verwenden. Der Wert ist in Minuten angegeben.
Synchronisierungsintervall
Typ: Integer
Standard: 60
appsettings.json: GitSyncInterval
Das Intervall in Sekunden zwischen automatischen Git-Synchronisierungsversuchen, wenn die automatische Synchronisierung aktiviert ist. Der Standardwert beträgt 60 Sekunden (1 Minute).
Um die Synchronisierungsfrequenz anzupassen, bearbeiten Sie appsettings.json:
Dies würde das Synchronisierungsintervall auf 5 Minuten ändern. Niedrigere Werte erhöhen die Synchronisierungsfrequenz, können jedoch die Leistung bei großen Repositories oder langsamen Netzwerken beeinträchtigen. Es wird nicht empfohlen, diesen Wert zu niedrig einzustellen (unter 30 Sekunden), insbesondere in Produktionsumgebungen.
Fehlerbehebung
Azure DevOps: "Too many redirects or authentication replays"
Dieser Fehler weist typischerweise auf eines der folgenden Probleme hin:
Veraltetes URL-Format: Stellen Sie sicher, dass Sie
https://dev.azure.com/<org>/<project>/_git/<repo>anstelle der älterenvisualstudio.com-Domäne verwendenUngültiger PAT-Scope: Ihr Personal Access Token muss über die Berechtigungen Code (Read & Write) in Azure DevOps verfügen
Abgelaufene Anmeldeinformationen: Generieren Sie ein neues PAT und geben Sie es erneut in den Git-Einstellungen von PSU ein
Codierte Leerzeichen: Wenn Ihr Repository-Name Leerzeichen enthält, stellen Sie sicher, dass diese in der URL als
%20codiert sind
Lösung:
Aktualisieren Sie die Remote-URL, sodass
dev.azure.comverwendet wirdGenerieren Sie ein neues PAT mit dem Scope Code (Read & Write)
Aktivieren Sie Use External Git Client und installieren Sie Git for Windows, wenn der integrierte Client weiterhin fehlschlägt
Fehlendes Upstream-Tracking
Fehler: "There is no tracking information for the current branch"
Ursache: Der lokale Git-Branch ist nicht so konfiguriert, dass er einen Remote-Branch verfolgt.
Lösung: Öffnen Sie PowerShell im Repository-Verzeichnis und führen Sie aus:
Ersetzen Sie main durch Ihren tatsächlichen Branch-Namen. Klicken Sie dann in PSU auf Synchronize Now.
Git-Synchronisierung stoppt nach dem Ändern von Einstellungen in der Benutzeroberfläche
Symptome: Nach dem Bearbeiten der Git-Einstellungen (Remote-URL, Anmeldeinformationen, Synchronisierungsintervall usw.) in der PSU-Benutzeroberfläche und dem Klicken auf OK funktioniert die Synchronisierung nicht mehr, obwohl die Einstellungen korrekt erscheinen.
Ursache: In PSU 5.x werden Git-Anmeldeinformationen in der SQL-Datenbank gespeichert. Jede Änderung an den Git-Einstellungen über die Benutzeroberfläche kann die gespeicherten Anmeldeinformationen löschen, selbst wenn das Passwortfeld im Formular weiterhin gefüllt erscheint.
Lösung:
Geben Sie das Personal Access Token unter Settings → Git erneut ein
Klicken Sie auf OK, um zu speichern
Wiederholen Sie diesen Vorgang in Umgebungen mit mehreren Knoten auf jedem Knoten – die Anmeldeinformationen müssen auf jedem Server einzeln eingegeben werden
Klicken Sie auf Synchronize Now, um zu überprüfen, ob die Synchronisierung wieder funktioniert
Das System überträgt Anmeldeinformationen in einer Konfiguration mit Lastverteilung oder Hochverfügbarkeit nicht automatisch auf andere Knoten.
Agent- und Netzwerkprobleme
Symptome: Die Synchronisierung funktioniert auf einem Knoten, schlägt aber auf anderen fehl, oder Sie sehen RpcException oder "service is unavailable"-Fehler in den Protokollen.
Häufige Ursachen:
Versionskonflikt: Stellen Sie sicher, dass alle PSU-Server und -Agenten die gleiche Version ausführen
Firewall-Regeln: Agenten kommunizieren mit dem PSU-Server über gRPC auf den Ports 5000 (HTTP) oder 5001 (HTTPS)
Blockierung durch Proxy oder WebSocket: Unternehmens-Proxys können gRPC-Traffic blockieren oder inspizieren; konfigurieren Sie Git für die Verwendung des Proxys oder aktivieren Sie den externen Git-Client
Lösung:
Überprüfen Sie, ob auf allen Knoten die gleiche PSU-Version ausgeführt wird
Prüfen Sie, ob die Firewall-Regeln Traffic auf den Ports 5000/5001 zulassen
Testen Sie die gRPC-Konnektivität zwischen den Knoten
Wenn Sie einen Proxy verwenden, konfigurieren Sie die Umgebungsvariablen
http_proxyundhttps_proxyfür das PSU-Dienstkonto
Docker- und containerisierte Bereitstellungen
Stellen Sie sicher, dass das Container-Image
gitenthält (führen Siegit --versionaus, um dies zu überprüfen)Überprüfen Sie den ausgehenden Netzwerkzugriff auf das Git-Remote
Binden Sie persistente Volumes für
/dataoder%ProgramData%\UniversalAutomationein, um den Git-Status über Neustarts hinweg zu erhaltenWenn die Synchronisierung stillschweigend fehlschlägt, prüfen Sie die Container-Protokolle auf Git- oder Netzwerkfehler
Bearbeiten von .git/config ohne Git CLI
Wenn das Git-Befehlszeilenwerkzeug nicht auf dem Server installiert ist und Sie auf Upstream-Tracking-Fehler stoßen, können Sie die Repository-Konfiguration direkt über den Datei-Browser von PSU bearbeiten:
Navigieren Sie zu Platform → Configuration → Repository → .git → config
Fügen Sie die folgenden Zeilen hinzu (passen Sie den Branch-Namen an Ihr Repository an):
Klicken Sie auf Speichern
Kehren Sie zu Settings → Git zurück und klicken Sie auf Synchronize Now
Mit diesem Ansatz können Sie das Upstream-Tracking konfigurieren, ohne git-Befehle zu benötigen, was besonders nützlich ist, wenn Git for Windows nicht installiert ist oder wenn unter eingeschränkten Dienstkonten ausgeführt wird.
Git-Einstellungen werden nicht beibehalten
Wenn Änderungen an den Git-Einstellungen nicht gespeichert werden oder unmittelbar nach dem Klicken auf OK zurückgesetzt werden:
Dateisystemberechtigungen prüfen:
Beenden Sie den PowerShell Universal-Dienst
Versuchen Sie,
%ProgramData%\PowerShellUniversal\appsettings.json(oder%ProgramData%\UniversalAutomation\appsettings.jsonin älteren Versionen) manuell zu bearbeitenFügen Sie eine Kommentarzeile hinzu, speichern Sie und öffnen Sie die Datei erneut, um zu überprüfen, ob Ihre Änderungen beibehalten werden
Wenn Änderungen zurückgesetzt werden, prüfen Sie, ob Antivirensoftware, Gruppenrichtlinienobjekte (GPO) oder NTFS-Berechtigungen Schreibvorgänge im PSU-Datenverzeichnis blockieren
Debug-Protokollierung zur Fehlerbehebung aktivieren:
Beenden Sie den PowerShell Universal-Dienst
Bearbeiten Sie
appsettings.jsonund setzen Sie:
Speichern Sie und starten Sie den Dienst neu
Versuchen Sie erneut, die Git-Einstellungen zu speichern
Prüfen Sie
%PROGRAMDATA%\PowerShellUniversal\systemLog.txtauf Fehler im Zusammenhang mit Konfigurationsschreibvorgängen
Git-Einstellungen manuell befüllen:
Bei gestopptem Dienst können Sie die Git-Felder direkt in appsettings.json befüllen:
Starten Sie den Dienst neu und überprüfen Sie, ob die Einstellungen unter Settings → Git erscheinen. Wenn sie wieder verschwinden, zeigen die Debug-Protokolle an, ob ein Berechtigungsproblem, eine Endpoint-Protection-Software oder ein Konfigurationsvalidierungsfehler das Zurücksetzen verursacht.
unknown certificate lookup failure: 16777280
Bei Verwendung der integrierten Git-Bibliothek können Zertifikatsprobleme auftreten, wenn Sie sich mit lokal gehosteten Git-Repositorys verbinden. In dieser Konfiguration empfehlen wir die Verwendung des externen Git-Clients, um mehr Unterstützung für die Konfiguration des Zertifikatssuchvorgangs zu bieten.
Enthaltene Dateien
Die Dateien, die bei einer Git-Synchronisierung enthalten sind, sind alle Dateien innerhalb des lokalen Repositorys. Dazu gehören PS1-Konfigurationsdateien, Pages-XML-Dateien und alle anderen Dateien, die Sie möglicherweise manuell hinzufügen.
Folgende sind nicht enthalten:
appsettings.json
database.db
web.config
PowerShell Universal-Anwendungsbinärdateien
Mehrere Git-Repositorys
PowerShell Universal unterstützt das Speichern mehrerer Git-Repository-Konfigurationen innerhalb der Datenbank. Dadurch können Sie schnell zwischen verschiedenen Konfigurationen von PowerShell Universal wechseln. Klicken Sie auf die Registerkarte Repositories, um die derzeit konfigurierten Repositorys anzuzeigen. Von hier aus können Sie Repository-Konfigurationen löschen und bearbeiten.
PowerShell Universal entfernt den Ordner .git nicht, wenn eine Repository-Konfiguration gelöscht wird. Sie müssen dies manuell tun, um ein neues Repository zu konfigurieren.
Wenn Sie eine neue Repository-Konfiguration hinzufügen, können Sie auf die Schaltfläche Apply klicken, um zum ausgewählten Repository zu wechseln. Dadurch werden alle Dateien im Repository-Verzeichnis gelöscht und das ausgewählte Repository geklont. Sie können eine Repository-Konfiguration nicht anwenden, wenn es nicht committete Änderungen in Ihrem Repository gibt. Nach dem Klonen des Repositorys lädt PowerShell Universal seine Konfiguration vollständig neu.
Git-Verlaufs- und Statusseite
Die Registerkarte History zeigt den gesamten Git-Commit-Verlauf für das aktuelle Repository an.
Die Registerkarte Sync Status zeigt den aktuellen Status der Knoten innerhalb des PSU-Clusters an.
Testen der Git-Synchronisierung
Der beste Weg, um sicherzustellen, dass Ihre Git-Synchronisierung ordnungsgemäß funktioniert, ist, auf die Schaltfläche Synchronize Now zu klicken. Dadurch wird eine Synchronisierung erzwungen, und Sie können überprüfen, ob die eingegebenen Einstellungen ordnungsgemäß funktioniert haben.
Änderungen anzeigen
Sie können Änderungen in der Tabelle der Git-Synchronisierungen anzeigen. Jede Synchronisierung enthält die Anzahl der seit der letzten Synchronisierung gefundenen Änderungen, den SHA des Commits und eine Liste der Änderungen zwischen diesem SHA und dem vorherigen. Wenn Dateien in einem geänderten Zustand sind, können Sie die Diffs mit dem Datei-Diff-Werkzeug anzeigen.
Umgang mit Konflikten
Wenn mehrere Benutzer die PowerShell Universal-Konfigurationsdateien bearbeiten, können Konflikte auftreten. PowerShell Universal zeigt an, dass sich ein bestimmter Knoten in einem Konfliktzustand befindet, wenn versucht wird, Änderungen zu committen. Auf der Git-Commit-Seite sehen Sie eine Liste der Änderungen, die im Konflikt stehen. Klicken Sie auf die Schaltfläche Resolve Conflict, um den Konflikt in einem Editor anzuzeigen.
In diesem Beispiel wurde die Zeichenfolge für diesen Endpunkt sowohl im Remote- als auch im lokalen Repository bearbeitet.
Bearbeiten Sie den Text, um den Konflikt zu beseitigen.
Speichern Sie die Änderungen und navigieren Sie zurück zur Git-Commit-Seite. Geben Sie eine neue Commit-Nachricht für den Merge-Konflikt ein und klicken Sie auf Commit Changes.
Damit wird der Merge-Konflikt gelöst und an das Remote gepusht.
Verhalten der Git-Synchronisierung
Zwei-Wege
Standardmäßig funktioniert die Git-Synchronisierung in beide Richtungen. Wenn Sie Änderungen in der PSU-Administrationskonsole vornehmen, werden diese Änderungen committet und mit dem konfigurierten Remote synchronisiert.
Alle Änderungen, die im Remote vorgenommen werden, werden lokal gepullt.
Wenn Sie die Git-Synchronisierung mit einem bereits vorhandenen Git-Remote einrichten, werden die Änderungen gepullt und lokal synchronisiert. Sie dürfen keine lokalen Änderungen haben.
Wenn Sie die Git-Synchronisierung mit einem Bare-Repository einrichten, werden die lokalen Änderungen synchronisiert und das Repository wird initialisiert.
Ein-Weg
Sie können das Verhalten der Git-Synchronisierung anpassen, indem Sie die Einstellung GitSyncBehavior in appsettings.json ändern. Wenn sie auf OneWay gesetzt ist, werden die Administrationskonsole und die Management-API schreibgeschützt. Das PowerShell Universal-System pullt vom Remote, wird aber niemals pushen oder lokal committen.
Nur-Push
Der Nur-Push-Git-Synchronisierungsmodus pullt keine Änderungen vom Remote. Alle lokal vorgenommenen Änderungen werden zum Remote gepusht. Die Konsole wird nicht schreibgeschützt. Diese Konfiguration ist nützlich für Szenarien, in denen Sie einen Computer haben, der für die Konfiguration als Source of Truth für einen Pool von Servern verwendet wird, die schreibgeschützt sind.
Persönliches Zugriffstoken
Wir empfehlen, ein persönliches Zugriffstoken (PAT) anstelle eines Benutzernamens und Passworts zu verwenden. Sie können ein persönliches Zugriffstoken konfigurieren, indem Sie die Passwort-Eigenschaft in der appsettings.json oder über andere Konfigurationsmethoden festlegen.
GitHub Fine-Grained Tokens
In GitHub können Sie ein Fine-Grained Token abrufen, indem Sie oben rechts auf Ihren Avatar klicken, Settings, Developers Settings, Personal Access Tokens und dann Fine-Grained Tokens auswählen.
Token-Bereiche
Stellen Sie beim Generieren des Tokens sicher, dass Sie dem Repository die Berechtigung Read-Write für Content erteilen. Dadurch wird automatisch Read für die Berechtigung Metadata hinzugefügt. Sie können den Zugriff nur auf das Repository erteilen, das Sie klonen möchten.
GitHub-Tokens (Classic)
In GitHub können Sie ein persönliches Zugriffstoken abrufen, indem Sie oben rechts auf Ihren Avatar klicken, Settings, Developer Settings, Personal Access Tokens und dann Tokens (Classic) auswählen.
Stellen Sie beim Generieren Ihres Zugriffstokens sicher, dass Sie die Repo-Berechtigungen auswählen.
Beachten Sie, dass Sie bei Verwendung von BitBucket zusätzlich zum PAT den Benutzernamen in appsettings.json angeben müssen.
Benutzername und Passwort
Sie können ein Git-Remote auch so konfigurieren, dass die Authentifizierung mit einem Benutzernamen und Passwort erfolgt. Legen Sie den Benutzernamen und das Passwort entweder mit der Datei appsettings.json oder einer anderen Konfigurationsmethode fest.
Häufige Fehler
Git synchronization failed. unknown certificate lookup failure: 16777280
Die Bibliothek lib2gitsharp konnte das Zertifikat des Remote-Git-Repositorys nicht validieren. Sie müssen den externen Git-Client und eine benutzerdefinierte Git-Konfiguration verwenden, um dies zu beheben.
Einige gängige Optionen für die Git-HTTPS-Unterstützung sind:
"too many redirects" oder Authentifizierungs-Replays
Das Git-Remote hat Ihre Anmeldeinformationen für den Zugriff auf das Repository abgelehnt. Ihr persönliches Zugriffstoken ist möglicherweise abgelaufen oder hat keinen Zugriff auf das Remote.
repository not owned by current user
Das lokale Git-Repository verfügt nicht über die richtigen Zugriffskontrollen für den Benutzer, der darauf zugreifen möchte. Dies kann passieren, wenn PowerShell Universal das Repository geklont hat und dann ein anderes Dienstkonto für den Dienst festgelegt wurde. Da die Zugriffskontrollen nicht übereinstimmen, greift Git nicht auf den Ordner zu. Dies ist ein Sicherheitsmerkmal von Git.
Sie können den Besitzer des Ordners aktualisieren, um dies zu vermeiden, oder Git so konfigurieren, dass es dem Ordner vertraut. Legen Sie den folgenden Wert in der globalen Git-Konfiguration fest.
Die globale Konfiguration finden Sie unter: C:\Program Files\git\etc\gitconfig
Vorteile der Git-Synchronisierung gegenüber der manuellen Git-Synchronisierung
Es ist möglich, ein Repository manuell per Git zu synchronisieren. PowerShell Universal verwendet sehr grundlegende Befehle im Umgang mit Git. Alle Änderungen, die über die Administrationskonsole oder die API an PowerShell Universal vorgenommen werden, lösen einen git commit aus, und der Autor wird auf die Identität des Benutzers gesetzt, der die Änderung vornimmt. Während eines Git-Synchronisierungsvorgangs führen wir zuerst ein git pull durch, um sicherzustellen, dass wir die neueste Version der Dateien im Remote haben. Anschließend führen wir ein git push durch, um lokale Commits zu pushen, die seit der letzten Synchronisierung erfolgt sind.
Sie könnten diese Funktionalität mit einem geplanten Job erreichen.
Dennoch ist eine Funktion der Git-Synchronisierung, dass sie den Commit analysiert, um sicherzustellen, dass nur Dateien neu geladen werden, die während der Synchronisierung geändert wurden. Dies verhindert, dass Dashboards automatisch bereitgestellt werden, wenn sie sich nicht geändert haben, oder dass API-Dienste neu gestartet werden, wenn die Umgebungen nicht aktualisiert wurden. Es gibt hier also einen Leistungsgewinn.
Das andere Problem ist, dass aufgrund der Art, wie PowerShell Universal Dateien überwacht (mit einem FileSystemWatcher), und der Art, wie Git Dateien aktualisiert, die Konfigurationen nach einem Pull nicht automatisch neu geladen werden. Sie müssen sicherstellen, dass Sie eine erneute Auswertung der Konfigurationen erzwingen.
Branching-Strategien
Branching-Strategien in Git legen fest, wie Änderungen von einem Branch in einen anderen verschoben werden. Die Verwendung verschiedener Arten von Branching-Strategien in PowerShell Universal kann sicherstellen, dass Teams unterschiedlicher Größe effektiv gemeinsam in der Plattform arbeiten können.
Einzelbenutzer und kleine Teams
Für Einzelbenutzer und kleine Teams ist es möglicherweise nicht erforderlich, mehr als einen einzigen Branch zu haben. Der Branch wird für die Verlaufsverfolgung verwendet und bietet die Möglichkeit, Änderungen zurückzunehmen. Benutzer greifen direkt auf PowerShell Universal zu, um Änderungen vorzunehmen, oder committen Änderungen in den einzelnen Branch aus lokalen Klonen des Repository-Verzeichnisses mit einem Werkzeug wie VS Code.
main - Einzelner Branch, der alle Änderungen direkt annimmt
Einzelbenutzer und kleine Teams mit einem Staging-Branch
Selbst Einzelbenutzer und kleine Teams können es vorteilhaft finden, einen Staging- oder Dev-Branch einzusetzen. Dieser Branch erhält Änderungen während der Entwicklung. Eine eigenständige Instanz von PowerShell Universal wird so konfiguriert, dass sie gegen diesen Dev-Branch läuft, sodass Benutzer Änderungen validieren können, bevor sie in die Produktion gepusht werden.
Bei Verwendung einer Staging-Branch-Konfiguration sind die PowerShell Universal-Umgebungen vollständig getrennt. Sie verwenden eine andere Datenbank und einen anderen Scheduler. Daten wie Identitäten, App-Tokens und Job-Verlauf werden nicht zwischen den Umgebungen geteilt.
Eine separate PowerShell Universal-Instanz kann dann so konfiguriert werden, dass sie auf einen main- oder Produktions-Branch verweist, der Aktualisierungen über Merges oder Pull Requests in einem System wie GitHub erhält. In dieser Konfiguration ist es möglich, eine Ein-Weg-Git-Synchronisierung zu verwenden, um Änderungen von main zu pullen, aber niemals von der Plattform zu pushen. Dies verhindert außerdem die meisten Merge-Konflikte, da sie im Dev-Branch oder über das Merge-Werkzeug im Quell-Repository behandelt werden.
main - Produktions-Branch, der Änderungen aus Pull Requests des Dev-Branches erhält
dev - Der Staging-Branch, der verwendet wird, um Commits anzunehmen und Änderungen zu validieren, bevor sie zum Master gepusht werden.
Mittlere bis große Teams
Bei Teams mit mehr als einigen wenigen Entwicklern kann eine komplexere Branching-Strategie hilfreich sein, um Codeänderungen besser zu bewerten und Merge-Konflikte zu vermeiden. PowerShell Universal bietet grundlegende Merge-Werkzeuge, aber es sind bessere Werkzeuge für diesen Zweck verfügbar, wie GitHub Pull Requests, GitLab Merge Requests und lokale Werkzeuge wie GitKraken.
In mittelgroßen Teams kann es wünschenswert sein, zusätzliche Feature-Branches zu haben, die bestimmte Änderungen in einem eigenen Branch isolieren. Beispielsweise könnte ein Entwickler einen neuen Satz von APIs zur Verwaltung von Azure in PowerShell Universal erstellen. Um Breaking Changes im Dev-Branch zu vermeiden, erstellen Entwickler ihren eigenen Feature-Branch, der alle ihre Änderungen enthält, bis er ausreichend fertig ist, um in den Entwicklungs-Branch gemergt zu werden.
Bei dieser Art von Konfiguration ist die lokale Entwicklung ideal, da die Entwickler auf ihrer lokalen PowerShell Universal-Instanz innerhalb ihres Feature-Branches arbeiten. Wenn das Feature abgeschlossen ist, erstellen sie einen Pull- oder Merge-Request im Quell-Repository, um die Änderungen in den Dev-Branch zu übernehmen. Die Tests werden im Dev-Branch abgeschlossen, bevor in die Produktion gemergt wird.
Ähnlich wie bei einer main\dev-Branching-Strategie sind alle PowerShell Universal-Instanzen isoliert und teilen keine Datenbank oder keinen Scheduler.
Sobald ein Satz von Features für die Produktion bereit ist, wird ein Pull- oder Merge-Request von dev in den main-Branch erstellt.
main - Produktions-Branch, der nur Änderungen von dev erhält
dev - Staging-Branch, der Änderungen von Feature-Branches erhält, aber nicht direkt geändert wird
feature - Feature-Branch, in den Entwickler direkt committen und der bei Bereitschaft in dev gemergt wird
Abhängig von der Komplexität Ihrer Umgebung kann es ratsam sein, in der Produktion Deployments anstelle von Git zu verwenden. Weitere Informationen finden Sie im Abschnitt Große Teams weiter unten.
Große Teams
In großen Teams empfehlen wir, git für Entwicklungszwecke zu verwenden, aber Deployments oder ein ähnliches Konzept für die Produktion einzusetzen.
Deployments stellen unveränderliche Konfigurationspakete bereit, die in untergeordneten Umgebungen ausführlich getestet wurden. Mit Deployments können Sie wählen, wie Sie Ihren Code entwickeln und verwalten, und das Ergebnis einfach in Ihren Entwicklungs-, Staging-, QA- und Produktionsumgebungen veröffentlichen. Dadurch wird sichergestellt, dass der gesamte Code gut getestet ist, bevor er auf Ihren kritischen Systemen bereitgestellt wird.
Sie können automatisierte Workflows wie GitHub Actions verwenden, um Ihre Deployments zu veröffentlichen, ohne ein System manuell aktualisieren zu müssen.
Git-Hosting
PowerShell Universal unterstützt jede standardmäßige git-Hosting-Lösung. Unsere Kunden verwenden häufig die folgenden:
GitHub
GitHub Enterprise
GitLab
Bitbucket
Azure DevOps
Dies sind zwar die gängigsten Plattformen, wir unterstützen jedoch jede Plattform, die das git-Protokoll beherrscht.
Beispiel: Gitea
Sie können auch einfache, selbst gehostete Lösungen wie Gitea verwenden. Hier ist ein Beispiel dafür, wie Sie einen Gitea-Docker-Container einfach für die Verwendung mit PowerShell Universal konfigurieren.
Zuletzt aktualisiert
War das hilfreich?