> 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 {% 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 modificando 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 in Impostazioni \ Git all'interno della console di amministrazione. Potrà fare clic sul pulsante Create Git Settings.

Finestra di dialogo 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, dovrà reinserire le credenziali su ogni nodo singolarmente dopo aver effettuato le 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 ha 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`. #### Correzione del tracking upstream mancante Se riscontra l'errore **"There is no tracking information for the current branch"**, il branch locale non è collegato al remoto. Per risolvere il problema: 1. Apra PowerShell in `%ProgramData%\UniversalAutomation\Repository` (o nel percorso del repository configurato) 2. Esegua: ```powershell git fetch git branch --set-upstream-to=origin/main main git pull ``` ### 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. Sono necessarie credenziali corrette per accedere a tale remoto. #### 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:** ``` https://dev.azure.com///_git/ ``` **Esempi:** ``` https://dev.azure.com/mycompany/MyProject/_git/PowerShellUniversal https://dev.azure.com/mycompany/MyProject/_git/PSU%20Scripts ``` Se il nome del suo repository contiene spazi, questi devono essere codificati come `%20` nell'URL. Eviti di utilizzare URL con il vecchio dominio `visualstudio.com`, poiché potrebbero 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 varie 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 GitLab si aspettano invece un header `Private-Token`. ### Autenticazione Dovrà configurare l'autenticazione al 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. Ciò le consente opzioni di configurazione aggiuntive, come l'utilizzo dell'autenticazione SSH. PowerShell Universal non utilizzerà i nomi utente, le password o i 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 Platform \ 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. All'interno della 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 la clonazione del suo repository. ``` git@github.com:ironmansoftware/psu-devo ```

URL SSH di GitHub

#### Impostazione delle credenziali Quando utilizza il client git esterno, è responsabile della configurazione delle 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 con l'URL di destinazione. Potrebbe essere necessario modificare l'URL a seconda del suo remoto git. ```batch git config --global credential.helper store echo "https://${username}:${password_or_access_token}@github.com" > ~/.git-credentials ``` Può anche memorizzare le credenziali direttamente nell'URL fornito a PowerShell Universal. ``` https://adam:APP_TOKEN@github.com/myOrg/myRepo.git ``` #### 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: ``` https://username:PAT@github.com/ironmansoftware/universal ``` #### Esempio: SSH e GitHub Innanzitutto, 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. ``` git@github.com:ironmansoftware/universal.git ``` #### Problema con il certificato SSL {% hint style="warning" %} SSL Certificate problem: unable to get local issuer certificate {% endhint %} Se sta eseguendo su Windows e riceve un problema relativo al 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 al sistema.
Una volta completate le modifiche, l'utente può fare clic su Save Changes per avviare un commit
Nella pagina di commit git, può visualizzare i file modificati e inserire un messaggio di commit.
Una volta eseguito il commit delle modifiche, queste verranno inviate al remoto e il servizio inizierà nuovamente a sincronizzarsi con git. In questo momento esiste anche la possibilità che 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`. ```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 }, ``` ### 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 suo repository dovrebbe essere semplicemente una cartella con i suoi file di 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 un file di licenza o readme.md. ![](/files/wbz1KelskCgXwibvuB9U) Una volta creato il repository, può recuperare l'URL del remoto git e fornirlo al file `appsettings.json` di PowerShell Universal. ![](/files/m0LwgU8GN1EHZjSVVo6m) 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` in modo da 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 farà il servizio 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. Ciò consente il tempo necessario per scaricare repository di grandi dimensioni o per far fronte a 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. ```json "Data" : { "GitSyncTimeout": 30 } ``` ### Intervallo di sincronizzazione **Tipo:** Integer\ **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`: ```json "GitSyncInterval": 300 ``` Questo modificherebbe 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 (al di sotto di 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 l'ambito Code (Read & Write) 3. Abiliti **Use External Git Client** e installi Git for Windows se il client integrato continua a non funzionare #### Tracking 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: ```powershell git fetch git branch --set-upstream-to=origin/main main git pull ``` 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 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 sembra ancora compilato nel modulo. **Risoluzione:** 1. Reinserisca il Personal Access Token in **Impostazioni → Git** 2. Faccia clic su **OK** per salvare 3. Negli ambienti multi-nodo, **ripeta questo processo su ogni nodo**: le credenziali devono essere inserite singolarmente 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 agent e di rete **Sintomi:** la sincronizzazione funziona su un nodo ma non riesce sugli altri, oppure vede errori `RpcException` o "service is unavailable" nei log. **Cause comuni:** * **Mancata corrispondenza delle versioni:** si assicuri che tutti i server e gli agent PSU eseguano la stessa versione * **Regole del firewall:** gli agent 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 o abiliti il client Git esterno **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 di ambiente `http_proxy` e `https_proxy` per l'account di servizio PSU #### Distribuzioni Docker e containerizzate * Si assicuri che l'immagine del container includa `git` (esegua `git --version` per verificare) * Verifichi l'accesso di rete in uscita al 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 individuare errori git o di rete #### Modifica di .git/config senza la CLI di Git Se lo strumento da riga di comando Git non è installato sul server e si verificano errori di tracciamento upstream, può modificare direttamente la configurazione del repository tramite il file browser di PSU: 1. Vada a **Platform → Configurazione → Repository → .git → config** 2. Aggiunga le righe seguenti (adatti il nome del branch al suo repository): ```ini [branch "main"] remote = origin merge = refs/heads/main ``` 3. Faccia clic su **Salva** 4. Torni a **Impostazioni → Git** e faccia clic su **Sincronizza ora** Questo approccio consente di configurare il tracciamento upstream senza bisogno dei comandi `git`, il che è particolarmente utile quando Git for Windows non è installato o quando si esegue con account di servizio con restrizioni. #### Le impostazioni Git non vengono mantenute Se le modifiche alle impostazioni Git non vengono salvate o vengono ripristinate subito dopo aver fatto clic 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 siano state mantenute * Se le modifiche vengono ripristinate, verifichi la presenza di software antivirus, oggetti Criteri di gruppo (GPO) o autorizzazioni NTFS che bloccano le scritture nella directory dati di PSU **Abiliti il logging di debug per la risoluzione dei problemi:** 1. Arresti il servizio PowerShell Universal 2. Modifichi `appsettings.json` e imposti: ```json "SystemLogLevel": "Debug" ``` 3. Salvi e riavvii il servizio 4. Provi nuovamente a salvare le impostazioni Git 5. Esamini `%PROGRAMDATA%\PowerShellUniversal\systemLog.txt` per individuare errori relativi alle scritture di configurazione **Popoli manualmente le impostazioni Git:** Con il servizio arrestato, può popolare direttamente i campi Git in `appsettings.json`: ```json "GitRemote": "https://dev.azure.com/org/project/_git/repo", "GitUserName": "any", "GitPassword": "your-PAT-here", "GitBranch": "main" ``` Riavvii il servizio e verifichi che le impostazioni compaiano in **Impostazioni → Git**. Se scompaiono di nuovo, i log di debug indicheranno se il ripristino è causato da un problema di autorizzazioni, da software di protezione degli endpoint 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 fornire maggiore supporto alla configurazione del processo di ricerca del certificato. ## File inclusi I file inclusi in una sincronizzazione git sono tutti i file all'interno del repository locale. Ciò include i file di configurazione PS1, i file XML delle pagine e qualsiasi altro file che può aggiungere manualmente. I seguenti non sono inclusi: * appsettings.json * database.db * web.config * Binari dell'applicazione PowerShell Universal ## Più repository Git PowerShell Universal supporta l'archiviazione di più configurazioni di repository git all'interno del database. In questo modo, può passare rapidamente da una configurazione all'altra di PowerShell Universal. Faccia clic 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 elimina una configurazione di repository. Dovrà farlo manualmente per poter configurare un nuovo repository. {% endhint %} Quando aggiunge una nuova configurazione di repository, può fare clic sul pulsante Applica per passare al repository selezionato. Ciò eliminerà tutti i file nella directory del repository e clonerà il repository selezionato. Non è possibile applicare una configurazione di repository se sono presenti modifiche non sottoposte a commit nel repository. Dopo aver clonato il repository, PowerShell Universal ricaricherà completamente la sua configurazione. ## Pagina della cronologia e dello stato di 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 attuale dei nodi all'interno del cluster PSU.
### Test della sincronizzazione Git Il modo migliore per assicurarsi che la sincronizzazione git funzioni correttamente è fare clic sul pulsante Sincronizza ora. Ciò forzerà l'esecuzione di una sincronizzazione e potrà verificare se le impostazioni inserite funzionano correttamente. ![](/files/XBcMgWDcH9G8s8OGKt90) ### 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 quello SHA e il precedente. Quando i file sono in stato modificato, potrà visualizzare le differenze utilizzando lo strumento di diff dei file. ![](/files/a9IuTjbVU3Fy6pknKqIF) ### 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 conflitti. PowerShell Universal indicherà che un determinato nodo si trova in stato di conflitto quando si tenta di eseguire il commit delle modifiche. Vedrà un elenco delle modifiche in conflitto nella pagina di commit git. Faccia clic sul pulsante Risolvi conflitto per visualizzare il conflitto in un editor.
In questo esempio, la stringa per questo endpoint è stata modificata sia nel repository remoto sia in quello locale.
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 faccia clic su Esegui commit delle modifiche.
Ciò 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 sottoposte a commit e sincronizzate con il remoto configurato. Tutte le modifiche apportate nel remoto verranno estratte (pull) localmente. Se configura la sincronizzazione git con un remoto git preesistente, le modifiche verranno estratte 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ò regolare il comportamento della sincronizzazione git modificando l'impostazione `GitSyncBehavior` in `appsettings.json`. Se impostata su `OneWay`, la console di amministrazione e l'API di gestione diventeranno di sola lettura. Il sistema PowerShell Universal eseguirà il pull dal remoto ma non eseguirà mai push o commit localmente. ```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": "" }, ``` ### Solo push La modalità di sincronizzazione git solo push non esegue il pull delle modifiche dal remoto. Tutte le modifiche apportate localmente verranno inviate al remoto. La console non sarà di sola lettura. Questa configurazione è utile per scenari in cui si dispone di una macchina utilizzata per la configurazione di riferimento (source-of-truth) di un pool di server di sola lettura. ```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": "" }, ``` ## 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 con altri metodi di configurazione. ```javascript "Data": { "RepositoryPath": "%ProgramData%\\UniversalAutomation\\Repository", "ConnectionString": "%ProgramData%\\UniversalAutomation\\database.db", "GitRemote": "https://github.com/myorg/myrepo.git", "GitUserName": "any", "GitPassword": "MYPAT----------------" }, ``` ### Token fine-grained di GitHub In GitHub, può recuperare un token fine-grained facendo clic sul suo avatar in alto a destra e selezionando Settings, Developers Settings, Personal Access Tokens e infine Fine-Grained Tokens. #### Ambiti dei token Quando genera il token, si assicuri di concedere al repository l'autorizzazione `Read-Write` per `Content`. Ciò aggiungerà automaticamente Read all'autorizzazione `Metadata`. Può fornire l'accesso solo al repository che intende clonare. ### Token GitHub (Classic) In GitHub, può recuperare un token di accesso personale facendo clic sul suo avatar in alto a destra e selezionando Settings, Developer Settings, Personal Access Tokens e infine Tokens (Classic). Quando genera il token di accesso, si assicuri di selezionare le autorizzazioni Repo. ![](/files/KBaYTp7M1omRXYOetwlJ) Nota: 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. ```javascript "Data": { "RepositoryPath": "%ProgramData%\\UniversalAutomation\\Repository", "ConnectionString": "%ProgramData%\\UniversalAutomation\\database.db", "GitRemote": "https://github.com/myorg/myrepo.git", "GitUserName": "myusername", "GitPassword": "mypassword" }, ``` ## Errori comuni #### Git synchronization failed. unknown certificate lookup failure: 16777280 La libreria lib2gitsharp non è riuscita a convalidare il certificato del repository git remoto. Dovrà utilizzare il [client git esterno](#external-git-client) e una configurazione git personalizzata per risolvere il problema. Alcune opzioni comuni per il supporto HTTPS di git includono: ``` 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" o replay di autenticazione Il remoto git ha rifiutato le sue credenziali per accedere 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. Ciò può accadere se PowerShell Universal ha clonato il repository e successivamente è stato impostato un account di servizio diverso sul servizio. Poiché i controlli di accesso non corrispondono, git non accederà alla cartella. Questa è una funzionalità di sicurezza di git. Può aggiornare il proprietario della cartella per evitare questo problema oppure configurare git per considerare attendibile la cartella. Imposti il valore seguente nella configurazione git globale. ``` [safe] directory = C:\ProgramData\UniversalAutomation\Repository ``` 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 git. PowerShell Universal utilizza comandi molto basilari quando si tratta di git. Qualsiasi modifica apportata a PowerShell Universal tramite la console di amministrazione o l'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 prima un `git pull` per assicurarci di avere la versione più recente dei file sul remoto. Successivamente, eseguiamo un `git push` per inviare i commit locali avvenuti 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. Ciò impedirà alle dashboard di essere distribuite automaticamente quando non sono cambiate o ai servizi API di riavviarsi quando gli ambienti non sono stati aggiornati. Si ottiene quindi un guadagno in termini di 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 la rivalutazione 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 diverse possano lavorare insieme in modo efficace nella piattaforma. ### Utenti singoli e piccoli team Per utenti singoli e piccoli team, potrebbe non essere necessario avere più di un singolo branch. Il branch viene utilizzato per il tracciamento della cronologia e offre la possibilità 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 - Singolo branch 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 diversi. Dati come identità, token 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 in modo che punti 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 estrarre le modifiche da main senza mai eseguire il push dalla piattaforma. Ciò previene anche la maggior parte dei conflitti di merge, poiché verranno risolti 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 Quando si considerano team con più di un paio di sviluppatori, una strategia di branching più complessa può essere utile per valutare meglio le modifiche al codice ed evitare conflitti di merge. PowerShell Universal fornisce 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 desiderabile avere 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 il proprio branch di funzionalità che conterrà tutte le loro modifiche fino a quando non sarà sufficientemente completo per essere unito al branch di sviluppo. {% hint style="info" %} PowerShell Universal fornisce [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 perché gli sviluppatori lavoreranno sulla loro istanza locale di PowerShell Universal all'interno del loro 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à effettuata una pull o merge request da dev al 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 per scopi 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 testati a fondo negli 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. Ciò garantisce che tutto il codice sia ben 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 di hosting git standard. I nostri clienti utilizzano spesso 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.