> For the complete documentation index, see [llms.txt](https://docs.devolutions.net/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.devolutions.net/powershell-universal/de/config/git.md). # Git {% hint style="info" %} Die Git-Integration erfordert eine [Lizenz](https://store.devolutions.net/package#psu). {% endhint %} 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.

Dialog „Git Settings“

{% hint style="info" %} In PowerShell Universal 5.x und höher werden Git-Anmeldeinformationen (Remote-URL, Benutzername und Personal Access Token) in der SQL-Datenbank gespeichert und nicht in appsettings.json. Das Bearbeiten dieser Einstellungen in der Benutzeroberfläche aktualisiert die Datenbank. Wenn Sie Git-Einstellungen bearbeiten und dann auf OK klicken, kann PSU gespeicherte Anmeldeinformationen löschen, selbst wenn die Felder gefüllt erscheinen. In Umgebungen mit mehreren Knoten müssen Sie die Anmeldeinformationen nach Änderungen auf jedem Knoten einzeln erneut eingeben. {% endhint %} ### appsettings.json Sie können auch die [Konfigurationseinstellungen](/powershell-universal/de/config/settings.md) 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: 1. Öffnen Sie PowerShell in `%ProgramData%\UniversalAutomation\Repository` (oder im konfigurierten Repository-Pfad) 2. Führen Sie aus: ```powershell git fetch git branch --set-upstream-to=origin/main main git pull ``` ### 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:** ``` https://dev.azure.com///_git/ ``` **Beispiele:** ``` https://dev.azure.com/mycompany/MyProject/_git/PowerShellUniversal https://dev.azure.com/mycompany/MyProject/_git/PSU%20Scripts ``` 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](https://docs.github.com/en/authentication/connecting-to-github-with-ssh) 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. ``` git@github.com:ironmansoftware/psu-devo ```

GitHub-SSH-URL

#### 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. ```batch git config --global credential.helper store echo "https://${username}:${password_or_access_token}@github.com" > ~/.git-credentials ``` Sie können Anmeldeinformationen auch direkt in der an PowerShell Universal übergebenen URL speichern. ``` https://adam:APP_TOKEN@github.com/myOrg/myRepo.git ``` #### 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: ``` https://username:PAT@github.com/ironmansoftware/universal ``` #### 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](https://docs.github.com/en/authentication/connecting-to-github-with-ssh) 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. ``` git@github.com:ironmansoftware/universal.git ``` #### SSL-Zertifikatsproblem {% hint style="warning" %} SSL Certificate problem: unable to get local issuer certificate {% endhint %} Wenn Sie unter Windows arbeiten und ein SSL-Zertifikatsproblem erhalten, müssen Sie möglicherweise sicherstellen, dass Sie die [schannel-Unterstützung aktiviert haben](https://stackoverflow.com/questions/23885449/unable-to-resolve-unable-to-get-local-issuer-certificate-using-git-on-windows). #### Persistenz von Anmeldeinformationen {% hint style="warning" %} Unable to persist credentials with the 'wincredman' credential store. {% endhint %} 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](https://github.com/GitCredentialManager/git-credential-manager/issues/633). ### 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](#dealing-with-conflicts). Der manuelle Modus kann in den Git-Einstellungen innerhalb der Admin-Konsole oder in `appsettings.json` festgelegt werden. ```json "Data": { "RepositoryPath": "%ProgramData%\\UniversalAutomation\\Repository", "ConnectionString": "filename=%ProgramData%\\UniversalAutomation\\database.db;upgrade=true", "RunMigrations": true, "GitRemote": "", "GitUserName": "", "GitPassword": "", "GitBranch": "", "GitSyncBehavior": "TwoWay", "GitInitializeBehavior": "", "GitSyncInterval": "1", "ConfigurationScript": "", "ExternalGitClient": false "Mode": "Manual" // Or Automatic }, ``` ### Methode eins: Lokale Dateien an das Remote pushen {% hint style="info" %} Der Standardspeicherort für das lokale Repository ist `C:\ProgramData\UniversalAutomation\Repository` {% endhint %} 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. ![](/files/oeF3uEMG5JTtIfDGhndK) Sobald das Repository erstellt wurde, können Sie die Git-Remote-URL abrufen und in der `appsettings.json`-Datei von PowerShell Universal angeben. ![](/files/9IdRrUPFhwrvzNMBQ0b6) 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 {% hint style="info" %} Der Standardspeicherort für das lokale Repository ist `C:\ProgramData\UniversalAutomation\Repository` {% endhint %} 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. ```json "Data" : { "GitSyncTimeout": 30 } ``` ### 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`: ```json "GitSyncInterval": 300 ``` 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///_git/` anstelle der älteren `visualstudio.com`-Domäne verwenden * **Ungü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 `%20` codiert sind **Lösung:** 1. Aktualisieren Sie die Remote-URL, sodass `dev.azure.com` verwendet wird 2. Generieren Sie ein neues PAT mit dem Scope Code (Read & Write) 3. 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: ```powershell git fetch git branch --set-upstream-to=origin/main main git pull ``` 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:** 1. Geben Sie das Personal Access Token unter **Settings → Git** erneut ein 2. Klicken Sie auf **OK**, um zu speichern 3. Wiederholen Sie diesen Vorgang in Umgebungen mit mehreren Knoten **auf jedem Knoten** – die Anmeldeinformationen müssen auf jedem Server einzeln eingegeben werden 4. 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:** 1. Überprüfen Sie, ob auf allen Knoten die gleiche PSU-Version ausgeführt wird 2. Prüfen Sie, ob die Firewall-Regeln Traffic auf den Ports 5000/5001 zulassen 3. Testen Sie die gRPC-Konnektivität zwischen den Knoten 4. Wenn Sie einen Proxy verwenden, konfigurieren Sie die Umgebungsvariablen `http_proxy` und `https_proxy` für das PSU-Dienstkonto #### Docker- und containerisierte Bereitstellungen * Stellen Sie sicher, dass das Container-Image `git` enthält (führen Sie `git --version` aus, um dies zu überprüfen) * Überprüfen Sie den ausgehenden Netzwerkzugriff auf das Git-Remote * Binden Sie persistente Volumes für `/data` oder `%ProgramData%\UniversalAutomation` ein, um den Git-Status über Neustarts hinweg zu erhalten * Wenn 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: 1. Navigieren Sie zu **Platform → Configuration → Repository → .git → config** 2. Fügen Sie die folgenden Zeilen hinzu (passen Sie den Branch-Namen an Ihr Repository an): ```ini [branch "main"] remote = origin merge = refs/heads/main ``` 3. Klicken Sie auf **Speichern** 4. 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.json` in älteren Versionen) manuell zu bearbeiten * Fü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:** 1. Beenden Sie den PowerShell Universal-Dienst 2. Bearbeiten Sie `appsettings.json` und setzen Sie: ```json "SystemLogLevel": "Debug" ``` 3. Speichern Sie und starten Sie den Dienst neu 4. Versuchen Sie erneut, die Git-Einstellungen zu speichern 5. Prüfen Sie `%PROGRAMDATA%\PowerShellUniversal\systemLog.txt` auf 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: ```json "GitRemote": "https://dev.azure.com/org/project/_git/repo", "GitUserName": "any", "GitPassword": "your-PAT-here", "GitBranch": "main" ``` 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. {% hint style="warning" %} 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. {% endhint %} 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. ![](/files/6KSonixSuVtUyDXzUgbg) ### Ä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. ![](/files/fETHoF81LtNp6yjfldIH) ### Umgang mit Konflikten {% hint style="info" %} Die Konfliktlösung ist nur im manuellen Git-Synchronisierungsmodus verfügbar. {% endhint %} 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. ```javascript "Data": { "RepositoryPath": "%ProgramData%\\UniversalAutomation\\Repository", "ConnectionString": "%ProgramData%\\UniversalAutomation\\database.db", "DatabaseType": "LiteDB", "GitRemote": "https://github.com/myorg/myrepo.git", "GitUserName": "any", "GitPassword": "MYPAT----------------" "GitBranch": "dev", "GitSyncBehavior": "OneWay", "ConfigurationScript": "" }, ``` ### 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. ```json "Data": { "RepositoryPath": "%ProgramData%\\UniversalAutomation\\Repository", "ConnectionString": "%ProgramData%\\UniversalAutomation\\database.db", "DatabaseType": "LiteDB", "GitRemote": "https://github.com/myorg/myrepo.git", "GitUserName": "any", "GitPassword": "MYPAT----------------" "GitBranch": "dev", "GitSyncBehavior": "PushOnly", "ConfigurationScript": "" }, ``` ## 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. ```javascript "Data": { "RepositoryPath": "%ProgramData%\\UniversalAutomation\\Repository", "ConnectionString": "%ProgramData%\\UniversalAutomation\\database.db", "GitRemote": "https://github.com/myorg/myrepo.git", "GitUserName": "any", "GitPassword": "MYPAT----------------" }, ``` ### 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. ![](/files/XBKqHJu2r1E0pJMawIMF) 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. ```javascript "Data": { "RepositoryPath": "%ProgramData%\\UniversalAutomation\\Repository", "ConnectionString": "%ProgramData%\\UniversalAutomation\\database.db", "GitRemote": "https://github.com/myorg/myrepo.git", "GitUserName": "myusername", "GitPassword": "mypassword" }, ``` ## 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](#external-git-client) und eine benutzerdefinierte Git-Konfiguration verwenden, um dies zu beheben. Einige gängige Optionen für die Git-HTTPS-Unterstützung sind: ``` http.sslVerify Whether to verify the SSL certificate when fetching or pushing over HTTPS. Can be overridden by the GIT_SSL_NO_VERIFY environment variable. http.sslCAInfo File containing the certificates to verify the peer with when fetching or pushing over HTTPS. Can be overridden by the GIT_SSL_CAINFO environment variable. http.sslCAPath Path containing files with the CA certificates to verify the peer with when fetching or pushing over HTTPS. Can be overridden by the GIT_SSL_CAPATH environment variable. ``` #### "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. ``` [safe] directory = C:\ProgramData\UniversalAutomation\Repository ``` 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. {% hint style="info" %} Jede Instanz von PowerShell Universal benötigt eine [Lizenz](/powershell-universal/de/licensing.md). In dieser Konfiguration wären zwei Lizenzen erforderlich. {% endhint %} 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. {% hint style="info" %} PowerShell Universal bietet [Entwicklerlizenzen](/powershell-universal/de/licensing.md), um zu vermeiden, dass für jeden Entwickler in Ihrem Team eine Lizenz erworben werden muss. Für die Produktions- und Staging-Umgebungen wären dennoch Lizenzen erforderlich. {% endhint %} 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 ](/powershell-universal/de/config/deployments.md)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](https://gitea.com) verwenden. Hier ist ein Beispiel dafür, wie Sie einen Gitea-Docker-Container einfach für die Verwendung mit PowerShell Universal konfigurieren. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.devolutions.net/powershell-universal/de/config/git.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.