> 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 Synchronisieren Sie die PowerShell Universal-Konfiguration mit einem entfernten Git-Repository – dies umfasst Branches, Authentifizierung, Sync-Verhalten und die Fehlerbehebung bei Konflikten. {% hint style="info" %} Die Git-Integration erfordert eine [Lizenz](https://store.devolutions.net/package#psu). {% endhint %} PowerShell Universal kann die Konfigurationsskripte mit einem entfernten Git-Repository synchronisieren. ## Konfiguration ### Admin-Konsole Die Git-Synchronisierung kann in der Datenbank konfiguriert werden, indem die Einstellungen in der Admin-Konsole angepasst werden. Dies ist der bevorzugte Ansatz. Der Vorteil besteht darin, 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 Source Control > Git > Settings. Dort können Sie auf die Schaltfläche Create Git Settings klicken. {% hint style="info" %} In PowerShell Universal 5.x und höher werden Git-Anmeldeinformationen (Remote URL, Username und Personal Access Token) in der SQL-Datenbank gespeichert und nicht in appsettings.json. Wenn Sie diese Einstellungen in der Benutzeroberfläche bearbeiten, wird die Datenbank aktualisiert. Wenn Sie Git-Einstellungen bearbeiten und anschließend auf OK klicken, kann PSU gespeicherte Anmeldeinformationen löschen, auch 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 Instanz von PSU 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 die Einstellungen für die Git-Synchronisierung in der Datenbank festgelegt sind, werden die in appsettings.json definierten Einstellungen ignoriert. ## Einstellungen für die Git-Synchronisierung ### Branch Standardmäßig synchronisiert PowerShell Universal mit dem Branch `master`. 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: {% code collapsedlinecount="10" %} ```powershell git fetch git branch --set-upstream-to=origin/main main git pull ``` {% endcode %} ### Remote Remotes sind nicht erforderlich. Wenn kein Remote angegeben ist, wird das Git-Repository lokal im Repository-Verzeichnis gespeichert. Wenn ein Remote angegeben ist, synchronisiert PowerShell Universal mit dem Remote. Für den Zugriff auf dieses Remote sind korrekte Anmeldeinformationen erforderlich. #### Azure DevOps-URL-Format Azure DevOps-Repositories sollten das moderne `dev.azure.com`-URL-Format anstelle der älteren Domain `visualstudio.com` verwenden: **Korrektes Format:** {% code collapsedlinecount="10" %} ``` https://dev.azure.com///_git/ ``` {% endcode %} **Beispiele:** {% code collapsedlinecount="10" %} ``` https://dev.azure.com/mycompany/MyProject/_git/PowerShellUniversal https://dev.azure.com/mycompany/MyProject/_git/PSU%20Scripts ``` {% endcode %} Wenn Ihr Repository-Name Leerzeichen enthält, sollten diese in der URL als `%20` codiert werden. Vermeiden Sie URLs mit der älteren Domain `visualstudio.com`, da sie zu Weiterleitungsschleifen oder Authentifizierungsfehlern mit dem Fehler "too many redirects or authentication replays" führen können. Für Azure DevOps muss Ihr Personal Access Token den Bereich **Code (Read & Write)** besitzen. Fein granulare Tokens funktionieren, es werden jedoch klassische PATs empfohlen, um die Kompatibilität über PSU-Versionen hinweg sicherzustellen. **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-Authentifizierung mit dem PAT als Passwort verwendet. Einige GitLab-Konfigurationen erwarten stattdessen einen `Private-Token`-Header. ### Authentifizierung Sie müssen die Authentifizierung für Ihr entferntes Git-Repository konfigurieren. Wir empfehlen ein Personal Access Token. ### Externer Git-Client Sie können anstelle der in PowerShell Universal integrierten Bibliothek einen externen Git-Client verwenden. Dies bietet Ihnen zusätzliche Konfigurationsoptionen, wie etwa die Verwendung der SSH-Authentifizierung. PowerShell Universal verwendet bei dieser Methode keine konfigurierten Benutzernamen, Passwörter oder PATs. Ein Git-Client muss installiert sein. #### 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 Source Control > SSH Keys. Generieren Sie einen neuen SSH-Schlüssel. Klicken Sie anschließend auf die Kopierschaltflä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 zum Beispiel dieser [GitHub-Anleitung](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 für das Klonen Ihres Repositorys die SSH-URL ausgewählt ist. {% code collapsedlinecount="10" %} ``` git@github.com:ironmansoftware/psu-devo ``` {% endcode %} #### Anmeldeinformationen festlegen Bei Verwendung des externen Git-Clients sind Sie dafür verantwortlich, die Anmeldeinformationen zu konfigurieren, bevor eine Synchronisierung durchgeführt wird. 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. Dabei 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. {% code collapsedlinecount="10" %} ```batch git config --global credential.helper store echo "https://${username}:${password_or_access_token}@github.com" > ~/.git-credentials ``` {% endcode %} Sie können Anmeldeinformationen auch direkt in der an PowerShell Universal übergebenen URL speichern. {% code collapsedlinecount="10" %} ``` https://adam:APP_TOKEN@github.com/myOrg/myRepo.git ``` {% endcode %} #### 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: {% code collapsedlinecount="10" %} ``` https://username:PAT@github.com/devolutions/powershell-universal ``` {% endcode %} #### Beispiel: SSH und GitHub Zuerst müssen Sie Ihren lokalen ssh-agent und Ihr GitHub-Konto mit SSH-Schlüsseln konfigurieren. Sie können der [Anleitung hier](https://docs.github.com/en/authentication/connecting-to-github-with-ssh) folgen. Als Nächstes geben Sie in PowerShell Universal eine SSH-URI als Git-Remote-URL an. Für die Verbindung wird der konfigurierte SSH-Schlüssel verwendet. {% code collapsedlinecount="10" %} ``` git@github.com:devolutions/powershell-universal.git ``` {% endcode %} #### 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 Der manuelle Modus erfordert, dass 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 wieder 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 in der Admin-Konsole oder in `appsettings.json` festgelegt werden. {% code collapsedlinecount="10" %} ```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 }, ``` {% endcode %} ### 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; PowerShell Universal erstellt dann ein neues Repository. Wenn Sie ein neues Git-Repository befüllen, müssen Sie sicherstellen, dass das Remote keine Dateien enthält. Es sollte ein vollständig leeres (bare) Repository sein. Wählen Sie zum Beispiel beim Erstellen eines Repositorys 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 sie in der `appsettings.json`-Datei von PowerShell Universal angeben. Sobald Sie den Branch, die Git-Remote-URL und die Anmeldeinformationen haben, können Sie sie in Ihrer `appsettings.json`-Datei angeben, und das Git-Remote wird mit Ihren lokalen Dateien befü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. Dateien im Ordner führen dazu, dass die Git-Synchronisierung fehlschlägt und sich nicht mehr erholen kann. 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. Als Erstes klont der Dienst das Repository und konfiguriert es lokal. ### Timeout der Git-Synchronisierung Die Git-Synchronisierung läuft in ein Timeout, wenn sie das Remote nach 60 Minuten nicht erreichen kann. Dies lässt Zeit für das 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. {% code collapsedlinecount="10" %} ```json "Data" : { "GitSyncTimeout": 30 } ``` {% endcode %} ### Sync-Intervall **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`: {% code collapsedlinecount="10" %} ```json "GitSyncInterval": 300 ``` {% endcode %} Dadurch würde das Sync-Intervall auf 5 Minuten geändert. Niedrigere Werte erhöhen die Synchronisierungsfrequenz, können aber bei großen Repositories oder langsamen Netzwerken die Leistung beeinträchtigen. Ein zu niedriger Wert (unter 30 Sekunden) wird für Produktionsumgebungen nicht empfohlen. ### Fehlerbehebung #### Azure DevOps: "Too many redirects or authentication replays" Dieser Fehler weist in der Regel auf eines der folgenden Probleme hin: * **Veraltetes URL-Format:** Stellen Sie sicher, dass Sie `https://dev.azure.com///_git/` anstelle der älteren Domain `visualstudio.com` verwenden * **Ungültiger PAT-Bereich:** Ihr Personal Access Token muss in Azure DevOps über die Berechtigungen **Code (Read & Write)** 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 sie `dev.azure.com` verwendet 2. Generieren Sie ein neues PAT mit dem Bereich Code (Read & Write) 3. Aktivieren Sie **Use External Git Client** und installieren Sie Git für 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: {% code collapsedlinecount="10" %} ```powershell git fetch git branch --set-upstream-to=origin/main main git pull ``` {% endcode %} Ersetzen Sie `main` durch Ihren tatsächlichen Branch-Namen. Klicken Sie anschließend in PSU auf **Synchronize Now**. #### Die Git-Synchronisierung stoppt nach dem Ändern von Einstellungen in der Benutzeroberfläche **Symptome:** Nach dem Bearbeiten der Git-Einstellungen (Remote-URL, Anmeldeinformationen, Sync-Intervall 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 der 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 erneut unter **Source Control > Git > Settings** ein 2. Klicken Sie auf **OK**, um zu speichern 3. Wiederholen Sie diesen Vorgang in Umgebungen mit mehreren Knoten **auf jedem Knoten** – 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 lastverteilten oder hochverfügbaren Konfiguration 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 -Agents dieselbe Version ausführen * **Firewall-Regeln:** Agents kommunizieren mit dem PSU-Server über gRPC an den Ports **5000** (HTTP) oder **5001** (HTTPS) * **Proxy- oder WebSocket-Blockierung:** Unternehmens-Proxys können gRPC-Verkehr 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 alle Knoten dieselbe PSU-Version ausführen 2. Prüfen Sie, ob die Firewall-Regeln Verkehr an 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` zur Überprüfung aus) * Überprüfen Sie den ausgehenden Netzwerkzugriff auf das Git-Remote * Binden Sie persistente Volumes für `/data` oder `%ProgramData%\UniversalAutomation` ein, um den Git-Zustand ü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-Befehlszeilentool nicht auf dem Server installiert ist und Sie auf Upstream-Tracking-Fehler stoßen, können Sie die Repository-Konfiguration direkt über den Dateibrowser 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): {% code collapsedlinecount="10" %} ```ini [branch "main"] remote = origin merge = refs/heads/main ``` {% endcode %} 3. Klicken Sie auf **Speichern** 4. Kehren Sie zu **Source Control > Git > Settings** zurück und klicken Sie auf **Synchronize Now** Dieser Ansatz ermöglicht es Ihnen, Upstream-Tracking ohne `git`-Befehle zu konfigurieren, 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 die Ä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: {% code collapsedlinecount="10" %} ```json "SystemLogLevel": "Debug" ``` {% endcode %} 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 eintragen:** Bei beendetem Dienst können Sie die Git-Felder in `appsettings.json` direkt eintragen: {% code collapsedlinecount="10" %} ```json "GitRemote": "https://dev.azure.com/org/project/_git/repo", "GitUserName": "any", "GitPassword": "your-PAT-here", "GitBranch": "main" ``` {% endcode %} Starten Sie den Dienst neu und überprüfen Sie, ob die Einstellungen unter **Source Control > Git > Settings** erscheinen. Wenn sie erneut verschwinden, zeigen die Debug-Protokolle an, ob ein Berechtigungsproblem, 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 eine Verbindung zu lokal gehosteten Git-Repositorys hergestellt wird. 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 manuell hinzufügen. Folgendes ist 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 in 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 .git-Ordner 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-Verlauf- und Statusseite Die Registerkarte Verlauf 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. ### Git-Synchronisierung testen Der beste Weg, um sicherzustellen, dass Ihre Git-Synchronisierung ordnungsgemäß funktioniert, ist ein Klick auf die Schaltfläche Synchronize Now. 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, die SHA des Commits und eine Liste der Änderungen zwischen dieser SHA und der vorherigen. Wenn Dateien in einem geänderten Zustand sind, können Sie die Diffs mit dem Datei-Diff-Tool anzeigen. ### 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. Sie sehen eine Liste der Änderungen, die auf der Git-Commit-Seite in 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: * Aktuelle (lokale) Version – zwischen `<<<<<<< HEAD` und `=======`: `"That endpoint"` * Eingehende (Remote-)Version – zwischen `=======` und `>>>>>>> main`: `"This endpoint"` Bearbeiten Sie den Text, um den Konflikt zu entfernen. 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. Dadurch wird der Merge-Konflikt gelöst und in das Remote gepusht. ## Verhalten der Git-Synchronisierung ### Zwei-Wege Standardmäßig funktioniert die Git-Synchronisierung in beide Richtungen. Wenn Sie Änderungen in der PSU-Adminkonsole vornehmen, werden diese Änderungen committet und mit dem konfigurierten Remote synchronisiert. Alle Änderungen, die im Remote vorgenommen werden, werden lokal abgerufen. Wenn Sie die Git-Synchronisierung mit einem bereits vorhandenen Git-Remote einrichten, werden die Änderungen abgerufen und lokal synchronisiert. Sie dürfen keine lokalen Änderungen haben. Wenn Sie die Git-Synchronisierung mit einem leeren Repository (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 Adminkonsole und die Management-API schreibgeschützt. Das PowerShell Universal-System ruft Änderungen vom Remote ab, pusht oder committet jedoch niemals lokal. {% code collapsedlinecount="10" %} ```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": "" }, ``` {% endcode %} ### Nur Push Im Nur-Push-Git-Synchronisierungsmodus werden keine Änderungen vom Remote abgerufen. Alle lokal vorgenommenen Änderungen werden zum Remote gepusht. Die Konsole ist nicht schreibgeschützt. Diese Konfiguration ist nützlich für Szenarien, in denen Sie einen Computer haben, der für die Source-of-Truth-Konfiguration eines Pools schreibgeschützter Server verwendet wird. {% code collapsedlinecount="10" %} ```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": "" }, ``` {% endcode %} ## 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. {% code collapsedlinecount="10" %} ```javascript "Data": { "RepositoryPath": "%ProgramData%\\UniversalAutomation\\Repository", "ConnectionString": "%ProgramData%\\UniversalAutomation\\database.db", "GitRemote": "https://github.com/myorg/myrepo.git", "GitUserName": "any", "GitPassword": "MYPAT----------------" }, ``` {% endcode %} ### GitHub Fine-Grained Tokens In GitHub können Sie ein Fine-Grained Token abrufen, indem Sie oben rechts auf Ihren Avatar klicken und 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 auf nur 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 und 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 es sich mit einem Benutzernamen und einem Passwort authentifiziert. Legen Sie den Benutzernamen und das Passwort entweder mit der Datei `appsettings.json` oder einer anderen Konfigurationsmethode fest. {% code collapsedlinecount="10" %} ```javascript "Data": { "RepositoryPath": "%ProgramData%\\UniversalAutomation\\Repository", "ConnectionString": "%ProgramData%\\UniversalAutomation\\database.db", "GitRemote": "https://github.com/myorg/myrepo.git", "GitUserName": "myusername", "GitPassword": "mypassword" }, ``` {% endcode %} ## Häufige Fehler #### Git synchronization failed. unknown certificate lookup failure: 16777280 Die lib2gitsharp-Bibliothek 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: {% code collapsedlinecount="10" %} ``` 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. ``` {% endcode %} #### „too many redirects“ oder Authentifizierungswiederholungen 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 anschließend ein anderes Dienstkonto für den Dienst festgelegt wurde. Da die Zugriffskontrollen nicht übereinstimmen, greift Git nicht auf den Ordner zu. Dies ist eine Sicherheitsfunktion 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. {% code collapsedlinecount="10" %} ``` [safe] directory = C:\ProgramData\UniversalAutomation\Repository ``` {% endcode %} Die globale Konfiguration finden Sie unter: `C:\Program Files\git\etc\gitconfig` ## Vorteile von Git Sync gegenüber manueller Git-Synchronisierung Es ist möglich, ein Repository manuell per Git zu synchronisieren. PowerShell Universal verwendet beim Umgang mit Git sehr einfache Befehle. Alle Änderungen, die über die Adminkonsole oder die API an PowerShell Universal vorgenommen werden, lösen ein `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 zunächst ein `git pull` durch, um sicherzustellen, dass wir die neueste Version der Dateien auf dem 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. Eine Funktion der Git-Synchronisierung ist jedoch, dass sie den Commit analysiert, um sicherzustellen, dass nur Dateien neu geladen werden, die während der Synchronisierung geändert wurden. Dadurch wird verhindert, dass Dashboards automatisch bereitgestellt werden, wenn sie sich nicht geändert haben, oder dass API-Dienste neu gestartet werden, wenn Umgebungen nicht aktualisiert wurden. Es gibt hier also einen Leistungsgewinn. Das andere Problem ist, dass aufgrund der Art und Weise, wie PowerShell Universal Dateien überwacht (mit einem `FileSystemWatcher`) und 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 bestimmen, wie Änderungen von einem Branch in einen anderen verschoben werden. Die Nutzung verschiedener Arten von Branching-Strategien in PowerShell Universal kann sicherstellen, dass Teams unterschiedlicher Größe effektiv gemeinsam auf 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ückzusetzen. Benutzer greifen direkt auf PowerShell Universal zu, um Änderungen vorzunehmen, oder committen Änderungen in den einzelnen Branch von lokalen Klonen des Repository-Verzeichnisses mit einem Tool 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 als vorteilhaft empfinden, einen Staging- oder Dev-Branch zu verwenden. 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 unterschiedliche Datenbank und einen unterschiedlichen 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 abzurufen, aber niemals von der Plattform zu pushen. Dies verhindert auch die meisten Merge-Konflikte, da diese im Dev-Branch oder über das Merge-Tool im Quell-Repository behandelt werden. * main – Produktions-Branch, der Änderungen aus Pull Requests des Dev-Branches erhält * dev – Der Staging-Branch, der zum Annehmen von Commits und zum Validieren von Änderungen verwendet wird, bevor sie in den 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-Tools, es gibt jedoch bessere Werkzeuge für diesen Zweck, wie GitHub Pull Requests, GitLab Merge Requests und lokale Tools wie GitKraken. In mittelgroßen Teams kann es wünschenswert sein, zusätzliche Feature-Branches zu haben, die bestimmte Änderungen in einem bestimmten Branch isolieren. Beispielsweise erstellt ein Entwickler möglicherweise eine neue Reihe von APIs zur Verwaltung von Azure in PowerShell Universal. Um Breaking Changes im Dev-Branch zu vermeiden, erstellen Entwickler ihren eigenen Feature-Branch, der alle ihre Änderungen enthält, bis er vollständig genug 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 weiterhin Lizenzen erforderlich. {% endhint %} In dieser Art von Konfiguration ist die lokale Entwicklung ideal, da die Entwickler an ihrer lokalen PowerShell Universal-Instanz innerhalb ihres Feature-Branches arbeiten. Wenn das Feature fertig ist, erstellen sie einen Pull- oder Merge-Request im Quell-Repository, um Änderungen in den Dev-Branch zu übernehmen. Das Testen wird 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 sich 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 unten. ### Große Teams In großen Teams empfehlen wir die Verwendung von Git zu Entwicklungszwecken, aber die Verwendung von Deployments oder einem ähnlichen Konzept für die Produktion. [Deployments ](/powershell-universal/de/config/deployments.md)bieten unveränderliche Konfigurationspakete, die in Umgebungen niedrigerer Ebenen gründlich 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, aber wir unterstützen jede Plattform, die das Git-Protokoll spricht. ### 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.