> 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 Synchronisez la configuration de PowerShell Universal avec un dépôt git distant, couvrant les branches, l'authentification, le comportement de synchronisation et le dépannage des conflits. {% hint style="info" %} L'intégration Git nécessite une [licence](https://store.devolutions.net/package#psu). {% endhint %} PowerShell Universal est capable de synchroniser les scripts de configuration avec un dépôt 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. C'est l'approche à privilégier. L'avantage est que lorsque vous connectez de nouvelles instances de PowerShell Universal à votre instance SQL, vous n'aurez pas à configurer la synchronisation git de nouveau. Pour configurer la synchronisation git, accédez à Source Control > Git > Settings dans la console d'administration. Vous pourrez cliquer sur le bouton Create Git Settings. {% hint style="info" %} Dans PowerShell Universal 5.x et versions ultérieures, les identifiants Git (Remote URL, Username et Personal Access Token) sont stockés dans la base de données SQL plutôt que dans appsettings.json. La modification de ces paramètres dans l'interface mettra à jour la base de données. Si vous modifiez les paramètres Git puis cliquez sur OK, PSU peut effacer les identifiants stockés même si les champs semblent remplis. Dans les environnements multinœuds, vous devez saisir de nouveau les identifiants sur chaque nœud individuellement après avoir effectué des modifications. {% endhint %} ### appsettings.json Vous pouvez aussi utiliser les [paramètres de configuration](/powershell-universal/fr/config/settings.md) pour mettre en place la synchronisation git. Cela est utile si vous avez une seule instance de PSU et que vous souhaitez sauvegarder votre fichier appsettings.json. L'ajustement des paramètres dans la console d'administration ne mettra pas à jour le fichier appsettings.json. Vous devrez le faire manuellement et redémarrer PowerShell Universal après avoir modifié les paramètres. Si les 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 synchronisera avec la branche `master`. Si vous souhaitez utiliser une autre branche, 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 du dépôt configuré) 2. Exécutez : {% code collapsedlinecount="10" %} ```powershell git fetch git branch --set-upstream-to=origin/main main git pull ``` {% endcode %} ### Distant Les dépôts distants ne sont pas requis. Si aucun dépôt distant n'est spécifié, le dépôt git est stocké localement dans le répertoire Repository. S'il est spécifié, PowerShell Universal se synchronisera avec le dépôt distant. Des identifiants appropriés sont requis pour accéder à ce dépôt distant. #### Format d'URL Azure DevOps Les dépôts Azure DevOps doivent utiliser le format d'URL moderne `dev.azure.com` plutôt que l'ancien domaine `visualstudio.com` : **Format correct :** {% code collapsedlinecount="10" %} ``` https://dev.azure.com///_git/ ``` {% endcode %} **Exemples :** {% code collapsedlinecount="10" %} ``` https://dev.azure.com/mycompany/MyProject/_git/PowerShellUniversal https://dev.azure.com/mycompany/MyProject/_git/PSU%20Scripts ``` {% endcode %} Si le nom de votre dépôt contient des espaces, ceux-ci doivent être encodés en `%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 Personal Access Token doit avoir la portée **Code (Read & Write)**. Les jetons à granularité fine fonctionnent, mais les PAT classiques sont recommandés pour la compatibilité entre les versions de PSU. **Note pour les utilisateurs de GitLab :** Si votre instance GitLab nécessite une authentification basée sur les en-têtes, vous devrez peut-être utiliser l'option External Git Client et configurer les assistants d'identifiants 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 plutôt un en-tête `Private-Token`. ### Authentification Vous devrez configurer l'authentification à votre dépôt git distant. Nous recommandons 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 additionnelles, comme l'utilisation de l'authentification SSH. PowerShell Universal n'utilisera pas les noms d'utilisateur, mots de passe ou PAT configurés lorsque cette méthode est activée. Vous devrez avoir un client git installé. #### Utilisation de 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 Source Control > SSH Keys. 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 dépôt 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 Git Settings, sélectionnez la clé SSH que vous souhaitez utiliser avec la synchronisation git. Lorsque vous utilisez des clés SSH, assurez-vous que l'URL SSH est sélectionnée pour cloner votre dépôt. {% code collapsedlinecount="10" %} ``` git@github.com:ironmansoftware/psu-devo ``` {% endcode %} #### Configuration des identifiants Lorsque vous utilisez le client git externe, il vous incombe de configurer les identifiants avant d'effectuer une synchronisation. Vous pouvez configurer les identifiants par la configuration git ou par l'URL transmise à PowerShell Universal. La commande suivante stockera les identifiants en texte en clair 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 identifiants. 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 selon votre dépôt git distant. {% code collapsedlinecount="10" %} ```batch git config --global credential.helper store echo "https://${username}:${password_or_access_token}@github.com" > ~/.git-credentials ``` {% endcode %} Vous pouvez aussi stocker les identifiants directement dans l'URL fournie à PowerShell Universal. {% code collapsedlinecount="10" %} ``` https://adam:APP_TOKEN@github.com/myOrg/myRepo.git ``` {% endcode %} #### 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 : {% code collapsedlinecount="10" %} ``` https://username:PAT@github.com/devolutions/powershell-universal ``` {% endcode %} #### Exemple : SSH et GitHub D'abord, vous devrez configurer votre ssh-agent 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 comme URL de dépôt git distant dans PowerShell Universal. La clé SSH configurée sera utilisée pour la connexion. {% code collapsedlinecount="10" %} ``` git@github.com:devolutions/powershell-universal.git ``` {% endcode %} #### Problème de certificat SSL {% hint style="warning" %} SSL Certificate problem: unable to get local issuer certificate {% endhint %} Si vous exécutez sur Windows et recevez un problème de certificat SSL, vous devrez peut-être vous assurer d'avoir [activé la prise en charge de schannel](https://stackoverflow.com/questions/23885449/unable-to-resolve-unable-to-get-local-issuer-certificate-using-git-on-windows). #### Persistance des identifiants {% hint style="warning" %} Unable to persist credentials with the 'wincredman' credential store. {% endhint %} Si vous êtes sur Windows et recevez une erreur au sujet de la persistance des identifiants dans wincredman, vous devrez peut-être définir la persistance des identifiants à DAPI. Vous pouvez [apprendre comment le 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 Edit afin d'apporter des modifications dans le système. Une fois les modifications terminées, l'utilisateur peut cliquer sur Save Changes pour amorcer un commit Sur la page de commit git, vous pouvez voir les fichiers modifiés et saisir un message de commit. Une fois les modifications validées, elles seront poussées vers le dépôt distant et le service recommencera à se synchroniser avec git. Il est aussi possible qu'un conflit de fusion git se produise à ce moment. Consultez [Gestion des conflits](#dealing-with-conflicts) pour plus d'information. Le mode manuel peut être défini dans les paramètres git de la console d'administration ou dans `appsettings.json`. {% 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 %} ### Méthode un : pousser les fichiers locaux vers le dépôt distant {% hint style="info" %} L'emplacement par défaut du dépôt local est `C:\ProgramData\UniversalAutomation\Repository` {% endhint %} Vous devez vous assurer que votre dossier local n'est pas un dépôt git préexistant. Votre répertoire de dépôt devrait simplement être un dossier contenant vos fichiers PowerShell Universal. Si un dossier `.git` existe et que vous ne souhaitez pas utiliser ce dépôt, vous devriez le supprimer et PowerShell Universal créera un nouveau dépôt. Si vous remplissez un nouveau dépôt git, vous devez vous assurer que le dépôt distant ne contient aucun fichier. Il devrait s'agir d'un dépôt complètement vide. Par exemple, lors de la création d'un dépôt sur GitHub, ne sélectionnez pas la création d'un fichier de licence ou readme.md. Une fois le dépôt créé, vous pouvez récupérer l'URL du dépôt git distant et la fournir au fichier `appsettings.json` de PowerShell Universal. Une fois que vous avez la branche, l'URL du dépôt git distant et les identifiants, vous pouvez les fournir à votre fichier `appsettings.json` et le dépôt git distant sera rempli avec vos fichiers locaux. ### Méthode deux : tirer depuis un dépôt git distant {% hint style="info" %} L'emplacement par défaut du dépôt local est `C:\ProgramData\UniversalAutomation\Repository` {% endhint %} Vous pouvez configurer PowerShell Universal pour tirer depuis un dépôt git distant. Dans cette configuration, vous devez vous assurer que votre dossier de dépôt local est complètement vide. Tout fichier dans le dossier fera échouer la synchronisation git et l'empêchera de se rétablir. Configurez le fichier `appsettings.json` pour inclure la branche, les identifiants 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 est de cloner le dépôt 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 le temps de télécharger de gros dépôts ou de composer avec des réseaux lents. Vous pourriez voir le service PowerShell Universal figé 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. {% code collapsedlinecount="10" %} ```json "Data" : { "GitSyncTimeout": 30 } ``` {% endcode %} ### Intervalle de synchronisation **Type :** Integer\ **Par défaut :** 60\ **appsettings.json :** `GitSyncInterval` L'intervalle, en secondes, entre les tentatives de synchronisation Git automatiques 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` : {% code collapsedlinecount="10" %} ```json "GitSyncInterval": 300 ``` {% endcode %} Cela changerait l'intervalle de synchronisation à 5 minutes. Des valeurs plus faibles augmentent la fréquence de synchronisation, mais peuvent affecter la performance dans les grands dépôts ou les réseaux lents. Définir cette valeur trop basse (sous 30 secondes) n'est pas recommandé pour les environnements de production. ### Dépannage #### Azure DevOps : « Too many redirects or authentication replays » Cette erreur indique généralement l'un des problèmes suivants : * **Ancien format d'URL :** Assurez-vous d'utiliser `https://dev.azure.com///_git/` plutôt que l'ancien domaine `visualstudio.com` * **Portée du PAT invalide :** Votre Personal Access Token doit avoir les permissions **Code (Read & Write)** dans Azure DevOps * **Identifiants expirés :** Générez un nouveau PAT et saisissez-le de nouveau dans les paramètres Git de PSU * **Espaces encodés :** Si le nom de votre dépôt contient des espaces, assurez-vous qu'ils sont encodés en `%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 (Read & Write) 3. Activez **Use External Git Client** 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 dépôt et exécutez : {% code collapsedlinecount="10" %} ```powershell git fetch git branch --set-upstream-to=origin/main main git pull ``` {% endcode %} Remplacez `main` par le nom réel de votre branche. Cliquez ensuite sur **Synchronize Now** dans PSU. #### La synchronisation Git s'arrête après la modification des paramètres dans l'interface **Symptômes :** Après avoir modifié les paramètres Git (URL distante, identifiants, intervalle de synchronisation, etc.) dans l'interface 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 identifiants Git sont stockés dans la base de données SQL. Toute modification apportée aux paramètres Git par l'interface peut effacer les identifiants stockés, même si le champ de mot de passe semble toujours rempli dans le formulaire. **Résolution :** 1. Saisissez de nouveau le Personal Access Token dans **Source Control > Git > Settings** 2. Cliquez sur **OK** pour enregistrer 3. Dans les environnements multinœuds, **répétez ce processus sur chaque nœud** — les identifiants doivent être saisis individuellement sur chaque serveur 4. Cliquez sur **Synchronize Now** pour vérifier que la synchronisation fonctionne de nouveau Le système ne propage pas automatiquement les identifiants 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 :** * **Incompatibilité 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 par gRPC sur les ports **5000** (HTTP) ou **5001** (HTTPS) * **Blocage de proxy ou de 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 permettent 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 #### Déploiements Docker et 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` afin de préserver l'état git entre les redémarrages * Si la synchronisation échoue silencieusement, vérifiez les journaux du conteneur pour des erreurs git ou réseau #### Modification de .git/config sans le 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 la configuration du dépôt directement par le navigateur de fichiers de PSU : 1. Accédez à **Platform → Configuration → Repository → .git → config** 2. Ajoutez les lignes suivantes (ajustez le nom de la branche pour qu'il corresponde à votre dépôt) : {% code collapsedlinecount="10" %} ```ini [branch "main"] remote = origin merge = refs/heads/main ``` {% endcode %} 3. Cliquez sur **Save** 4. Retournez à **Source Control > Git > Settings** et cliquez sur **Synchronize Now** Cette approche vous permet de configurer le suivi en amont sans avoir besoin de commandes `git`, ce qui est particulièrement utile lorsque Git for Windows n'est pas installé ou lors de l'exécution 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érifier les permissions 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 antérieures) * Ajoutez une ligne de commentaire, enregistrez, puis 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 permissions NTFS empêchent l'écriture dans le répertoire de données PSU **Activer la journalisation de débogage pour le dépannage :** 1. Arrêtez le service PowerShell Universal 2. Modifiez `appsettings.json` et définissez : {% code collapsedlinecount="10" %} ```json "SystemLogLevel": "Debug" ``` {% endcode %} 3. Enregistrez et redémarrez le service 4. Tentez d'enregistrer les paramètres Git de nouveau 5. Consultez `%PROGRAMDATA%\PowerShellUniversal\systemLog.txt` pour repérer les erreurs liées aux écritures de configuration **Renseigner manuellement les paramètres Git :** Une fois le service arrêté, vous pouvez renseigner directement les champs Git dans `appsettings.json` : {% code collapsedlinecount="10" %} ```json "GitRemote": "https://dev.azure.com/org/project/_git/repo", "GitUserName": "any", "GitPassword": "your-PAT-here", "GitBranch": "main" ``` {% endcode %} Redémarrez le service et vérifiez que les paramètres apparaissent dans **Source Control > Git > Settings**. S'ils disparaissent de nouveau, les journaux de débogage indiqueront si un problème de permission, un logiciel de protection des terminaux ou une erreur de validation de la configuration provoque la réinitialisation. ### unknown certificate lookup failure: 16777280 Lorsque vous utilisez la bibliothèque git intégrée, vous pourriez rencontrer des problèmes de certificat lors de la connexion à des dépôts git hébergés localement. Dans cette configuration, nous recommandons d'utiliser le client git externe afin d'offrir un meilleur soutien pour la configuration du processus de recherche de certificat. ## Fichiers inclus Les fichiers inclus lors d'une synchronisation git sont tous les fichiers du dépôt local. Cela comprend les fichiers de configuration PS1, les fichiers XML des pages et tout autre fichier que vous pourriez ajouter manuellement. Les éléments suivants ne sont pas inclus : * appsettings.json * database.db * web.config * Binaires de l'application PowerShell Universal ## Plusieurs dépôts Git PowerShell Universal prend en charge le stockage de plusieurs configurations de dépôt git dans la base de données. Ainsi, vous pouvez basculer rapidement entre différentes configurations de PowerShell Universal. Cliquez sur l'onglet Repositories pour voir les dépôts actuellement configurés. À partir de là, vous pouvez supprimer et modifier les configurations de dépôt. {% hint style="warning" %} PowerShell Universal ne supprime pas le dossier .git lors de la suppression d'une configuration de dépôt. Vous devrez le faire manuellement afin de configurer un nouveau dépôt. {% endhint %} Lorsque vous ajoutez une nouvelle configuration de dépôt, vous pouvez cliquer sur le bouton Apply pour basculer vers le dépôt sélectionné. Cela supprimera tous les fichiers du répertoire du dépôt et clonera le dépôt sélectionné. Vous ne pouvez pas appliquer une configuration de dépôt s'il y a des modifications non validées dans votre dépôt. Après avoir cloné le dépôt, PowerShell Universal rechargera complètement sa configuration. ## Page de l'historique et de l'état Git L'onglet de l'historique affiche tout l'historique des commits git du dépôt actuel. L'onglet de l'état de synchronisation affiche l'état actuel des nœuds au sein du cluster PSU. ### Tester la synchronisation Git La meilleure façon de s'assurer que votre synchronisation git fonctionne correctement est de cliquer sur le bouton Synchronize Now. Cela forcera l'exécution d'une synchronisation, et vous pourrez vérifier si les paramètres saisis fonctionnent correctement. ### Afficher les modifications Vous pouvez consulter les modifications dans le tableau des synchronisations git. Chaque synchronisation comprend le nombre de modifications trouvées depuis la dernière synchronisation, le SHA du commit et une liste des modifications entre ce SHA et le précédent. Lorsque des fichiers sont dans un état modifié, vous pourrez consulter les différences à l'aide de l'outil de comparaison de fichiers. ### Gérer les conflits {% hint style="info" %} La résolution de 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 indiquera qu'un nœud particulier est dans un état de conflit lors d'une tentative de validation des modifications. Vous verrez une liste des modifications en conflit sur la page de commit git. Cliquez sur le bouton Resolve Conflict pour afficher le conflit dans un éditeur. Dans cet exemple, la chaîne de ce point de terminaison a été modifiée à la fois sur le dépôt distant et sur le dépôt local : * Version actuelle (locale) — entre `<<<<<<< HEAD` et `=======` : `"That endpoint"` * Version entrante (distante) — entre `=======` et `>>>>>>> main` : `"This endpoint"` Modifiez le texte pour supprimer le conflit. Enregistrez les modifications et retournez à la page de commit git. Saisissez un nouveau message de commit pour le conflit de fusion et cliquez sur Commit Changes. Cela résoudra le conflit de fusion et effectuera un push vers le dépôt distant. ## Comportement de la synchronisation Git ### Bidirectionnelle 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 vers le dépôt distant configuré. Toutes les modifications effectuées dans le dépôt distant seront récupérées localement. Si vous configurez la synchronisation git avec un dépôt distant git préexistant, les modifications seront récupérées et synchronisées localement. Vous ne pouvez avoir aucune modification locale. Si vous configurez la synchronisation git avec un dépôt vide (bare), les modifications locales seront synchronisées et le dépôt sera initialisé. ### Unidirectionnelle Vous pouvez ajuster le comportement de la synchronisation git en modifiant le paramètre `GitSyncBehavior` dans `appsettings.json`. Lorsqu'il est défini à `OneWay`, la console d'administration et l'API de gestion deviennent en lecture seule. Le système PowerShell Universal récupérera les modifications du dépôt distant, mais n'effectuera jamais de push ni de commit local. {% 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 %} ### Push seulement Le mode de synchronisation git push seulement ne récupérera pas les modifications du dépôt distant. Toutes les modifications effectuées localement seront poussées vers le dépôt distant. La console ne sera pas en lecture seule. Cette configuration est utile dans les scénarios où vous avez une machine utilisée pour la configuration source de vérité d'un groupe de serveurs en lecture seule. {% 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 %} ## Jeton d'accès personnel Nous 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é password dans le fichier `appsettings.json` ou par d'autres méthodes de configuration. {% 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 %} ### Jetons à granularité fine GitHub Dans GitHub, vous pouvez obtenir un jeton à granularité fine en cliquant sur votre avatar en haut à droite, puis en sélectionnant Settings, Developers Settings, Personal Access Tokens et enfin Fine-Grained Tokens. #### Portées du jeton Lors de la génération du jeton, assurez-vous d'accorder au dépôt la permission `Read-Write` sur `Content`. Cela ajoutera automatiquement Read à la permission `Metadata`. Vous pouvez accorder l'accès uniquement au dépôt que vous souhaitez cloner. ### Jetons GitHub (classiques) Dans GitHub, vous pouvez obtenir un jeton d'accès personnel en cliquant sur votre avatar en haut à droite, puis en sélectionnant Settings, Developer Settings, Personal Access Tokens et enfin Tokens (Classic). Lors de la génération de votre jeton d'accès, assurez-vous de sélectionner les permissions Repo. 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 aussi configurer un dépôt distant git 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 avec une autre méthode de configuration. {% 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 %} ## Erreurs courantes #### Git synchronization failed. unknown certificate lookup failure: 16777280 La bibliothèque lib2gitsharp n'a pas pu valider le certificat du dépôt git distant. Vous devrez utiliser le [client git externe](#external-git-client) et une configuration git personnalisée pour corriger ce problème. Voici quelques options courantes pour la prise en charge de git HTTPS : {% 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" ou rejeux d'authentification Le dépôt distant git a rejeté vos identifiants d'accès au dépôt. Votre jeton d'accès personnel est peut-être expiré ou n'a pas accès au dépôt distant. #### repository not owned by current user Le dépôt 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 dépôt et qu'un compte de service différent a ensuite été défini sur le service. Comme 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 qu'il fasse confiance au dossier. Définissez la valeur suivante dans la configuration git globale. {% code collapsedlinecount="10" %} ``` [safe] directory = C:\ProgramData\UniversalAutomation\Repository ``` {% endcode %} 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 dépôt avec git. PowerShell Universal utilise des commandes très basiques lorsqu'il traite avec git. Toute modification apportée à PowerShell Universal par la console d'administration ou l'API déclenche un `git commit` et l'auteur est défini comme l'identité de l'utilisateur qui effectue la modification. Lors d'une opération de synchronisation git, nous effectuons d'abord un `git pull` afin de nous assurer d'avoir la dernière version des fichiers du dépôt distant. Ensuite, nous effectuons un `git push` pour pousser les commits locaux survenus depuis la dernière synchronisation. Vous pourriez obtenir cette fonctionnalité avec une tâche planifiée. Cela dit, une fonctionnalité de la synchronisation git est qu'elle analyse le commit pour s'assurer que seuls les fichiers modifiés durant la synchronisation sont rechargés. Cela empêchera les tableaux de bord de se déployer automatiquement alors qu'ils n'ont pas changé ou les services d'API de redémarrer alors que les environnements n'ont pas été mis à jour. Il y a donc un gain de performance ici. L'autre problème est qu'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 un pull. Vous devrez vous assurer de forcer la réévaluation des configurations. ## Stratégies de branchement Les stratégies de branchement dans git déterminent 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 permet de s'assurer que des équipes de tailles différentes peuvent travailler efficacement ensemble dans la plateforme. ### Utilisateurs seuls et petites équipes Pour les utilisateurs seuls et les petites équipes, il n'est peut-être pas 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 des modifications. Les utilisateurs accèderont directement à PowerShell Universal pour apporter des modifications ou valider des modifications dans la branche unique à partir de clones locaux du répertoire du dépôt en utilisant un outil comme VS Code. * main - Branche unique qui accepte toutes les modifications directement ### Utilisateurs seuls et petites équipes avec une branche de préproduction Même les utilisateurs seuls et les petites équipes peuvent trouver avantageux d'employer une branche de préproduction (staging), ou dev. Cette branche recevra les modifications durant le développement. Une instance autonome de PowerShell Universal sera configurée pour s'exécuter avec cette branche dev afin que les utilisateurs puissent valider les modifications avant de les pousser en production. Lorsqu'une configuration avec branche de préproduction est utilisée, 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 main, ou production, qui recevra les mises à jour par fusions ou Pull Requests dans un système comme GitHub. Dans cette configuration, il est possible d'utiliser la synchronisation git unidirectionnelle pour récupérer les modifications de main sans jamais pousser depuis la plateforme. Cela évite également la plupart des conflits de fusion, puisqu'ils seront traités dans la branche dev ou via l'outil de fusion du dépôt source. * main - Branche de production qui reçoit les modifications provenant des pull requests de la branche dev * dev - La branche de préproduction utilisée pour accepter les commits et valider les modifications avant de pousser vers master. ### Équipes de taille moyenne à grande Lorsqu'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 de code et éviter les conflits de fusion. PowerShell Universal offre des outils de fusion de base, mais de meilleurs outils sont disponibles à cette fin, comme les pull requests de GitHub, les merge requests de GitLab et des 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 des changements cassants dans la branche dev, les développeurs créeront leur propre branche de fonctionnalité contenant toutes leurs modifications jusqu'à ce qu'elle soit suffisamment complète pour être fusionnée dans la branche de développement. {% hint style="info" %} PowerShell Universal offre des [licences de développeur](/powershell-universal/fr/licensing.md) pour éviter d'avoir à acheter une licence pour chaque développeur de votre équipe. Des licences seraient tout de même 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 locale de PowerShell Universal au sein de leur branche de fonctionnalité. Lorsque la fonctionnalité est terminée, ils créeront une Pull ou Merge request dans le dépôt source pour déplacer les modifications vers la branche dev. Les tests seront effectués sur la branche dev avant la fusion vers la production. Comme pour une stratégie de branchement main\dev, toutes les instances de PowerShell Universal seront isolées et ne partageront pas de base de données ni de planificateur. Lorsqu'un ensemble de fonctionnalités est prêt pour la production, une Pull ou Merge request sera effectuée de dev vers la branche main. * main - Branche de production qui ne recevra que les modifications de dev * dev - Branche de préproduction qui reçoit les modifications des branches de fonctionnalités, mais qui n'est pas modifiée directement * feature - Branche de fonctionnalité dans laquelle les développeurs valident directement et qui est fusionnée vers dev lorsqu'elle est prête Selon la complexité de votre environnement, il peut être conseillé d'utiliser les Deployments plutôt que git en production. Consultez la section Grandes équipes ci-dessous pour plus d'information. ### Grandes équipes Dans les grandes équipes, nous recommandons d'utiliser git à des fins de développement, mais d'utiliser les Deployments, ou un concept similaire, pour la production. Les [Deployments ](/powershell-universal/fr/config/deployments.md)fournissent des paquets de configuration immuables qui ont été bien testés dans des environnements de niveau inférieur. En utilisant les Deployments, 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'AQ 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 Deployments sans devoir mettre à jour manuellement quelque système que ce soit. ## Hébergement Git PowerShell Universal prend en charge toute solution d'hébergement git standard. Nos clients utilisent fréquemment les suivantes : * GitHub * GitHub Enterprise * GitLab * Bitbucket * Azure DevOps Bien qu'il s'agisse des plateformes les plus courantes, nous prenons en charge toute plateforme utilisant 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 l'utiliser 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, and the optional `goal` query parameter: ``` GET https://docs.devolutions.net/powershell-universal/fr/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.