> 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/it/config/git.md). # Git Sincronizzi la configurazione di PowerShell Universal con un repository git remoto, includendo branch, autenticazione, comportamento di sincronizzazione e risoluzione dei conflitti. {% hint style="info" %} L'integrazione con git richiede una [licenza](https://store.devolutions.net/package#psu). {% endhint %} PowerShell Universal è in grado di sincronizzare gli script di configurazione con un repository git remoto. ## Configurazione ### Console di amministrazione La sincronizzazione git può essere configurata nel database regolando le impostazioni all'interno della console di amministrazione. Questo è l'approccio preferito. Il vantaggio è che, quando connette nuove istanze di PowerShell Universal alla sua istanza SQL, non dovrà configurare nuovamente la sincronizzazione git. Per configurare la sincronizzazione git, vada su Source Control > Git > Settings all'interno della console di amministrazione. Potrà fare clic sul pulsante Create Git Settings. {% hint style="info" %} In PowerShell Universal 5.x e versioni successive, le credenziali Git (Remote URL, Username e Personal Access Token) sono memorizzate nel database SQL anziché in appsettings.json. La modifica di queste impostazioni nell'interfaccia utente aggiornerà il database. Se modifica le impostazioni Git e poi fa clic su OK, PSU potrebbe cancellare le credenziali memorizzate anche se i campi appaiono compilati. Negli ambienti multi-nodo, deve reinserire le credenziali su ogni nodo individualmente dopo aver apportato modifiche. {% endhint %} ### appsettings.json Può anche utilizzare le [impostazioni di configurazione](/powershell-universal/it/config/settings.md) per impostare la sincronizzazione git. Questo è utile se dispone di una singola istanza di PSU e desidera eseguire il backup del file appsettings.json. La modifica delle impostazioni all'interno della console di amministrazione non aggiornerà il file appsettings.json. Dovrà farlo manualmente e riavviare PowerShell Universal dopo aver modificato le impostazioni. Se le impostazioni di sincronizzazione git sono specificate nel database, le impostazioni definite in appsettings.json vengono ignorate. ## Impostazioni di sincronizzazione git ### Branch Per impostazione predefinita, PowerShell Universal si sincronizzerà con il branch `master`. Se desidera utilizzare un branch diverso, specifichi l'impostazione `GitBranch` all'interno del suo `appsettings.json`. #### Correggere il tracciamento upstream mancante Se riscontra l'errore **"There is no tracking information for the current branch"**, il branch locale non è collegato al remoto. Per correggerlo: 1. Apra PowerShell in `%ProgramData%\UniversalAutomation\Repository` (o nel percorso del repository configurato) 2. Esegua: {% code collapsedlinecount="10" %} ```powershell git fetch git branch --set-upstream-to=origin/main main git pull ``` {% endcode %} ### Remoto I remoti non sono obbligatori. Se non viene specificato un remoto, il repository git viene memorizzato localmente nella directory Repository. Se specificato, PowerShell Universal si sincronizzerà con il remoto. Per accedere a tale remoto sono necessarie credenziali valide. #### Formato URL di Azure DevOps I repository di Azure DevOps devono utilizzare il formato URL moderno `dev.azure.com` anziché il dominio legacy `visualstudio.com`: **Formato corretto:** {% code collapsedlinecount="10" %} ``` https://dev.azure.com///_git/ ``` {% endcode %} **Esempi:** {% code collapsedlinecount="10" %} ``` https://dev.azure.com/mycompany/MyProject/_git/PowerShellUniversal https://dev.azure.com/mycompany/MyProject/_git/PSU%20Scripts ``` {% endcode %} Se il nome del repository contiene spazi, questi devono essere codificati come `%20` nell'URL. Eviti di utilizzare URL con il vecchio dominio `visualstudio.com`, poiché possono causare loop di reindirizzamento o errori di autenticazione con l'errore "too many redirects or authentication replays". Per Azure DevOps, il suo Personal Access Token deve avere l'ambito **Code (Read & Write)**. I token fine-grained funzionano, ma sono consigliati i PAT classici per compatibilità tra le versioni di PSU. **Nota per gli utenti GitLab:** se la sua istanza GitLab richiede l'autenticazione basata su header, potrebbe essere necessario utilizzare l'opzione External Git Client e configurare gli helper delle credenziali Git, poiché il client Git integrato di PSU utilizza l'autenticazione HTTP Basic con il PAT come password. Alcune configurazioni di GitLab si aspettano invece un header `Private-Token`. ### Autenticazione Dovrà configurare l'autenticazione verso il suo repository git remoto. Consigliamo un personal access token. ### Client git esterno Può scegliere di utilizzare un client git esterno anziché la libreria integrata in PowerShell Universal. Questo le consente ulteriori opzioni di configurazione, come l'utilizzo dell'autenticazione SSH. PowerShell Universal non utilizzerà nome utente, password o PAT configurati quando si abilita questo metodo. Dovrà avere un client git installato. #### Utilizzo delle chiavi SSH Può utilizzare PowerShell Universal per generare e gestire le chiavi SSH. All'interno della console di amministrazione, faccia clic su Source Control > SSH Keys. Generi una nuova chiave SSH. Successivamente, faccia clic sul pulsante di copia accanto alla chiave SSH per ottenere la chiave pubblica. Registri la chiave pubblica con il repository o l'account di destinazione. Ad esempio, può seguire la [guida di GitHub](https://docs.github.com/en/authentication/connecting-to-github-with-ssh) qui. Nella finestra Git Settings, selezioni la chiave SSH che desidera utilizzare con la sincronizzazione git. Quando utilizza le chiavi SSH, si assicuri che sia selezionato l'URL SSH per clonare il suo repository. {% code collapsedlinecount="10" %} ``` git@github.com:ironmansoftware/psu-devo ``` {% endcode %} #### Impostazione delle credenziali Quando utilizza il client git esterno, è sua responsabilità configurare le credenziali prima di eseguire una sincronizzazione. Può configurare le credenziali tramite la configurazione git o l'URL passato a PowerShell Universal. Il comando seguente memorizzerà le credenziali in testo normale sul server PowerShell Universal. Dovrà eseguire questo comando come utente dell'account di servizio in modo che abbia accesso alle credenziali. Questo creerà un file `.git-credentials` che verrà utilizzato durante l'autenticazione verso l'URL di destinazione. Potrebbe essere necessario modificare l'URL a seconda del suo remoto git. {% code collapsedlinecount="10" %} ```batch git config --global credential.helper store echo "https://${username}:${password_or_access_token}@github.com" > ~/.git-credentials ``` {% endcode %} Può anche memorizzare le credenziali direttamente nell'URL fornito a PowerShell Universal. {% code collapsedlinecount="10" %} ``` https://adam:APP_TOKEN@github.com/myOrg/myRepo.git ``` {% endcode %} #### Esempio: nome utente e PAT Per utilizzare un client git esterno e passare un nome utente e un PAT per l'autenticazione, può specificarli nell'URL del remoto git. Ad esempio: {% code collapsedlinecount="10" %} ``` https://username:PAT@github.com/devolutions/powershell-universal ``` {% endcode %} #### Esempio: SSH e GitHub Per prima cosa, dovrà configurare il suo ssh-agent locale e il suo account GitHub con le chiavi SSH. Può seguire la [guida disponibile qui](https://docs.github.com/en/authentication/connecting-to-github-with-ssh). Successivamente, fornirà un URI SSH per l'URL del remoto git in PowerShell Universal. La chiave SSH configurata verrà utilizzata per la connessione. {% code collapsedlinecount="10" %} ``` git@github.com:devolutions/powershell-universal.git ``` {% endcode %} #### Problema con il certificato SSL {% hint style="warning" %} SSL Certificate problem: unable to get local issuer certificate {% endhint %} Se esegue il prodotto su Windows e riceve un problema di certificato SSL, potrebbe essere necessario assicurarsi di aver [abilitato il supporto schannel](https://stackoverflow.com/questions/23885449/unable-to-resolve-unable-to-get-local-issuer-certificate-using-git-on-windows). #### Persistenza delle credenziali {% hint style="warning" %} Unable to persist credentials with the 'wincredman' credential store. {% endhint %} Se si trova su Windows e riceve un errore relativo alla persistenza delle credenziali in wincredman, potrebbe essere necessario impostare la persistenza delle credenziali su DAPI. Può [scoprire come farlo qui](https://github.com/GitCredentialManager/git-credential-manager/issues/633). ### Modalità manuale La modalità manuale richiede che gli utenti che modificano l'istanza di PowerShell Universal facciano clic su Edit per apportare modifiche nel sistema. Una volta completate le modifiche, l'utente può fare clic su Save Changes per avviare un commit Nella pagina del commit git, può visualizzare i file modificati e inserire un messaggio di commit. Una volta che le modifiche sono state committate, verranno inviate al remoto e il servizio inizierà nuovamente a sincronizzarsi con git. È anche possibile che in questo momento si verifichi un conflitto di merge git. Consulti [Gestione dei conflitti](#dealing-with-conflicts) per maggiori informazioni. La modalità manuale può essere impostata nelle impostazioni git all'interno della console di amministrazione o all'interno di `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 %} ### Metodo uno: invio dei file locali al remoto {% hint style="info" %} La posizione predefinita per il repository locale è `C:\ProgramData\UniversalAutomation\Repository` {% endhint %} Deve assicurarsi che la sua cartella locale non sia un repository git preesistente. La directory del repository dovrebbe essere semplicemente una cartella con i suoi file PowerShell Universal. Se esiste una cartella `.git` e non desidera utilizzare questo repository, dovrebbe eliminarla e PowerShell Universal creerà un nuovo repository. Se sta popolando un nuovo repository git, deve assicurarsi che il remoto non contenga alcun file. Dovrebbe essere un repository completamente vuoto. Ad esempio, quando crea un repository su GitHub, non selezioni la creazione di una licenza o di un file readme.md. Una volta creato il repository, può recuperare l'URL del remoto git e fornirlo al file `appsettings.json` di PowerShell Universal. Una volta ottenuti il branch, l'URL del remoto git e le credenziali, può fornirli al suo file `appsettings.json` e il remoto git verrà popolato con i suoi file locali. ### Metodo due: pull da un remoto git {% hint style="info" %} La posizione predefinita per il repository locale è `C:\ProgramData\UniversalAutomation\Repository` {% endhint %} Può configurare PowerShell Universal per eseguire il pull da un remoto git. In questa configurazione, deve assicurarsi che la cartella del suo repository locale sia completamente vuota. Qualsiasi file all'interno della cartella causerà il fallimento della sincronizzazione git e ne impedirà il ripristino. Configuri il file `appsettings.json` per includere il branch, le credenziali e l'URL del remoto git che sta clonando. Una volta impostati i campi, può avviare il servizio PowerShell Universal. La prima cosa che il servizio farà sarà clonare il repository e configurarlo localmente. ### Timeout della sincronizzazione git La sincronizzazione git andrà in timeout se non riesce a contattare il remoto dopo 60 minuti. Questo consente il tempo necessario per scaricare repository di grandi dimensioni o per gestire ritardi con reti lente. Potrebbe vedere il servizio PowerShell Universal bloccato su "Synchronizing with git" durante l'avvio mentre il server attende che ciò avvenga. Se desidera ridurre questo tempo, può utilizzare la seguente impostazione di appsetting.json. Il valore è espresso in minuti. {% code collapsedlinecount="10" %} ```json "Data" : { "GitSyncTimeout": 30 } ``` {% endcode %} ### Intervallo di sincronizzazione **Tipo:** Intero\ **Predefinito:** 60\ **appsettings.json:** `GitSyncInterval` L'intervallo, in secondi, tra i tentativi di sincronizzazione Git automatica quando la sincronizzazione automatica è abilitata. Il valore predefinito è 60 secondi (1 minuto). Per regolare la frequenza di sincronizzazione, modifichi `appsettings.json`: {% code collapsedlinecount="10" %} ```json "GitSyncInterval": 300 ``` {% endcode %} Questo cambierebbe l'intervallo di sincronizzazione a 5 minuti. Valori più bassi aumentano la frequenza di sincronizzazione ma possono avere un impatto sulle prestazioni in repository di grandi dimensioni o su reti lente. Impostare questo valore troppo basso (sotto i 30 secondi) non è consigliato per gli ambienti di produzione. ### Risoluzione dei problemi #### Azure DevOps: "Too many redirects or authentication replays" Questo errore indica in genere uno dei seguenti problemi: * **Formato URL legacy:** si assicuri di utilizzare `https://dev.azure.com///_git/` anziché il vecchio dominio `visualstudio.com` * **Ambito PAT non valido:** il suo Personal Access Token deve avere le autorizzazioni **Code (Read & Write)** in Azure DevOps * **Credenziali scadute:** generi un nuovo PAT e lo reinserisca nelle impostazioni Git di PSU * **Spazi codificati:** se il nome del suo repository contiene spazi, si assicuri che siano codificati come `%20` nell'URL **Risoluzione:** 1. Aggiorni l'URL del remoto per utilizzare `dev.azure.com` 2. Generi un nuovo PAT con ambito Code (Read & Write) 3. Abiliti **Use External Git Client** e installi Git per Windows se il client integrato continua a non funzionare #### Tracciamento upstream mancante **Errore:** "There is no tracking information for the current branch" **Causa:** il branch Git locale non è configurato per tracciare un branch remoto. **Risoluzione:** apra PowerShell nella directory del repository ed esegua: {% code collapsedlinecount="10" %} ```powershell git fetch git branch --set-upstream-to=origin/main main git pull ``` {% endcode %} Sostituisca `main` con il nome effettivo del suo branch. Quindi faccia clic su **Synchronize Now** in PSU. #### La sincronizzazione git si interrompe dopo la modifica delle impostazioni nell'interfaccia utente **Sintomi:** dopo aver modificato le impostazioni Git (URL del remoto, credenziali, intervallo di sincronizzazione, ecc.) nell'interfaccia utente di PSU e aver fatto clic su OK, la sincronizzazione smette di funzionare anche se le impostazioni sembrano corrette. **Causa:** in PSU 5.x, le credenziali Git sono memorizzate nel database SQL. Qualsiasi modifica alle impostazioni Git tramite l'interfaccia utente può cancellare le credenziali memorizzate, anche se il campo della password appare ancora compilato nel modulo. **Risoluzione:** 1. Reinserisca il Personal Access Token in **Source Control > Git > Settings** 2. Faccia clic su **OK** per salvare 3. Negli ambienti multi-nodo, **ripeta questo processo su ogni nodo**: le credenziali devono essere inserite individualmente su ciascun server 4. Faccia clic su **Synchronize Now** per verificare che la sincronizzazione funzioni di nuovo Il sistema non propaga automaticamente le credenziali tra i nodi in una configurazione con bilanciamento del carico o ad alta disponibilità. #### Problemi di agente e di rete **Sintomi:** la sincronizzazione funziona su un nodo ma non sugli altri, oppure vede errori `RpcException` o "service is unavailable" nei log. **Cause comuni:** * **Versioni non corrispondenti:** si assicuri che tutti i server e gli agenti PSU eseguano la stessa versione * **Regole del firewall:** gli agenti comunicano con il server PSU tramite gRPC sulle porte **5000** (HTTP) o **5001** (HTTPS) * **Blocco di proxy o WebSocket:** i proxy aziendali possono bloccare o ispezionare il traffico gRPC; configuri git per utilizzare il proxy oppure abiliti External Git Client **Risoluzione:** 1. Verifichi che tutti i nodi eseguano la stessa versione di PSU 2. Controlli che le regole del firewall consentano il traffico sulle porte 5000/5001 3. Testi la connettività gRPC tra i nodi 4. Se utilizza un proxy, configuri le variabili d'ambiente `http_proxy` e `https_proxy` per l'account di servizio PSU #### Docker e distribuzioni containerizzate * Si assicuri che l'immagine del container includa `git` (esegua `git --version` per verificare) * Verifichi l'accesso di rete in uscita verso il remoto git * Monti volumi persistenti per `/data` o `%ProgramData%\UniversalAutomation` per preservare lo stato di git tra i riavvii * Se la sincronizzazione fallisce silenziosamente, controlli i log del container per errori di git o di rete #### Modifica di .git/config senza la CLI Git Se lo strumento da riga di comando Git non è installato sul server e riscontra errori di tracciamento upstream, può modificare la configurazione del repository direttamente tramite il file browser di PSU: 1. Vada su **Platform → Configuration → Repository → .git → config** 2. Aggiunga le righe seguenti (adatti il nome del branch al suo repository): {% code collapsedlinecount="10" %} ```ini [branch "main"] remote = origin merge = refs/heads/main ``` {% endcode %} 3. Clicchi su **Save** 4. Torni a **Source Control > Git > Settings** e clicchi su **Synchronize Now** Questo approccio le consente di configurare il tracciamento upstream senza necessità di comandi `git`, il che è particolarmente utile quando Git for Windows non è installato o quando l'esecuzione avviene con account di servizio soggetti a restrizioni. #### Le impostazioni Git non vengono mantenute Se le modifiche alle impostazioni Git non vengono salvate o vengono annullate subito dopo aver cliccato su OK: **Verifichi le autorizzazioni del file system:** * Arresti il servizio PowerShell Universal * Provi a modificare manualmente `%ProgramData%\PowerShellUniversal\appsettings.json` (o `%ProgramData%\UniversalAutomation\appsettings.json` nelle versioni precedenti) * Aggiunga una riga di commento, salvi e riapra il file per verificare che le modifiche vengano mantenute * Se le modifiche vengono annullate, verifichi la presenza di software antivirus, oggetti Criteri di gruppo (GPO) o autorizzazioni NTFS che impediscono la scrittura nella directory dati di PSU **Abiliti la registrazione di debug per la risoluzione dei problemi:** 1. Arresti il servizio PowerShell Universal 2. Modifichi `appsettings.json` e imposti: {% code collapsedlinecount="10" %} ```json "SystemLogLevel": "Debug" ``` {% endcode %} 3. Salvi e riavvii il servizio 4. Tenti nuovamente di salvare le impostazioni Git 5. Esamini `%PROGRAMDATA%\PowerShellUniversal\systemLog.txt` per individuare errori relativi alla scrittura della configurazione **Popoli manualmente le impostazioni Git:** Con il servizio arrestato, può popolare direttamente i campi Git in `appsettings.json`: {% code collapsedlinecount="10" %} ```json "GitRemote": "https://dev.azure.com/org/project/_git/repo", "GitUserName": "any", "GitPassword": "your-PAT-here", "GitBranch": "main" ``` {% endcode %} Riavvii il servizio e verifichi che le impostazioni compaiano in **Source Control > Git > Settings**. Se scompaiono nuovamente, i log di debug indicheranno se il reset è causato da un problema di autorizzazioni, da un software di endpoint protection o da un errore di convalida della configurazione. ### unknown certificate lookup failure: 16777280 Quando si utilizza la libreria git integrata, potrebbe riscontrare problemi con il certificato durante la connessione a repository git ospitati localmente. In questa configurazione, consigliamo di utilizzare il client git esterno per disporre di un maggiore supporto nella configurazione del processo di ricerca del certificato. ## File inclusi I file inclusi in una sincronizzazione git sono tutti i file presenti nel repository locale. Ciò include i file di configurazione PS1, i file XML delle pagine e qualsiasi altro file che può aggiungere manualmente. Non sono inclusi i seguenti elementi: * appsettings.json * database.db * web.config * Binari dell'applicazione PowerShell Universal ## Più repository Git PowerShell Universal supporta la memorizzazione di più configurazioni di repository git all'interno del database. In questo modo può passare rapidamente da una configurazione di PowerShell Universal all'altra. Clicchi sulla scheda Repositories per visualizzare i repository attualmente configurati. Da qui può eliminare e modificare le configurazioni dei repository. {% hint style="warning" %} PowerShell Universal non rimuove la cartella .git quando si elimina una configurazione di repository. Dovrà farlo manualmente per poter configurare un nuovo repository. {% endhint %} Quando aggiunge una nuova configurazione di repository, può cliccare il pulsante Apply per passare al repository selezionato. Questa operazione eliminerà tutti i file nella directory del repository e clonerà il repository selezionato. Non può applicare una configurazione di repository se sono presenti modifiche non committate nel suo repository. Dopo la clonazione del repository, PowerShell Universal ricaricherà completamente la propria configurazione. ## Pagina della cronologia e dello stato Git La scheda della cronologia mostra tutta la cronologia dei commit git per il repository corrente. La scheda dello stato di sincronizzazione mostra lo stato corrente dei nodi all'interno del cluster PSU. ### Test della sincronizzazione Git Il modo migliore per accertarsi che la sincronizzazione git funzioni correttamente è cliccare il pulsante Synchronize Now. Questo forzerà l'esecuzione di una sincronizzazione e potrà verificare se le impostazioni inserite hanno funzionato correttamente. ### Visualizzazione delle modifiche Può visualizzare le modifiche nella tabella delle sincronizzazioni git. Ogni sincronizzazione include il numero di modifiche rilevate dall'ultima sincronizzazione, lo SHA del commit e un elenco delle modifiche tra tale SHA e quello precedente. Quando i file si trovano in stato modificato, potrà visualizzare le differenze utilizzando lo strumento di diff dei file. ### Gestione dei conflitti {% hint style="info" %} La risoluzione dei conflitti è disponibile solo nella modalità di sincronizzazione git manuale. {% endhint %} Quando più utenti modificano i file di configurazione di PowerShell Universal, possono verificarsi dei conflitti. PowerShell Universal indicherà che un determinato nodo si trova in stato di conflitto quando si tenta di eseguire il commit delle modifiche. Nella pagina di commit git vedrà un elenco delle modifiche in conflitto. Clicchi il pulsante Resolve Conflict per visualizzare il conflitto in un editor. In questo esempio, la stringa di questo endpoint è stata modificata sia nel repository remoto sia in quello locale: * Versione corrente (locale) — tra `<<<<<<< HEAD` e `=======`: `"That endpoint"` * Versione in arrivo (remota) — tra `=======` e `>>>>>>> main`: `"This endpoint"` Modifichi il testo per rimuovere il conflitto. Salvi le modifiche e torni alla pagina di commit git. Inserisca un nuovo messaggio di commit per il conflitto di merge e clicchi Commit Changes. Questo risolverà il conflitto di merge ed eseguirà il push al remoto. ## Comportamento della sincronizzazione Git ### Bidirezionale Per impostazione predefinita, la sincronizzazione git funziona in entrambe le direzioni. Se apporta modifiche nella console di amministrazione PSU, tali modifiche verranno committate e sincronizzate con il remoto configurato. Tutte le modifiche apportate nel remoto verranno scaricate localmente. Se configura la sincronizzazione git con un remoto git preesistente, le modifiche verranno scaricate e sincronizzate localmente. Non può avere alcuna modifica in locale. Se configura la sincronizzazione git con un repository vuoto (bare), le modifiche locali verranno sincronizzate e il repository verrà inizializzato. ### Unidirezionale Può modificare il comportamento della sincronizzazione git cambiando l'impostazione `GitSyncBehavior` in `appsettings.json`. Se impostata su `OneWay`, la console di amministrazione e la management API diventeranno di sola lettura. Il sistema PowerShell Universal eseguirà il pull dal remoto ma non eseguirà mai push o commit in locale. {% 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 %} ### Solo push La modalità di sincronizzazione git solo push non scaricherà le modifiche dal remoto. Tutte le modifiche apportate localmente verranno inviate al remoto. La console non sarà di sola lettura. Questa configurazione è utile negli scenari in cui dispone di una macchina utilizzata come configurazione di riferimento (source-of-truth) per un pool di server di sola lettura. {% 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 %} ## Token di accesso personale Consigliamo di utilizzare un token di accesso personale (PAT) anziché un nome utente e una password. Può configurare un token di accesso personale impostando la proprietà password in `appsettings.json` o tramite altri metodi di configurazione. {% 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 %} ### Token fine-grained di GitHub In GitHub, può recuperare un token fine-grained cliccando sul suo avatar in alto a destra e selezionando Settings, Developers Settings, Personal Access Tokens e infine Fine-Grained Tokens. #### Ambiti del token Durante la generazione del token, si assicuri di assegnare al repository l'autorizzazione `Read-Write` per `Content`. Questo aggiungerà automaticamente Read all'autorizzazione `Metadata`. Può fornire l'accesso soltanto al repository che intende clonare. ### Token GitHub (Classic) In GitHub, può recuperare un token di accesso personale cliccando sul suo avatar in alto a destra e selezionando Settings, Developer Settings, Personal Access Tokens e infine Tokens (Classic). Durante la generazione del token di accesso, si assicuri di selezionare le autorizzazioni Repo. Noti che, se utilizza BitBucket, dovrà specificare il nome utente oltre al PAT in `appsettings.json`. ## Nome utente e password Può anche configurare un remoto git per l'autenticazione con nome utente e password. Imposti il nome utente e la password tramite il file `appsettings.json` o un altro metodo di configurazione. {% 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 %} ## Errori comuni #### Git synchronization failed. unknown certificate lookup failure: 16777280 La libreria lib2gitsharp non è riuscita a convalidare il certificato del repository git remoto. Per risolvere il problema dovrà utilizzare il [client git esterno](#external-git-client) e una configurazione git personalizzata. Alcune opzioni comuni per il supporto HTTPS di git includono: {% 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" o replay di autenticazione Il remoto git ha rifiutato le sue credenziali di accesso al repository. Il suo token di accesso personale potrebbe essere scaduto o non avere accesso al remoto. #### repository not owned by current user Il repository git locale non dispone dei controlli di accesso corretti per l'utente che tenta di accedervi. Questo può accadere se PowerShell Universal ha clonato il repository e successivamente è stato impostato un account di servizio diverso per il servizio. Poiché i controlli di accesso non corrispondono, git non accederà alla cartella. Si tratta di una funzionalità di sicurezza di git. Per evitarlo può aggiornare il proprietario della cartella oppure configurare git in modo che consideri attendibile la cartella. Imposti il valore seguente nella configurazione git globale. {% code collapsedlinecount="10" %} ``` [safe] directory = C:\ProgramData\UniversalAutomation\Repository ``` {% endcode %} La configurazione globale si trova in: `C:\Program Files\git\etc\gitconfig` ## Vantaggi della sincronizzazione Git rispetto alla sincronizzazione Git manuale È possibile sincronizzare manualmente un repository con git. PowerShell Universal utilizza comandi molto semplici quando lavora con git. Qualsiasi modifica apportata a PowerShell Universal tramite la console di amministrazione o le API richiama un `git commit` e l'autore viene impostato sull'identità dell'utente che effettua la modifica. Durante un'operazione di sincronizzazione git, eseguiamo innanzitutto un `git pull` per assicurarci di disporre della versione più recente dei file sul remoto. Successivamente eseguiamo un `git push` per inviare i commit locali effettuati dall'ultima sincronizzazione. Potrebbe ottenere questa funzionalità con un job pianificato. Detto questo, una funzionalità della sincronizzazione git è che analizza il commit per garantire che vengano ricaricati solo i file modificati durante la sincronizzazione. Questo impedisce che le dashboard vengano ridistribuite automaticamente quando non sono cambiate o che i servizi API vengano riavviati quando gli ambienti non sono stati aggiornati. Si ottiene quindi un miglioramento delle prestazioni. L'altro problema è che, a causa del modo in cui PowerShell Universal monitora i file (con un `FileSystemWatcher`) e del modo in cui git aggiorna i file, le configurazioni non verranno ricaricate automaticamente dopo un pull. Dovrà assicurarsi di forzare una nuova valutazione delle configurazioni. ## Strategie di branching Le strategie di branching in git determinano come le modifiche vengono spostate da un branch all'altro. L'utilizzo di diversi tipi di strategie di branching in PowerShell Universal può garantire che team di dimensioni differenti riescano a collaborare in modo efficace all'interno della piattaforma. ### Utenti singoli e piccoli team Per gli utenti singoli e i piccoli team potrebbe non essere necessario avere più di un singolo branch. Il branch viene utilizzato per il tracciamento della cronologia e consente di annullare le modifiche. Gli utenti accederanno direttamente a PowerShell Universal per apportare modifiche oppure eseguiranno il commit delle modifiche nel singolo branch da cloni locali della directory del repository, utilizzando uno strumento come VS Code. * main - Branch singolo che accetta direttamente tutte le modifiche ### Utenti singoli e piccoli team con un branch di staging Anche gli utenti singoli e i piccoli team possono trovare vantaggioso utilizzare un branch di staging, o dev. Questo branch riceverà le modifiche durante lo sviluppo. Un'istanza autonoma di PowerShell Universal verrà configurata per essere eseguita su questo branch dev, in modo che gli utenti possano convalidare le modifiche prima di inviarle in produzione. Quando si utilizza una configurazione con branch di staging, gli ambienti PowerShell Universal sono completamente separati. Utilizzano un database e uno scheduler differenti. Dati come identità, token delle app e cronologia dei job non sono condivisi tra gli ambienti. {% hint style="info" %} Ogni istanza di PowerShell Universal richiede una [licenza](/powershell-universal/it/licensing.md). In questa configurazione sarebbero necessarie due licenze. {% endhint %} È quindi possibile configurare un'istanza separata di PowerShell Universal per puntare a un branch main, o di produzione, che riceverà gli aggiornamenti tramite merge o Pull Request in un sistema come GitHub. In questa configurazione è possibile utilizzare la sincronizzazione git unidirezionale per scaricare le modifiche da main senza mai eseguire push dalla piattaforma. Questo previene inoltre la maggior parte dei conflitti di merge, poiché verranno gestiti nel branch dev o tramite lo strumento di merge nel repository di origine. * main - Branch di produzione che riceve le modifiche dalle pull request del branch dev * dev - Il branch di staging utilizzato per accettare i commit e convalidare le modifiche prima di inviarle a master. ### Team di medie e grandi dimensioni Nel caso di team con più di un paio di sviluppatori, una strategia di branching più complessa può risultare utile per valutare meglio le modifiche al codice ed evitare conflitti di merge. PowerShell Universal offre strumenti di merge di base, ma per questo scopo sono disponibili strumenti migliori, come le pull request di GitHub, le merge request di GitLab e strumenti locali come GitKraken. Nei team di medie dimensioni può essere opportuno disporre di branch di funzionalità aggiuntivi che isolino modifiche specifiche in un determinato branch. Ad esempio, uno sviluppatore potrebbe creare un nuovo set di API per gestire Azure in PowerShell Universal. Per evitare modifiche che compromettano il branch dev, gli sviluppatori creeranno un proprio branch di funzionalità contenente tutte le loro modifiche, finché non sarà sufficientemente completo da poter essere unito al branch di sviluppo. {% hint style="info" %} PowerShell Universal offre [licenze per sviluppatori](/powershell-universal/it/licensing.md) per evitare di dover acquistare una licenza per ogni sviluppatore del suo team. Le licenze sarebbero comunque necessarie per gli ambienti di produzione e di staging. {% endhint %} In questo tipo di configurazione lo sviluppo locale è ideale, poiché gli sviluppatori lavoreranno sulla loro istanza locale di PowerShell Universal all'interno del proprio branch di funzionalità. Quando la funzionalità è completa, creeranno una Pull o Merge request nel repository di origine per spostare le modifiche nel branch dev. I test verranno completati sul branch dev prima del merge in produzione. Analogamente a una strategia di branching main\dev, tutte le istanze di PowerShell Universal saranno isolate e non condivideranno un database o uno scheduler. Una volta che un set di funzionalità è pronto per la produzione, verrà creata una Pull o Merge request da dev verso il branch main. * main - Branch di produzione che riceverà modifiche solo da dev * dev - Branch di staging che riceve le modifiche dai branch di funzionalità ma non viene modificato direttamente * feature - Branch di funzionalità su cui gli sviluppatori eseguono direttamente i commit e che viene unito a dev quando è pronto A seconda della complessità del suo ambiente, potrebbe essere consigliabile utilizzare i Deployment anziché git in produzione. Consulti la sezione Team di grandi dimensioni più avanti per maggiori informazioni. ### Team di grandi dimensioni Nei team di grandi dimensioni consigliamo di utilizzare git a scopo di sviluppo, ma di utilizzare i Deployment, o un concetto simile, per la produzione. I [Deployment ](/powershell-universal/it/config/deployments.md)forniscono pacchetti di configurazione immutabili che sono stati accuratamente testati in ambienti di livello inferiore. Utilizzando i Deployment può scegliere come sviluppare e gestire il suo codice e semplicemente pubblicare il risultato negli ambienti di sviluppo, staging, QA e produzione. Questo garantisce che tutto il codice sia accuratamente testato prima della distribuzione nei suoi sistemi critici. Può utilizzare workflow automatizzati, come GitHub Actions, per pubblicare i suoi Deployment senza dover aggiornare manualmente alcun sistema. ## Hosting Git PowerShell Universal supporta qualsiasi soluzione standard di hosting git. I nostri clienti utilizzano frequentemente le seguenti: * GitHub * GitHub Enterprise * GitLab * Bitbucket * Azure DevOps Sebbene queste siano le piattaforme più comuni, supportiamo qualsiasi piattaforma che utilizzi il protocollo git. ### Esempio: Gitea È inoltre possibile utilizzare soluzioni semplici e self-hosted come [Gitea](https://gitea.com). Ecco un esempio di come configurare facilmente un container docker Gitea da utilizzare con 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/it/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.