> 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/fr/config/git.md). # Git {% hint style="info" %} L'intégration Git nécessite une [licence](https://ironmansoftware.com/pricing/powershell-universal). {% endhint %} PowerShell Universal est capable de synchroniser les scripts de configuration avec un référentiel git distant. ## Configuration ### Console d'administration La synchronisation Git peut être configurée dans la base de données en ajustant les paramètres dans la console d'administration. Il s'agit de l'approche recommandée. L'avantage est que lorsque vous connectez de nouvelles instances de PowerShell Universal à votre instance SQL, vous n'aurez pas à reconfigurer la synchronisation Git. Pour configurer la synchronisation Git, accédez à Paramètres \ Git dans la console d'administration. Vous pourrez cliquer sur le bouton Créer les paramètres Git.

Boîte de dialogue des paramètres Git

{% hint style="info" %} Dans PowerShell Universal 5.x et versions ultérieures, les informations d'identification Git (URL distante, nom d'utilisateur et jeton d'accès personnel) sont stockées dans la base de données SQL plutôt que dans appsettings.json. La modification de ces paramètres dans l'interface utilisateur met à jour la base de données. Si vous modifiez les paramètres Git puis cliquez sur OK, PSU peut effacer les informations d'identification stockées même si les champs semblent remplis. Dans les environnements à plusieurs nœuds, vous devez saisir à nouveau les informations d'identification sur chaque nœud individuellement après avoir effectué des modifications. {% endhint %} ### appsettings.json Vous pouvez également utiliser les [paramètres de configuration](/powershell-universal/fr/config/settings.md) pour configurer la synchronisation Git. Cela est utile si vous disposez d'une seule instance de PSU et souhaitez sauvegarder votre fichier appsettings.json. La modification des paramètres dans la console d'administration ne met pas à jour le fichier appsettings.json. Vous devrez le faire manuellement et redémarrer PowerShell Universal après avoir modifié les paramètres. Si des paramètres de synchronisation Git sont spécifiés dans la base de données, les paramètres définis dans appsettings.json sont ignorés. ## Paramètres de synchronisation Git ### Branche Par défaut, PowerShell Universal se synchronise avec la branche `master`. Si vous souhaitez utiliser une branche différente, spécifiez le paramètre `GitBranch` dans votre `appsettings.json`. #### Correction du suivi amont manquant Si vous rencontrez l'erreur **« There is no tracking information for the current branch »**, la branche locale n'est pas liée à la branche distante. Pour corriger cela : 1. Ouvrez PowerShell dans `%ProgramData%\UniversalAutomation\Repository` (ou le chemin de référentiel configuré) 2. Exécutez : ```powershell git fetch git branch --set-upstream-to=origin/main main git pull ``` ### Distant Les dépôts distants ne sont pas obligatoires. Si aucun distant n'est spécifié, le référentiel git est stocké localement dans le répertoire du référentiel. S'il est spécifié, PowerShell Universal se synchronisera avec le distant. Des informations d'identification appropriées sont requises pour accéder à ce distant. #### Format d'URL Azure DevOps Les référentiels Azure DevOps doivent utiliser le format d'URL moderne `dev.azure.com` plutôt que l'ancien domaine `visualstudio.com` : **Format correct :** ``` https://dev.azure.com///_git/ ``` **Exemples :** ``` https://dev.azure.com/mycompany/MyProject/_git/PowerShellUniversal https://dev.azure.com/mycompany/MyProject/_git/PSU%20Scripts ``` Si le nom de votre référentiel contient des espaces, ils doivent être encodés sous la forme `%20` dans l'URL. Évitez d'utiliser des URL avec l'ancien domaine `visualstudio.com`, car elles peuvent provoquer des boucles de redirection ou des échecs d'authentification avec l'erreur « too many redirects or authentication replays ». Pour Azure DevOps, votre jeton d'accès personnel doit avoir la portée **Code (lecture et écriture)**. Les jetons à granularité fine fonctionnent, mais les PAT classiques sont recommandés pour la compatibilité entre les versions de PSU. **Remarque pour les utilisateurs de GitLab :** Si votre instance GitLab nécessite une authentification par en-tête, vous devrez peut-être utiliser l'option Client Git externe et configurer des assistants d'informations d'identification Git, car le client Git intégré de PSU utilise l'authentification HTTP Basic avec le PAT comme mot de passe. Certaines configurations GitLab attendent un en-tête `Private-Token` à la place. ### Authentification Vous devrez configurer l'authentification auprès de votre référentiel git distant. Nous recommandons l'utilisation d'un jeton d'accès personnel. ### Client Git externe Vous pouvez choisir d'utiliser un client git externe plutôt que la bibliothèque intégrée à PowerShell Universal. Cela vous offre des options de configuration supplémentaires, comme l'utilisation de l'authentification SSH. PowerShell Universal n'utilisera pas le nom d'utilisateur, les mots de passe ou les PAT configurés lors de l'activation de cette méthode. Vous devrez avoir un client git installé. #### Utilisation des clés SSH Vous pouvez utiliser PowerShell Universal pour générer et gérer des clés SSH. Dans la console d'administration, cliquez sur Plateforme \ Clés SSH. Générez une nouvelle clé SSH. Ensuite, cliquez sur le bouton de copie à côté de la clé SSH pour obtenir la clé publique. Enregistrez la clé publique auprès du référentiel ou du compte cible. Par exemple, vous pouvez suivre le [guide GitHub](https://docs.github.com/en/authentication/connecting-to-github-with-ssh) ici. Dans la fenêtre Paramètres Git, sélectionnez la clé SSH que vous souhaitez utiliser avec la synchronisation Git. Lors de l'utilisation de clés SSH, assurez-vous que l'URL SSH est sélectionnée pour le clonage de votre référentiel. ``` git@github.com:ironmansoftware/psu-devo ```

URL SSH GitHub

#### Définition des informations d'identification Lors de l'utilisation du client git externe, vous êtes responsable de la configuration des informations d'identification avant d'effectuer une synchronisation. Vous pouvez configurer les informations d'identification via la configuration git ou l'URL transmise à PowerShell Universal. La commande suivante stockera les informations d'identification en texte brut sur le serveur PowerShell Universal. Vous devrez exécuter cette commande en tant qu'utilisateur du compte de service afin qu'il ait accès aux informations d'identification. Cela créera un fichier `.git-credentials` qui sera utilisé lors de l'authentification auprès de l'URL cible. Vous devrez peut-être modifier l'URL en fonction de votre dépôt git distant. ```batch git config --global credential.helper store echo "https://${username}:${password_or_access_token}@github.com" > ~/.git-credentials ``` Vous pouvez également stocker les informations d'identification directement dans l'URL fournie à PowerShell Universal. ``` https://adam:APP_TOKEN@github.com/myOrg/myRepo.git ``` #### Exemple : nom d'utilisateur et PAT Pour utiliser un client git externe et transmettre un nom d'utilisateur et un PAT pour l'authentification, vous pouvez les spécifier dans l'URL du dépôt git distant. Par exemple : ``` https://username:PAT@github.com/ironmansoftware/universal ``` #### Exemple : SSH et GitHub Tout d'abord, vous devrez configurer votre agent ssh local et votre compte GitHub avec des clés SSH. Vous pouvez suivre leur [guide ici](https://docs.github.com/en/authentication/connecting-to-github-with-ssh). Ensuite, vous fournirez un URI SSH pour l'URL du dépôt git distant dans PowerShell Universal. La clé SSH configurée sera utilisée pour la connexion. ``` git@github.com:ironmansoftware/universal.git ``` #### Problème de certificat SSL {% hint style="warning" %} SSL Certificate problem: unable to get local issuer certificate {% endhint %} Si vous exécutez sous Windows et rencontrez un problème de certificat SSL, vous devrez peut-être vous assurer d'avoir [activé le support schannel](https://stackoverflow.com/questions/23885449/unable-to-resolve-unable-to-get-local-issuer-certificate-using-git-on-windows). #### Persistance des informations d'identification {% hint style="warning" %} Unable to persist credentials with the 'wincredman' credential store. {% endhint %} Si vous êtes sous Windows et recevez une erreur concernant la persistance des informations d'identification dans wincredman, vous devrez peut-être définir la persistance des informations d'identification sur DAPI. Vous pouvez [apprendre comment faire ici](https://github.com/GitCredentialManager/git-credential-manager/issues/633). ### Mode manuel Le mode manuel exige que les utilisateurs qui modifient l'instance PowerShell Universal cliquent sur ***Modifier*** afin d'apporter des modifications au système.
Une fois les modifications terminées, l'utilisateur peut cliquer sur ***Enregistrer les modifications*** pour lancer une validation.
Sur la page de validation git, vous pouvez afficher les fichiers modifiés et saisir un message de validation.
Une fois les modifications validées, elles seront transmises au dépôt distant et le service commencera à se synchroniser à nouveau avec git. Il est également possible qu'un conflit de fusion git se produise à ce moment. Consultez [Résolution des conflits](#dealing-with-conflicts) pour plus d'informations. Le mode manuel peut être défini dans les paramètres git de la console d'administration ou dans `appsettings.json`. ```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 }, ``` ### Méthode 1 : Transmission des fichiers locaux vers le dépôt distant {% hint style="info" %} L'emplacement par défaut du référentiel local est `C:\ProgramData\UniversalAutomation\Repository` {% endhint %} Vous devez vous assurer que votre dossier local n'est pas un référentiel git préexistant. Votre répertoire de référentiel doit simplement être un dossier contenant vos fichiers PowerShell Universal. Si un dossier `.git` existe et que vous ne souhaitez pas utiliser ce référentiel, vous devez le supprimer et PowerShell Universal en créera un nouveau. Si vous remplissez un nouveau référentiel git, vous devez vous assurer que le dépôt distant ne contient aucun fichier. Il doit s'agir d'un référentiel complètement vide. Par exemple, lors de la création d'un référentiel sur GitHub, ne sélectionnez pas de licence ni de fichier readme.md à créer. ![](/files/CBZd6eBDPvIDT2HQpnGF) Une fois le référentiel créé, vous pouvez récupérer l'URL du dépôt git distant et la fournir au fichier `appsettings.json` de PowerShell Universal. ![](/files/yhPLdKVcc9CXYXHjacC6) Une fois que vous disposez de la branche, de l'URL du dépôt git distant et des informations d'identification, vous pouvez les fournir à votre fichier `appsettings.json` et le dépôt distant sera rempli avec vos fichiers locaux. ### Méthode 2 : Extraction depuis un dépôt git distant {% hint style="info" %} L'emplacement par défaut du référentiel local est `C:\ProgramData\UniversalAutomation\Repository` {% endhint %} Vous pouvez configurer PowerShell Universal pour extraire depuis un dépôt git distant. Dans cette configuration, vous devez vous assurer que votre dossier de référentiel local est complètement vide. Tout fichier présent dans le dossier entraînera l'échec de la synchronisation Git et l'empêchera de récupérer. Configurez le fichier `appsettings.json` pour inclure la branche, les informations d'identification et l'URL du dépôt git distant que vous clonez. Une fois les champs définis, vous pouvez démarrer le service PowerShell Universal. La première chose que le service fera sera de cloner le référentiel et de le configurer localement. ### Délai d'expiration de la synchronisation Git La synchronisation Git expirera si elle ne peut pas contacter le dépôt distant après 60 minutes. Cela laisse du temps pour télécharger de grands référentiels ou pour les délais liés à des réseaux lents. Vous pouvez constater que le service PowerShell Universal reste bloqué sur « Synchronizing with git » au démarrage pendant que le serveur attend que cela se produise. Si vous souhaitez réduire ce délai, vous pouvez utiliser le paramètre appsetting.json suivant. La valeur est en minutes. ```json "Data" : { "GitSyncTimeout": 30 } ``` ### Intervalle de synchronisation **Type :** Entier\ **Par défaut :** 60\ **appsettings.json :** `GitSyncInterval` L'intervalle, en secondes, entre les tentatives de synchronisation Git automatique lorsque la synchronisation automatique est activée. La valeur par défaut est de 60 secondes (1 minute). Pour ajuster la fréquence de synchronisation, modifiez `appsettings.json` : ```json "GitSyncInterval": 300 ``` Cela changerait l'intervalle de synchronisation à 5 minutes. Des valeurs plus faibles augmentent la fréquence de synchronisation, mais peuvent avoir un impact sur les performances dans les grands référentiels ou les réseaux lents. Il n'est pas recommandé de définir cette valeur trop basse (en dessous de 30 secondes) pour les environnements de production. ### Résolution des problèmes #### Azure DevOps : « Too many redirects or authentication replays » Cette erreur indique généralement l'un des problèmes suivants : * **Format d'URL hérité :** Assurez-vous d'utiliser `https://dev.azure.com///_git/` au lieu de l'ancien domaine `visualstudio.com` * **Portée de PAT non valide :** Votre jeton d'accès personnel doit avoir les autorisations **Code (lecture et écriture)** dans Azure DevOps * **Informations d'identification expirées :** Générez un nouveau PAT et saisissez-le à nouveau dans les paramètres Git de PSU * **Espaces encodés :** Si le nom de votre référentiel contient des espaces, assurez-vous qu'ils sont encodés sous la forme `%20` dans l'URL **Résolution :** 1. Mettez à jour l'URL distante pour utiliser `dev.azure.com` 2. Générez un nouveau PAT avec la portée Code (lecture et écriture) 3. Activez **Utiliser le client Git externe** et installez Git pour Windows si le client intégré continue d'échouer #### Suivi amont manquant **Erreur :** « There is no tracking information for the current branch » **Cause :** La branche Git locale n'est pas configurée pour suivre une branche distante. **Résolution :** Ouvrez PowerShell dans le répertoire du référentiel et exécutez : ```powershell git fetch git branch --set-upstream-to=origin/main main git pull ``` Remplacez `main` par le nom de votre branche réelle. Cliquez ensuite sur **Synchroniser maintenant** dans PSU. #### La synchronisation Git s'arrête après la modification des paramètres dans l'interface utilisateur **Symptômes :** Après avoir modifié les paramètres Git (URL distante, informations d'identification, intervalle de synchronisation, etc.) dans l'interface utilisateur de PSU et cliqué sur OK, la synchronisation cesse de fonctionner même si les paramètres semblent corrects. **Cause :** Dans PSU 5.x, les informations d'identification Git sont stockées dans la base de données SQL. Toute modification apportée aux paramètres Git via l'interface utilisateur peut effacer les informations d'identification stockées, même si le champ du mot de passe semble encore rempli dans le formulaire. **Résolution :** 1. Saisissez à nouveau le jeton d'accès personnel dans **Paramètres → Git** 2. Cliquez sur **OK** pour enregistrer 3. Dans les environnements à plusieurs nœuds, **répétez cette procédure sur chaque nœud** — les informations d'identification doivent être saisies individuellement sur chaque serveur 4. Cliquez sur **Synchroniser maintenant** pour vérifier que la synchronisation fonctionne à nouveau Le système ne propage pas automatiquement les informations d'identification entre les nœuds dans une configuration à charge équilibrée ou à haute disponibilité. #### Problèmes d'agent et de réseau **Symptômes :** La synchronisation fonctionne sur un nœud mais échoue sur les autres, ou vous voyez des erreurs `RpcException` ou « service is unavailable » dans les journaux. **Causes courantes :** * **Inadéquation de version :** Assurez-vous que tous les serveurs et agents PSU exécutent la même version * **Règles de pare-feu :** Les agents communiquent avec le serveur PSU via gRPC sur les ports **5000** (HTTP) ou **5001** (HTTPS) * **Blocage de proxy ou WebSocket :** Les proxys d'entreprise peuvent bloquer ou inspecter le trafic gRPC ; configurez git pour utiliser le proxy ou activez le client Git externe **Résolution :** 1. Vérifiez que tous les nœuds exécutent la même version de PSU 2. Vérifiez que les règles de pare-feu autorisent le trafic sur les ports 5000/5001 3. Testez la connectivité gRPC entre les nœuds 4. Si vous utilisez un proxy, configurez les variables d'environnement `http_proxy` et `https_proxy` pour le compte de service PSU #### Docker et déploiements conteneurisés * Assurez-vous que l'image du conteneur inclut `git` (exécutez `git --version` pour vérifier) * Vérifiez l'accès réseau sortant vers le dépôt git distant * Montez des volumes persistants pour `/data` ou `%ProgramData%\UniversalAutomation` pour préserver l'état git entre les redémarrages * Si la synchronisation échoue silencieusement, vérifiez les journaux du conteneur pour les erreurs git ou réseau #### Modification de .git/config sans CLI Git Si l'outil de ligne de commande Git n'est pas installé sur le serveur et que vous rencontrez des erreurs de suivi amont, vous pouvez modifier directement la configuration du référentiel via le navigateur de fichiers de PSU : 1. Accédez à **Plateforme → Configuration → Référentiel → .git → config** 2. Ajoutez les lignes suivantes (ajustez le nom de la branche pour correspondre à votre référentiel) : ```ini [branch "main"] remote = origin merge = refs/heads/main ``` 3. Cliquez sur **Enregistrer** 4. Revenez à **Paramètres → Git** et cliquez sur **Synchroniser maintenant** Cette approche vous permet de configurer le suivi amont sans avoir besoin de commandes `git`, ce qui est particulièrement utile lorsque Git pour Windows n'est pas installé ou lorsque vous exécutez sous des comptes de service restreints. #### Les paramètres Git ne persistent pas Si les modifications apportées aux paramètres Git ne sont pas enregistrées ou sont annulées immédiatement après avoir cliqué sur OK : **Vérifiez les autorisations du système de fichiers :** * Arrêtez le service PowerShell Universal * Essayez de modifier manuellement `%ProgramData%\PowerShellUniversal\appsettings.json` (ou `%ProgramData%\UniversalAutomation\appsettings.json` dans les versions plus anciennes) * Ajoutez une ligne de commentaire, enregistrez et rouvrez le fichier pour vérifier que vos modifications persistent * Si les modifications sont annulées, vérifiez si un logiciel antivirus, des objets de stratégie de groupe (GPO) ou des autorisations NTFS bloquent les écritures dans le répertoire de données PSU **Activez la journalisation de débogage pour la résolution des problèmes :** 1. Arrêtez le service PowerShell Universal 2. Modifiez `appsettings.json` et définissez : ```json "SystemLogLevel": "Debug" ``` 3. Enregistrez et redémarrez le service 4. Essayez d'enregistrer les paramètres Git à nouveau 5. Examinez `%PROGRAMDATA%\PowerShellUniversal\systemLog.txt` pour les erreurs liées aux écritures de configuration **Remplissez manuellement les paramètres Git :** Avec le service arrêté, vous pouvez directement remplir les champs Git dans `appsettings.json` : ```json "GitRemote": "https://dev.azure.com/org/project/_git/repo", "GitUserName": "any", "GitPassword": "your-PAT-here", "GitBranch": "main" ``` Redémarrez le service et vérifiez que les paramètres apparaissent dans **Paramètres → Git**. S'ils disparaissent à nouveau, les journaux de débogage indiqueront si un problème d'autorisation, un logiciel de protection des points de terminaison ou une erreur de validation de configuration est à l'origine de la réinitialisation. ### unknown certificate lookup failure: 16777280 Lors de l'utilisation de la bibliothèque git intégrée, vous pouvez rencontrer des problèmes de certificat lors de la connexion à des référentiels git hébergés localement. Dans cette configuration, nous recommandons d'utiliser le client git externe pour bénéficier d'un meilleur support pour la configuration du processus de recherche de certificat. ## Fichiers inclus Les fichiers inclus dans une synchronisation Git sont tous les fichiers présents dans le référentiel local. Cela inclut les fichiers de configuration PS1, les fichiers XML de pages et tous les autres fichiers que vous pouvez ajouter manuellement. Les éléments suivants ne sont pas inclus : * appsettings.json * database.db * web.config * Binaires de l'application PowerShell Universal ## Référentiels Git multiples PowerShell Universal prend en charge le stockage de plusieurs configurations de référentiel git dans la base de données. Ce faisant, vous pouvez rapidement basculer entre différentes configurations de PowerShell Universal. Cliquez sur l'onglet Référentiels pour afficher les référentiels actuellement configurés. De là, vous pouvez supprimer et modifier les configurations de référentiel. {% hint style="warning" %} PowerShell Universal ne supprime pas le dossier .git lors de la suppression d'une configuration de référentiel. Vous devrez le faire manuellement afin de configurer un nouveau référentiel. {% endhint %} Lorsque vous ajoutez une nouvelle configuration de référentiel, vous pouvez cliquer sur le bouton Appliquer pour basculer vers le référentiel sélectionné. Cela supprimera tous les fichiers du répertoire du référentiel et clonera le référentiel sélectionné. Vous ne pouvez pas appliquer une configuration de référentiel s'il y a des modifications non validées dans votre référentiel. Après le clonage du référentiel, PowerShell Universal rechargera entièrement sa configuration. ## Page d'historique et d'état Git L'onglet d'historique affiche tout l'historique des validations git pour le référentiel actuel.
L'onglet d'état de synchronisation affiche l'état actuel des nœuds dans le cluster PSU.
### Test de la synchronisation Git La meilleure façon de s'assurer que votre synchronisation Git fonctionne correctement est de cliquer sur le bouton Synchroniser maintenant. Cela forcera l'exécution d'une synchronisation et vous pourrez vérifier si les paramètres saisis ont fonctionné correctement. ![](/files/mxRQd3tsljKyXUrKcLVM) ### Affichage des modifications Vous pouvez afficher les modifications dans le tableau des synchronisations git. Chaque synchronisation inclut le nombre de modifications trouvées depuis la dernière synchronisation, le SHA de la validation et une liste des modifications entre ce SHA et le précédent. Lorsque des fichiers sont dans un état modifié, vous pourrez afficher les différences à l'aide de l'outil de comparaison de fichiers. ![](/files/8lLP3IiQa8Ta4sG0Eolq) ### Résolution des conflits {% hint style="info" %} La résolution des conflits n'est disponible qu'en mode de synchronisation Git manuelle. {% endhint %} Lorsque plusieurs utilisateurs modifient les fichiers de configuration de PowerShell Universal, il peut y avoir des conflits. PowerShell Universal affichera qu'un nœud particulier est dans un état conflictuel lors d'une tentative de validation des modifications. Vous verrez une liste des modifications en conflit sur la page de validation git. Cliquez sur le bouton Résoudre le conflit pour afficher le conflit dans un éditeur.
Dans cet exemple, la chaîne pour ce point de terminaison a été modifiée à la fois sur le dépôt distant et sur le référentiel local.
Modifiez le texte pour supprimer le conflit.
Enregistrez les modifications et revenez à la page de validation git. Saisissez un nouveau message de validation pour le conflit de fusion et cliquez sur Valider les modifications.
Cela résoudra le conflit de fusion et transmettra les modifications au dépôt distant. ## Comportement de la synchronisation Git ### Bidirectionnel Par défaut, la synchronisation Git fonctionne dans les deux sens. Si vous apportez des modifications dans la console d'administration PSU, ces modifications seront validées et synchronisées avec le dépôt distant configuré. Toutes les modifications apportées dans le dépôt distant seront extraites localement. Si vous configurez la synchronisation Git avec un dépôt git distant préexistant, les modifications seront extraites et synchronisées localement. Vous ne pouvez pas avoir de modifications locales. Si vous configurez la synchronisation Git avec un référentiel vide, les modifications locales seront synchronisées et le référentiel sera initialisé. ### Unidirectionnel Vous pouvez ajuster le comportement de la synchronisation Git en modifiant le paramètre `GitSyncBehavior` dans `appsettings.json`. Lorsqu'il est défini sur `OneWay`, la console d'administration et l'API de gestion deviennent en lecture seule. Le système PowerShell Universal extraira depuis le dépôt distant mais ne transmettra ni ne validera jamais localement. ```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": "" }, ``` ### Transmission uniquement Le mode de synchronisation Git en transmission uniquement n'extraira pas les modifications du dépôt distant. Toutes les modifications apportées localement seront transmises au dépôt distant. La console ne sera pas en lecture seule. Cette configuration est utile dans les scénarios où vous disposez d'un ordinateur utilisé comme source de vérité pour la configuration d'un pool de serveurs en lecture seule. ```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": "" }, ``` ## Jeton d'accès personnel Nous vous recommandons d'utiliser un jeton d'accès personnel (PAT) plutôt qu'un nom d'utilisateur et un mot de passe. Vous pouvez configurer un jeton d'accès personnel en définissant la propriété de mot de passe dans `appsettings.json` ou via d'autres méthodes de configuration. ```javascript "Data": { "RepositoryPath": "%ProgramData%\\UniversalAutomation\\Repository", "ConnectionString": "%ProgramData%\\UniversalAutomation\\database.db", "GitRemote": "https://github.com/myorg/myrepo.git", "GitUserName": "any", "GitPassword": "MYPAT----------------" }, ``` ### Jetons à granularité fine GitHub Dans GitHub, vous pouvez récupérer un jeton à granularité fine en cliquant sur votre avatar en haut à droite, en sélectionnant Paramètres, Paramètres développeur, Jetons d'accès personnels, puis Jetons à granularité fine. #### Portées du jeton Lors de la génération du jeton, assurez-vous de fournir l'accès `Read-Write` au référentiel pour l'autorisation `Content`. Cela ajoutera automatiquement l'accès en lecture à l'autorisation `Metadata`. Vous pouvez fournir l'accès uniquement au référentiel que vous souhaitez cloner. ### Jetons GitHub (classiques) Dans GitHub, vous pouvez récupérer un jeton d'accès personnel en cliquant sur votre avatar en haut à droite, en sélectionnant Paramètres, Paramètres développeur, Jetons d'accès personnels, puis Jetons (classiques). Lors de la génération de votre jeton d'accès, assurez-vous de sélectionner les autorisations Repo. ![](/files/1A7Kgj2FK6LUpzujREIQ) Notez que si vous utilisez BitBucket, vous devrez spécifier le nom d'utilisateur en plus du PAT dans `appsettings.json`. ## Nom d'utilisateur et mot de passe Vous pouvez également configurer un dépôt git distant pour s'authentifier avec un nom d'utilisateur et un mot de passe. Définissez le nom d'utilisateur et le mot de passe soit avec le fichier `appsettings.json`, soit via une autre méthode de configuration. ```javascript "Data": { "RepositoryPath": "%ProgramData%\\UniversalAutomation\\Repository", "ConnectionString": "%ProgramData%\\UniversalAutomation\\database.db", "GitRemote": "https://github.com/myorg/myrepo.git", "GitUserName": "myusername", "GitPassword": "mypassword" }, ``` ## Erreurs courantes #### Git synchronization failed. unknown certificate lookup failure: 16777280 La bibliothèque lib2gitsharp n'a pas pu valider le certificat du référentiel git distant. Vous devrez utiliser le [client git externe](#external-git-client) et une configuration git personnalisée pour résoudre ce problème. Certaines options courantes pour la prise en charge HTTPS de git incluent : ``` 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 » ou rejeux d'authentification Le dépôt git distant a rejeté vos informations d'identification pour accéder au référentiel. Votre jeton d'accès personnel a peut-être expiré ou n'a pas accès au dépôt distant. #### repository not owned by current user Le référentiel git local ne dispose pas des contrôles d'accès appropriés pour l'utilisateur qui tente d'y accéder. Cela peut se produire si PowerShell Universal a cloné le référentiel et qu'un compte de service différent a ensuite été défini sur le service. Étant donné que les contrôles d'accès ne correspondent pas, git n'accédera pas au dossier. Il s'agit d'une fonctionnalité de sécurité de git. Vous pouvez mettre à jour le propriétaire du dossier pour éviter cela ou configurer git pour faire confiance au dossier. Définissez la valeur suivante dans la configuration git globale. ``` [safe] directory = C:\ProgramData\UniversalAutomation\Repository ``` La configuration globale se trouve dans : `C:\Program Files\git\etc\gitconfig` ## Avantages de la synchronisation Git par rapport à la synchronisation Git manuelle Il est possible de synchroniser manuellement un référentiel git. PowerShell Universal utilise des commandes très basiques lorsqu'il traite avec git. Toute modification apportée à PowerShell Universal via la console d'administration ou l'API invoque un `git commit` et l'auteur est défini sur l'identité de l'utilisateur effectuant la modification. Lors d'une opération de synchronisation Git, nous effectuons d'abord un `git pull` pour nous assurer que nous disposons de la dernière version des fichiers sur le dépôt distant. Ensuite, nous effectuons un `git push` pour transmettre les validations locales qui ont eu lieu depuis la dernière synchronisation. Vous pourriez obtenir cette fonctionnalité avec une tâche planifiée. Cela dit, l'une des fonctionnalités de la synchronisation Git est qu'elle analyse la validation pour s'assurer que seuls les fichiers modifiés lors de la synchronisation sont rechargés. Cela empêchera les tableaux de bord de se déployer automatiquement lorsqu'ils n'ont pas changé ou les services API de redémarrer lorsque les environnements n'ont pas été mis à jour. Il y a donc un gain de performances ici. L'autre problème est que, en raison de la façon dont PowerShell Universal surveille les fichiers (avec un `FileSystemWatcher`) et de la façon dont git met à jour les fichiers, les configurations ne se rechargeront pas automatiquement après une extraction. Vous devrez vous assurer que vous forcez la réévaluation des configurations. ## Stratégies de branchement Les stratégies de branchement dans git dictent comment les modifications sont déplacées d'une branche à une autre. L'utilisation de différents types de stratégies de branchement dans PowerShell Universal peut garantir que des équipes de différentes tailles peuvent travailler efficacement ensemble dans la plateforme. ### Utilisateurs uniques et petites équipes Pour les utilisateurs uniques et les petites équipes, il peut ne pas être nécessaire d'avoir plus d'une seule branche. La branche est utilisée pour le suivi de l'historique et offre la possibilité d'annuler les modifications. Les utilisateurs accéderont directement à PowerShell Universal pour apporter des modifications ou valider des modifications sur la branche unique à partir de clones locaux du répertoire du référentiel à l'aide d'un outil comme VS Code. * main - Branche unique qui accepte toutes les modifications directement ### Utilisateurs uniques et petites équipes avec une branche de préproduction Même les utilisateurs uniques et les petites équipes peuvent trouver avantageux d'utiliser une branche de préproduction, ou de développement. Cette branche recevra les modifications pendant le développement. Une instance autonome de PowerShell Universal sera configurée pour s'exécuter sur cette branche de développement afin que les utilisateurs puissent valider les modifications avant de les transmettre en production. Lors de l'utilisation d'une configuration de branche de préproduction, les environnements PowerShell Universal sont complètement séparés. Ils utilisent une base de données et un planificateur différents. Les données telles que les identités, les jetons d'application et l'historique des tâches ne sont pas partagées entre les environnements. {% hint style="info" %} Chaque instance de PowerShell Universal nécessite une [licence](/powershell-universal/fr/licensing.md). Dans cette configuration, deux licences seraient requises. {% endhint %} Une instance PowerShell Universal distincte peut ensuite être configurée pour pointer vers une branche principale, ou de production, qui recevra les mises à jour via des fusions ou des demandes de tirage dans un système comme GitHub. Dans cette configuration, il est possible d'utiliser la synchronisation Git unidirectionnelle pour extraire les modifications de la branche principale sans jamais transmettre depuis la plateforme. Cela évite également la plupart des conflits de fusion car ils seront traités dans la branche de développement ou via l'outil de fusion dans le référentiel source. * main - Branche de production qui reçoit les modifications des demandes de tirage de la branche dev * dev - La branche de préproduction utilisée pour accepter les validations et valider les modifications avant de les transmettre au master ### Équipes de taille moyenne à grande Lorsque l'on considère des équipes de plus de quelques développeurs, une stratégie de branchement plus complexe peut être utile pour mieux évaluer les modifications du code et éviter les conflits de fusion. PowerShell Universal fournit des outils de fusion de base, mais de meilleurs outils sont disponibles à cette fin, tels que les demandes de tirage GitHub, les demandes de fusion GitLab et les outils locaux comme GitKraken. Dans les équipes de taille moyenne, il peut être souhaitable d'avoir des branches de fonctionnalités supplémentaires qui isolent des modifications spécifiques dans une certaine branche. Par exemple, un développeur peut créer un nouvel ensemble d'API pour gérer Azure dans PowerShell Universal. Afin d'éviter les modifications importantes dans la branche dev, les développeurs créeront leur propre branche de fonctionnalité qui contient toutes leurs modifications jusqu'à ce qu'elles soient suffisamment complètes pour être fusionnées dans la branche de développement. {% hint style="info" %} PowerShell Universal fournit des [licences développeur](/powershell-universal/fr/licensing.md) pour éviter d'avoir à acheter une licence pour chaque développeur de votre équipe. Des licences seraient toujours requises pour les environnements de production et de préproduction. {% endhint %} Dans ce type de configuration, le développement local est idéal car les développeurs travailleront sur leur instance PowerShell Universal locale dans leur branche de fonctionnalité. Lorsque la fonctionnalité est terminée, ils créeront une demande de tirage ou de fusion dans le référentiel source pour déplacer les modifications dans la branche dev. Les tests seront effectués sur la branche dev avant la fusion en production. Similaire à une stratégie de branchement main\dev, toutes les instances PowerShell Universal seront isolées et ne partageront pas de base de données ni de planificateur. Une fois qu'un ensemble de fonctionnalités est prêt pour la production, une demande de tirage ou de fusion sera effectuée de dev vers la branche principale. * main - Branche de production qui ne recevra les modifications que de dev * dev - Branche de préproduction qui reçoit les modifications des branches de fonctionnalités mais n'est pas modifiée directement * feature - Branche de fonctionnalité sur laquelle les développeurs valident directement et qui est fusionnée dans dev lorsqu'elle est prête Selon la complexité de votre environnement, il peut être conseillé d'utiliser les déploiements plutôt que git en production. Consultez la section Grandes équipes ci-dessous pour plus d'informations. ### Grandes équipes Dans les grandes équipes, nous recommandons d'utiliser git à des fins de développement, mais d'utiliser les déploiements, ou un concept similaire, pour la production. Les [déploiements](/powershell-universal/fr/config/deployments.md) fournissent des packages de configuration immuables qui ont été bien testés dans les environnements inférieurs. En utilisant les déploiements, vous pouvez choisir comment vous développez et gérez votre code et simplement publier le résultat dans vos environnements de développement, de préproduction, d'assurance qualité et de production. Cela garantit que tout le code est bien testé avant d'être déployé dans vos systèmes critiques. Vous pouvez utiliser des flux de travail automatisés, comme GitHub Actions, pour publier vos déploiements sans avoir à mettre à jour manuellement aucun système. ## Hébergement Git PowerShell Universal prend en charge toute solution d'hébergement git standard. Nos clients utilisent fréquemment les solutions suivantes : * GitHub * GitHub Enterprise * GitLab * Bitbucket * Azure DevOps Bien que ce soient les plateformes les plus courantes, nous prenons en charge toute plateforme qui utilise le protocole git. ### Exemple : Gitea Vous pouvez également utiliser des solutions simples et auto-hébergées comme [Gitea](https://gitea.com). Voici un exemple de la façon de configurer facilement un conteneur Docker Gitea pour une utilisation avec PowerShell Universal. --- # 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: ``` GET https://docs.devolutions.net/powershell-universal/fr/config/git.md?ask= ``` The question should be specific, self-contained, and written in natural language. 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.