> 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/da/config/git.md). # Git Synkroniser PowerShell Universal-konfigurationen med et eksternt git-lager, herunder grene, godkendelse, synkroniseringsadfærd og fejlfinding af konflikter. {% hint style="info" %} Git-integration kræver en [licens](https://store.devolutions.net/package#psu). {% endhint %} PowerShell Universal er i stand til at synkronisere konfigurationsscriptsene med et eksternt git-lager. ## Konfiguration ### Admin Console Git-synkronisering kan konfigureres i databasen ved at justere indstillingerne i Admin Console. Dette er den foretrukne fremgangsmåde. Fordelen er, at når De forbinder nye instanser af PowerShell Universal med Deres SQL-instans, behøver De ikke konfigurere git-synkronisering igen. For at konfigurere git-synkronisering skal De navigere til Source Control > Git > Settings i Admin Console. De vil kunne klikke på knappen Create Git Settings. {% hint style="info" %} I PowerShell Universal 5.x og nyere gemmes Git-legitimationsoplysninger (Remote URL, Username og personligt adgangstoken) i SQL-databasen i stedet for i appsettings.json. Redigering af disse indstillinger i brugergrænsefladen opdaterer databasen. Hvis De redigerer Git-indstillinger og derefter klikker på OK, kan PSU rydde gemte legitimationsoplysninger, selv om felterne ser udfyldte ud. I miljøer med flere noder skal De angive legitimationsoplysningerne igen på hver node for sig, efter at De har foretaget ændringer. {% endhint %} ### appsettings.json De kan også bruge [Konfigurationsindstillinger](/powershell-universal/da/config/settings.md) til at opsætte git-synkronisering. Dette er nyttigt, hvis De har en enkelt instans af PSU og gerne vil sikkerhedskopiere filen appsettings.json. Justering af indstillinger i admin console opdaterer ikke filen appsettings.json. De skal gøre det manuelt og genstarte PowerShell Universal, når De har ændret indstillingerne. Hvis indstillinger for git-synkronisering er angivet i databasen, ignoreres indstillinger, der er defineret i appsettings.json. ## Indstillinger for Git-synkronisering ### Gren Som standard synkroniserer PowerShell Universal med grenen `master`. Hvis De vil bruge en anden gren, skal De angive indstillingen `GitBranch` i Deres `appsettings.json`. #### Løsning af manglende upstream-sporing Hvis De støder på fejlen **"There is no tracking information for the current branch"**, er den lokale gren ikke knyttet til fjernlageret. Sådan løser De det: 1. Åbn PowerShell i `%ProgramData%\UniversalAutomation\Repository` (eller den konfigurerede lagersti) 2. Kør: {% code collapsedlinecount="10" %} ```powershell git fetch git branch --set-upstream-to=origin/main main git pull ``` {% endcode %} ### Fjernlager Fjernlagre er ikke påkrævede. Hvis et fjernlager ikke er angivet, gemmes git-lageret lokalt i lagerkataloget. Hvis det er angivet, vil PowerShell Universal synkronisere med fjernlageret. Korrekte legitimationsoplysninger er påkrævede for adgang til det fjernlager. #### Azure DevOps-URL-format Azure DevOps-lagre bør bruge det moderne URL-format `dev.azure.com` frem for det ældre domæne `visualstudio.com`: **Korrekt format:** {% code collapsedlinecount="10" %} ``` https://dev.azure.com///_git/ ``` {% endcode %} **Eksempler:** {% code collapsedlinecount="10" %} ``` https://dev.azure.com/mycompany/MyProject/_git/PowerShellUniversal https://dev.azure.com/mycompany/MyProject/_git/PSU%20Scripts ``` {% endcode %} Hvis Deres lagernavn indeholder mellemrum, skal de kodes som `%20` i URL'en. Undgå at bruge URL'er med det ældre domæne `visualstudio.com`, da de kan forårsage omdirigeringsløkker eller godkendelsesfejl med fejlen "too many redirects or authentication replays". For Azure DevOps skal Deres personlige adgangstoken have omfanget **Code (Read & Write)**. Fine-grained tokens fungerer, men klassiske PAT'er anbefales af hensyn til kompatibilitet på tværs af PSU-versioner. **Bemærkning til GitLab-brugere:** Hvis Deres GitLab-instans kræver headerbaseret godkendelse, skal De muligvis bruge indstillingen External Git Client og konfigurere Git-hjælpere til legitimationsoplysninger, da den indbyggede Git-klient i PSU bruger HTTP Basic-godkendelse med PAT'en som adgangskode. Nogle GitLab-konfigurationer forventer i stedet en `Private-Token`-header. ### Godkendelse De skal konfigurere godkendelse til Deres eksterne git-lager. Vi anbefaler et personligt adgangstoken. ### Ekstern Git-klient De kan vælge at bruge en ekstern git-klient i stedet for det bibliotek, der er indbygget i PowerShell Universal. Dette giver Dem yderligere konfigurationsmuligheder, f.eks. brug af SSH-godkendelse. PowerShell Universal bruger ikke konfigureret brugernavn, adgangskoder eller PAT'er, når denne metode aktiveres. De skal have en git-klient installeret. #### Brug af SSH-nøgler De kan bruge PowerShell Universal til at generere og administrere SSH-nøgler. Klik på Source Control > SSH Keys i admin console. Generer en ny SSH-nøgle. Klik derefter på kopieringsknappen ud for SSH-nøglen for at hente den offentlige nøgle. Registrer den offentlige nøgle hos mållageret eller kontoen. De kan f.eks. følge [GitHub-vejledningen](https://docs.github.com/en/authentication/connecting-to-github-with-ssh) her. I vinduet Git Settings skal De vælge den SSH-nøgle, De vil bruge til git-synkroniseringen. Når De bruger SSH-nøgler, skal De sikre, at SSH-URL'en er valgt til kloning af Deres lager. {% code collapsedlinecount="10" %} ``` git@github.com:ironmansoftware/psu-devo ``` {% endcode %} #### Angivelse af legitimationsoplysninger Når De bruger den eksterne git-klient, er De ansvarlig for at konfigurere legitimationsoplysninger, før De udfører en synkronisering. De kan konfigurere legitimationsoplysninger via git-konfiguration eller den URL, der overføres til PowerShell Universal. Følgende kommando gemmer legitimationsoplysningerne i klartekst på PowerShell Universal-serveren. De skal køre denne kommando som tjenestekontobrugeren, så vedkommende har adgang til legitimationsoplysningerne. Dette opretter en `.git-credentials`-fil, der bruges ved godkendelse mod mål-URL'en. De skal muligvis ændre URL'en afhængigt af Deres git-remote. {% code collapsedlinecount="10" %} ```batch git config --global credential.helper store echo "https://${username}:${password_or_access_token}@github.com" > ~/.git-credentials ``` {% endcode %} De kan også gemme legitimationsoplysninger direkte i den URL, der er angivet til PowerShell Universal. {% code collapsedlinecount="10" %} ``` https://adam:APP_TOKEN@github.com/myOrg/myRepo.git ``` {% endcode %} #### Eksempel: brugernavn og PAT For at bruge en ekstern git-klient og sende et brugernavn og et PAT, som der skal godkendes med, kan De angive dem i URL'en til git-fjernlageret. For eksempel: {% code collapsedlinecount="10" %} ``` https://username:PAT@github.com/devolutions/powershell-universal ``` {% endcode %} #### Eksempel: SSH og GitHub Først skal De konfigurere Deres lokale ssh-agent og GitHub-konto med SSH-nøgler. De kan følge deres [vejledning her](https://docs.github.com/en/authentication/connecting-to-github-with-ssh). Dernæst skal De angive en SSH-URI til URL'en for git-fjernlageret i PowerShell Universal. Den konfigurerede SSH-nøgle bruges til forbindelsen. {% code collapsedlinecount="10" %} ``` git@github.com:devolutions/powershell-universal.git ``` {% endcode %} #### SSL-certifikatproblem {% hint style="warning" %} SSL Certificate problem: unable to get local issuer certificate {% endhint %} Hvis De kører på Windows og får et SSL-certifikatproblem, skal De muligvis sikre, at De har [aktiveret schannel-understøttelse](https://stackoverflow.com/questions/23885449/unable-to-resolve-unable-to-get-local-issuer-certificate-using-git-on-windows). #### Persistens af legitimationsoplysninger {% hint style="warning" %} Unable to persist credentials with the 'wincredman' credential store. {% endhint %} Hvis De er på Windows og får en fejl om at bevare legitimationsoplysninger i wincredman, skal De muligvis angive persistensen for legitimationsoplysninger til DAPI. De kan [lære, hvordan De gør det, her](https://github.com/git-ecosystem/git-credential-manager/issues/633). #### Commit-signering Det indbyggede git-bibliotek kan ikke signere commits, og det ignorerer `commit.gpgsign`. For at signere de commits, som PowerShell Universal opretter, skal De aktivere External Git Client. PowerShell Universal kører derefter den installerede eksekverbare fil `git`, som læser standardkonfigurationen for git, så både signering og push-legitimationsoplysninger fungerer. Vi anbefaler SSH-signering frem for GPG. PowerShell Universal kører git fra en tjeneste uden interaktivt skrivebord, hvor `gpg-agent` og dens prompt om adgangssætning er upålidelige. Brug en signeringsnøgle uden adgangssætning, som tjenestekontoen kan læse. Den samme nøgle skal stå tre steder: * `user.signingkey` - den nøgle, git signerer med. Peg den på filen med den private nøgle, da tjenesten ikke har nogen `ssh-agent`-session. * Filen med tilladte underskrivere, der refereres til af `gpg.ssh.allowedSignersFile` - bruges af git til at verificere signaturer lokalt (for eksempel `git log --show-signature`). * Deres git-vært - registrer den offentlige nøgle som en **Signing Key** (på GitHub og GitLab er denne adskilt fra en godkendelsesnøgle). En minimal konfiguration: {% code collapsedlinecount="10" %} ```ini [gpg] format = ssh [gpg "ssh"] allowedSignersFile = C:/ProgramData/git/allowed_signers [user] signingkey = C:/ProgramData/git/psu_signing_key [commit] gpgsign = true ``` {% endcode %} Hver linje i filen med tilladte underskrivere indeholder committerens e-mail efterfulgt af den offentlige nøgle: {% code collapsedlinecount="10" %} ``` psu@example.com ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAA... ``` {% endcode %} **Committer-identitet** PowerShell Universal angiver selv commit-forfatteren og committeren og ignorerer `user.name` og `user.email`. Som standard er committeren `PowerShell Universal `, hvilket ikke er en gyldig e-mailadresse. GitHub og GitLab markerer kun et signeret commit som **Verified**, når committerens e-mail stemmer overens med en verificeret e-mail på den konto, der ejer signeringsnøglen, så disse commits vises som **Unverified**, selv med en gyldig signatur. For at løse dette skal De tilføje committer-identiteten i indstillingen [Git Environment Variables](#git-environment-variables). Git giver disse variabler forrang frem for sin konfiguration. {% code collapsedlinecount="10" %} ``` GIT_COMMITTER_NAME=PSU Service GIT_COMMITTER_EMAIL=psu@example.com ``` {% endcode %} {% hint style="warning" %} Angiv kun committer-variablerne. `GIT_AUTHOR_NAME` og `GIT_AUTHOR_EMAIL` ville også tilsidesætte PowerShell Universals forfatter, som er angivet til identiteten for den bruger, der foretager ændringen, og hver commit ville blive tilskrevet den samme forfatter. {% endhint %} **Konfigurationsomfang for tjenestekonto** Som standard kører PowerShell Universal-tjenesten som `LocalSystem`. Kontoen læser sin globale git-konfiguration fra `C:\Windows\System32\config\systemprofile\.gitconfig`, ikke fra profilen for den bruger, der er logget på. Indstillinger, der er oprettet med `git config --global` i en interaktiv session, anvendes derfor ikke på tjenesten. For at anvende signeringskonfigurationen uanset tjenestekontoen skal De køre kommandoerne fra en forhøjet prompt med systemomfanget: {% code collapsedlinecount="10" %} ```powershell git config --system gpg.format ssh git config --system gpg.ssh.allowedSignersFile "C:/ProgramData/git/allowed_signers" git config --system user.signingkey "C:/ProgramData/git/psu_signing_key" git config --system commit.gpgsign true ``` {% endcode %} Sørg for, at tjenestekontoen kan læse nøglen og filerne med tilladte underskrivere. ### Manuel tilstand Manuel tilstand kræver, at brugere, der redigerer PowerShell Universal-instansen, klikker på Edit for at foretage ændringer i systemet. Når ændringerne er fuldført, kan brugeren derefter klikke på Save Changes for at starte en commit På git commit-siden kan De se de ændrede filer og angive en commit-meddelelse. Når ændringer er committet, push'es de til fjernlageret, og tjenesten begynder at synkronisere med git igen. Der er også en mulighed for, at der opstår en git-mergekonflikt på dette tidspunkt. Se [Håndtering af konflikter](#dealing-with-conflicts) for at få flere oplysninger. Manuel tilstand kan angives i git-indstillingerne i admin console eller i `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 %} ### Metode et: push af lokale filer til fjernlageret {% hint style="info" %} Standardplaceringen for det lokale lager er `C:\ProgramData\UniversalAutomation\Repository` {% endhint %} De skal sikre, at Deres lokale mappe ikke er et allerede eksisterende git-lager. Deres lagerkatalog skal blot være en mappe med Deres PowerShell Universal-filer. Hvis der findes en `.git`-mappe, og De ikke ønsker at bruge dette lager, bør De slette den, og PowerShell Universal vil oprette et nyt lager. Hvis De udfylder et nyt git-lager, skal De sikre, at fjernlageret ikke indeholder nogen filer. Det skal være et helt bart lager. Når De f.eks. opretter et lager på GitHub, vælg ikke en licens eller en readme.md-fil, som skal oprettes. Når lageret er oprettet, kan De hente URL'en til git-fjernlageret og angive den i PowerShell Universals `appsettings.json`-fil. Når De har grenen, URL'en til git-fjernlageret og legitimationsoplysningerne, kan De angive dem i Deres `appsettings.json`-fil, og git-fjernlageret udfyldes med Deres lokale filer. ### Metode to: hentning fra et Git-fjernlager {% hint style="info" %} Standardplaceringen for det lokale lager er `C:\ProgramData\UniversalAutomation\Repository` {% endhint %} De kan konfigurere PowerShell Universal til at hente fra et git-fjernlager. I denne konfiguration skal De sikre, at Deres lokale lagermappe er helt tom. Eventuelle filer i mappen får git-synkroniseringen til at mislykkes og forhindrer den i at gendanne sig. Konfigurer filen `appsettings.json`, så den indeholder den branch, legitimationsoplysningerne og den git-fjern-URL, som De kloner. Når felterne er angivet, kan De starte PowerShell Universal-tjenesten. Det første, tjenesten gør, er at klone lageret og konfigurere det lokalt. ### Timeout for Git-synkronisering Git-synkronisering får timeout, hvis den ikke kan kontakte fjernlageret efter 60 minutter. Det giver tid til at downloade store lagre eller til forsinkelse ved langsomme netværk. De kan opleve, at PowerShell Universal-tjenesten hænger ved "Synchronizing with git" under opstart, mens serveren venter på, at det sker. Hvis De ønsker at reducere denne tid, kan De bruge følgende indstilling i appsetting.json. Værdien er i minutter. {% code collapsedlinecount="10" %} ```json "Data" : { "GitSyncTimeout": 30 } ``` {% endcode %} ### Synkroniseringsinterval **Type:** Integer\ **Standard:** 60\ **appsettings.json:** `GitSyncInterval` Intervallet i sekunder mellem automatiske forsøg på Git-synkronisering, når automatisk synkronisering er aktiveret. Standardværdien er 60 sekunder (1 minut). For at justere synkroniseringsfrekvensen skal De redigere `appsettings.json`: {% code collapsedlinecount="10" %} ```json "GitSyncInterval": 300 ``` {% endcode %} Dette ville ændre synkroniseringsintervallet til 5 minutter. Lavere værdier øger synkroniseringsfrekvensen, men kan påvirke ydeevnen i store lagre eller langsomme netværk. Det anbefales ikke at angive denne værdi for lavt (under 30 sekunder) i produktionsmiljøer. ### Git-miljøvariabler **Type:** Liste over strenge\ **Standard:** Tom Miljøvariabler, der angives for hver git-proces, som PowerShell Universal kører. Angiv hver variabel i vinduet Git Settings i formatet `Name=Value`, for eksempel `GIT_SSL_NO_VERIFY=true`. Værdien må ikke indeholde tegnet `=`. Miljøvariabler har forrang frem for git-konfiguration, hvilket gør denne indstilling nyttig til at tilsidesætte værdier som committerens identitet. Se [Commit Signing](#commit-signing). Denne indstilling gælder, når External Git Client er aktiveret, da det indbyggede git-bibliotek ikke starter en git-proces. ### Fejlfinding #### Azure DevOps: "Too many redirects or authentication replays" Denne fejl angiver typisk et af følgende problemer: * **Ældre URL-format:** Sørg for, at De bruger `https://dev.azure.com///_git/` i stedet for det ældre `visualstudio.com`-domæne * **Ugyldigt PAT-omfang:** Deres personlige adgangstoken skal have tilladelserne **Code (Read & Write)** i Azure DevOps * **Udløbne legitimationsoplysninger:** Generer en ny PAT, og angiv den igen i PSU's Git-indstillinger * **Kodede mellemrum:** Hvis Deres lagernavn indeholder mellemrum, skal De sikre, at de er kodet som `%20` i URL'en **Løsning:** 1. Opdater fjern-URL'en, så den bruger `dev.azure.com` 2. Generer en ny PAT med omfanget Code (Read & Write) 3. Aktivér **Use External Git Client**, og installér Git for Windows, hvis den indbyggede klient fortsat fejler #### Manglende opstrømssporing **Fejl:** "There is no tracking information for the current branch" **Årsag:** Den lokale Git-gren er ikke konfigureret til at spore en fjern-gren. **Løsning:** Åbn PowerShell i lagerkataloget, og kør: {% code collapsedlinecount="10" %} ```powershell git fetch git branch --set-upstream-to=origin/main main git pull ``` {% endcode %} Erstat `main` med Deres faktiske grennavn. Klik derefter på **Synchronize Now** i PSU. #### Git Sync stopper efter ændring af indstillinger i brugergrænsefladen **Symptomer:** Når Git-indstillinger (fjern-URL, legitimationsoplysninger, synkroniseringsinterval osv.) er redigeret i PSU-brugergrænsefladen, og der klikkes på OK, holder synkroniseringen op med at fungere, selvom indstillingerne ser korrekte ud. **Årsag:** I PSU 5.x gemmes Git-legitimationsoplysninger i SQL-databasen. Enhver ændring af Git-indstillinger via brugergrænsefladen kan rydde de gemte legitimationsoplysninger, selv om adgangskodefeltet stadig ser udfyldt ud i formularen. **Løsning:** 1. Indtast det personlige adgangstoken igen i **Source Control > Git > Settings** 2. Klik på **OK** for at gemme 3. I miljøer med flere noder skal De **gentage denne proces på hver node**—legitimationsoplysninger skal angives individuelt på hver server 4. Klik på **Synchronize Now** for at bekræfte, at synkroniseringen fungerer igen Systemet overfører ikke automatisk legitimationsoplysninger på tværs af noder i en konfiguration med belastningsfordeling eller høj tilgængelighed. #### Agent- og netværksproblemer **Symptomer:** Synkronisering fungerer på én node, men mislykkes på andre, eller De ser fejlene `RpcException` eller "service is unavailable" i loggene. **Almindelige årsager:** * **Versionskonflikt:** Sørg for, at alle PSU-servere og -agenter kører den samme version * **Firewallregler:** Agenter kommunikerer med PSU-serveren via gRPC på portene **5000** (HTTP) eller **5001** (HTTPS) * **Proxy- eller WebSocket-blokering:** Virksomhedsproxyer kan blokere eller inspicere gRPC-trafik; konfigurer git til at bruge proxyen, eller aktivér External Git Client **Løsning:** 1. Kontrollér, at alle noder kører den samme PSU-version 2. Kontrollér, at firewallreglerne tillader trafik på portene 5000/5001 3. Test gRPC-forbindelse mellem noder 4. Hvis De bruger en proxy, skal De konfigurere miljøvariablerne `http_proxy` og `https_proxy` for PSU-tjenestekontoen #### Docker og containeriserede udrulninger * Sørg for, at containerimaget indeholder `git` (kør `git --version` for at verificere) * Kontrollér udgående netværksadgang til git-fjernlageret * Montér persistente volumener for `/data` eller `%ProgramData%\UniversalAutomation` for at bevare git-tilstanden på tværs af genstarter * Hvis synkroniseringen mislykkes lydløst, skal De kontrollere containerloggene for git- eller netværksfejl #### Redigering af .git/config uden Git CLI Hvis kommandolinjeværktøjet Git ikke er installeret på serveren, og De støder på fejl med upstream-sporing, kan De redigere lagerkonfigurationen direkte via PSU's filbrowser: 1. Naviger til **Platform → Configuration → Repository → .git → config** 2. Tilføj følgende linjer (juster grennavnet, så det matcher Deres lager): {% code collapsedlinecount="10" %} ```ini [branch "main"] remote = origin merge = refs/heads/main ``` {% endcode %} 3. Klik på **Save** 4. Vend tilbage til **Source Control > Git > Settings**, og klik på **Synchronize Now** Denne fremgangsmåde giver Dem mulighed for at konfigurere upstream-sporing uden at skulle bruge `git`-kommandoer, hvilket er særligt nyttigt, når Git for Windows ikke er installeret, eller når der køres under begrænsede tjenestekonti. #### Git-indstillinger bevares ikke Hvis ændringer af Git-indstillinger ikke gemmes, eller hvis de tilbageføres umiddelbart efter klik på OK: **Kontrollér filsystemtilladelser:** * Stop PowerShell Universal-tjenesten * Prøv at redigere `%ProgramData%\PowerShellUniversal\appsettings.json` manuelt (eller `%ProgramData%\UniversalAutomation\appsettings.json` i ældre versioner) * Tilføj en kommentarlinje, gem, og genåbn filen for at kontrollere, at Deres ændringer bevares * Hvis ændringer rulles tilbage, skal De kontrollere, om antivirussoftware, gruppepolitikobjekter (GPO) eller NTFS-tilladelser blokerer skrivning til PSU-datakataloget **Aktivér fejlfindingslogning til fejlfinding:** 1. Stop PowerShell Universal-tjenesten 2. Rediger `appsettings.json`, og angiv: {% code collapsedlinecount="10" %} ```json "SystemLogLevel": "Debug" ``` {% endcode %} 3. Gem og genstart tjenesten 4. Forsøg at gemme Git-indstillinger igen 5. Gennemgå `%PROGRAMDATA%\PowerShellUniversal\systemLog.txt` for fejl relateret til konfigurationsskrivninger **Udfyld Git-indstillinger manuelt:** Når tjenesten er stoppet, kan De udfylde Git-felter direkte i `appsettings.json`: {% code collapsedlinecount="10" %} ```json "GitRemote": "https://dev.azure.com/org/project/_git/repo", "GitUserName": "any", "GitPassword": "your-PAT-here", "GitBranch": "main" ``` {% endcode %} Genstart tjenesten, og kontrollér, at indstillingerne vises i **Source Control > Git > Settings**. Hvis de forsvinder igen, angiver fejlfindingsloggene, om et tilladelsesproblem, software til slutpunktsbeskyttelse eller en valideringsfejl i konfigurationen forårsager nulstillingen. ### unknown certificate lookup failure: 16777280 Når De bruger det integrerede git-bibliotek, kan De støde på problemer med certifikatet, når De opretter forbindelse til lokalt hostede git-lagre. I denne konfiguration anbefaler vi at bruge den eksterne git-klient for at give mere support til konfiguration af certifikatopslagsprocessen. ## Medtagne filer De filer, der medtages i en git-synkronisering, er alle filer i det lokale lager. Dette omfatter PS1-konfigurationsfiler, XML-filer til sider og alle andre filer, som De eventuelt tilføjer manuelt. Følgende er ikke inkluderet: * appsettings.json * database.db * web.config * Binære filer til PowerShell Universal-programmet ## Flere Git-lagre PowerShell Universal understøtter lagring af flere git-lagerkonfigurationer i databasen. På den måde kan De hurtigt skifte mellem forskellige konfigurationer af PowerShell Universal. Klik på fanen Repositories for at se de aktuelt konfigurerede lagre. Herfra kan De slette og redigere lagerkonfigurationer. {% hint style="warning" %} PowerShell Universal fjerner ikke mappen .git, når en lagerkonfiguration slettes. De skal gøre dette manuelt for at konfigurere et nyt lager. {% endhint %} Når De tilføjer en ny lagerkonfiguration, kan De klikke på knappen Apply for at skifte til det valgte lager. Dette sletter alle filer i lagerkataloget og kloner det valgte lager. De kan ikke anvende en lagerkonfiguration, hvis der er ændringer, der ikke er committet, i Deres lager. Når lageret er klonet, genindlæser PowerShell Universal sin konfiguration fuldstændigt. ## Git-historik og statusside Historikfanen viser hele git-commit-historikken for det aktuelle lager. Synkroniseringsstatusfanen viser den aktuelle status for noder i PSU-klyngen. ### Test af Git-synkronisering Den bedste måde at sikre, at Deres git-synkronisering fungerer korrekt, er at klikke på knappen Synchronize Now. Dette tvinger en synkronisering til at køre, og De kan kontrollere, om de angivne indstillinger virkede korrekt. ### Visning af ændringer De kan se ændringer i tabellen over git-synkroniseringer. Hver synkronisering indeholder antallet af ændringer, der er fundet siden den seneste synkronisering, SHA for committen og en liste over ændringer mellem denne SHA og den forrige. Når filer er i ændret tilstand, kan De se diffene ved hjælp af fildiff-værktøjet. ### Håndtering af konflikter {% hint style="info" %} Konfliktløsning er kun tilgængelig i tilstanden for manuel git-synkronisering. {% endhint %} Når flere brugere redigerer PowerShell Universal-konfigurationsfilerne, kan der opstå konflikter. PowerShell Universal viser, at en bestemt node er i en konflikttilstand, når der forsøges at committe ændringer. De får vist en liste over ændringer, der er i konflikt, på git-commit-siden. Klik på knappen Resolve Conflict for at se konflikten i en editor. I dette eksempel blev strengen for dette slutpunkt redigeret i både fjernlageret og det lokale lager: * Aktuel (lokal) version — mellem `<<<<<<< HEAD` og `=======`: `"That endpoint"` * Indgående (fjern) version — mellem `=======` og `>>>>>>> main`: `"This endpoint"` Rediger teksten for at fjerne konflikten. Gem ændringerne, og gå tilbage til git commit-siden. Angiv en ny commit-meddelelse for mergekonflikten, og klik på Commit Changes. Dette vil løse mergekonflikten og pushe til fjernlageret. ## Git-synkroniseringsadfærd ### Two-Way Som standard fungerer git-synkronisering begge veje. Hvis De foretager ændringer i PSU-admin console, bliver disse ændringer committet og synkroniseret til det konfigurerede fjernlager. Alle ændringer, der foretages i fjernlageret, vil blive hentet lokalt. Hvis De opsætter git-synkronisering med et allerede eksisterende git-fjernlager, hentes ændringerne og synkroniseres lokalt. De kan ikke have nogen ændringer lokalt. Hvis De opsætter git-synkronisering med et bart lager, synkroniseres de lokale ændringer, og lageret initialiseres. ### One-Way De kan justere funktionsmåden for git-synkroniseringen ved at ændre indstillingen `GitSyncBehavior` i `appsettings.json`. Når den er angivet til `OneWay`, bliver admin console og management-API'et skrivebeskyttede. PowerShell Universal-systemet henter fra fjernlageret, men foretager aldrig push eller commit lokalt. {% 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-Only Git-synkroniseringstilstanden Push-only henter ikke ændringer fra fjernlageret. Alle ændringer, der foretages lokalt, skubbes op til fjernlageret. Konsollen vil ikke være skrivebeskyttet. Denne konfiguration er nyttig i scenarier, hvor De har én maskine, der bruges til konfigurationen, som er én sandhedskilde for en pulje af servere, der er skrivebeskyttede. {% 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 %} ## Personligt adgangstoken Vi anbefaler, at De bruger et personligt adgangstoken (PAT) frem for et brugernavn og en adgangskode. De kan konfigurere et personligt adgangstoken ved at angive adgangskodeegenskaben i `appsettings.json` eller med andre konfigurationsmetoder. {% 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 %} ### GitHubs finkornede tokens I GitHub kan De hente et finkornet token ved at klikke på Deres avatar øverst til højre, vælge Settings, Developers Settings, Personal Access Tokens og derefter Fine-Grained Tokens. #### Token-omfang Når De genererer tokenet, skal De sørge for at give lageret `Read-Write` til tilladelsen `Content`. Dette vil automatisk tilføje Read til tilladelsen `Metadata`. De kan give adgang til netop det lager, De vil klone. ### GitHub-tokens (Classic) I GitHub kan De hente et personligt adgangstoken ved at klikke på Deres avatar øverst til højre, vælge Settings, Developer Settings, Personal Access Tokens og derefter Tokens (Classic). Når De genererer Deres adgangstoken, skal De sikre, at De vælger Repo-tilladelserne. Bemærk, at hvis De bruger BitBucket, skal De angive brugernavnet ud over PAT'en i `appsettings.json`. ## Brugernavn og adgangskode De kan også konfigurere et git-fjernlager til at godkende med et brugernavn og en adgangskode. Angiv brugernavnet og adgangskoden enten med filen `appsettings.json` eller en anden konfigurationsmetode. {% 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 %} ## Almindelige fejl #### Git-synkronisering mislykkedes. unknown certificate lookup failure: 16777280 Biblioteket lib2gitsharp kunne ikke validere certifikatet for det eksterne git-lager. De skal bruge den [eksterne git-klient](#external-git-client) og en brugerdefineret git-konfiguration for at løse dette. Nogle almindelige muligheder for git-HTTPS-understøttelse omfatter: {% 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" eller godkendelsesgentagelser Git-fjernlageret har afvist Deres legitimationsoplysninger til adgang til lageret. Deres personlige adgangstoken kan være udløbet eller ikke have adgang til fjernlageret. #### repository not owned by current user Det lokale git-lager har ikke de rette adgangskontroller for den bruger, der forsøger at få adgang til det. Dette kan ske, hvis PowerShell Universal har klonet lageret, og der derefter er angivet en anden tjenestekonto på tjenesten. Fordi adgangskontrollerne ikke stemmer overens, får git ikke adgang til mappen som følge heraf. Dette er en sikkerhedsfunktion i git. De kan opdatere ejeren af mappen for at undgå dette eller konfigurere git til at have tillid til mappen. Angiv følgende værdi i den globale git-konfiguration. {% code collapsedlinecount="10" %} ``` [safe] directory = C:\ProgramData\UniversalAutomation\Repository ``` {% endcode %} Den globale konfiguration findes i: `C:\Program Files\git\etc\gitconfig` ## Fordele ved Git-synkronisering i forhold til manuel Git-synkronisering Det er muligt at synkronisere et lager manuelt med git. PowerShell Universal bruger meget grundlæggende kommandoer i forbindelse med git. Alle ændringer af PowerShell Universal via admin console eller API'en udfører en `git commit`, og forfatteren angives som identiteten for den bruger, der foretager ændringen. Under en git-synkronisering udfører vi først en `git pull` for at sikre, at vi har den seneste version af filerne på fjernlageret. Dernæst udfører vi en `git push` for at sende de lokale commits op, som er sket siden den seneste synkronisering. De kunne opnå denne funktionalitet med et planlagt job. Når det er sagt, er det en funktion ved git-synkroniseringen, at den analyserer committet for at sikre, at kun filer, der blev ændret under synkroniseringen, genindlæses. Det forhindrer dashboards i at blive udrullet automatisk, når de ikke er ændret, eller API-tjenester i at genstarte, når miljøer ikke er blevet opdateret. Så der er en ydeevnegevinst her. Det andet problem er, at konfigurationerne på grund af den måde, PowerShell Universal overvåger filer på (med en `FileSystemWatcher`), og den måde, git opdaterer filer på, ikke genindlæses automatisk efter et pull. De skal sikre, at De gennemtvinger, at konfigurationerne evalueres igen. ## Forgreningsstrategier Forgreningsstrategier i git bestemmer, hvordan ændringer flyttes fra én gren til en anden. Brug af forskellige typer forgreningsstrategier i PowerShell Universal kan sikre, at teams af forskellig størrelse kan arbejde effektivt sammen på platformen. ### Enkeltbrugere og små teams For enkeltbrugere og små teams er det muligvis ikke nødvendigt at have mere end én gren. Grenen bruges til historiksporing og giver mulighed for at rulle ændringer tilbage. Brugere får adgang til PowerShell Universal direkte for at foretage ændringer eller committe ændringer til den enkelte gren fra lokale kloner af lagerkataloget ved hjælp af et værktøj som VS Code. * main - Enkelt gren, der accepterer alle ændringer direkte ### Enkeltbrugere og små teams med en staging-gren Selv enkelte brugere og små teams kan finde det fordelagtigt at anvende en staging- eller dev-branch. Denne branch modtager ændringer under udviklingen. En enkeltstående instans af PowerShell Universal konfigureres til at køre mod denne dev-branch, så brugerne kan validere ændringer, før de pusher til produktion. Når De bruger en konfiguration med staging-gren, er PowerShell Universal-miljøerne helt adskilte. Miljøerne bruger en anden database og en anden planlægger. Data såsom identiteter, app-tokens og jobhistorik deles ikke på tværs af miljøerne. {% hint style="info" %} Hver instans af PowerShell Universal kræver en [licens](/powershell-universal/da/licensing.md). I denne konfiguration ville der kræves to licenser. {% endhint %} En separat PowerShell Universal-instans kan derefter konfigureres til at pege på en main- eller produktionsbranch, der modtager opdateringer via fletninger eller pullanmodninger i et system som GitHub. I denne konfiguration er det muligt at bruge envejs-git-synkronisering til at hente ændringer fra main, men aldrig pushe fra platformen. Dette forhindrer også de fleste flettekonflikter, da de håndteres i dev-branchen eller via fletteværktøjet i kildelageret. * main - Produktionsgren, der modtager ændringer fra pull requests fra dev-grenen * dev - Staging-grenen, der bruges til at acceptere commits og validere ændringer, før der pushes til master. ### Mellemstore til store teams Når der er tale om teams med mere end et par udviklere, kan en mere kompleks forgreningsstrategi være nyttig til bedre at vurdere kodeændringer og undgå fletningskonflikter. PowerShell Universal indeholder grundlæggende fletningsværktøjer, men der findes bedre værktøjer til dette formål, f.eks. GitHub-pullanmodning, GitLab-fletningsanmodninger og lokale værktøjer som GitKraken. I mellemstore teams kan det være ønskeligt at have yderligere funktionsbranches, der isolerer specifikke ændringer på en bestemt branch. En udvikler kan for eksempel være i gang med at oprette et nyt sæt API'er til at administrere Azure i PowerShell Universal. For at undgå brydende ændringer i dev-branchen opretter udviklerne deres egen funktionsbranch, der indeholder alle deres ændringer, indtil den er tilstrækkeligt færdig til at blive flettet ind i udviklingsbranchen. {% hint style="info" %} PowerShell Universal tilbyder [udviklerlicenser](/powershell-universal/da/licensing.md), så De undgår at skulle købe en licens til hver udvikler på Deres team. Licenser vil stadig være påkrævet til produktionsmiljøerne og de midlertidige miljøer. {% endhint %} I denne type konfiguration er lokal udvikling ideel, fordi udviklerne vil arbejde på deres lokale PowerShell Universal-instans i deres funktionsgren. Når funktionen er færdig, opretter de en Pull- eller Merge-anmodning i kildelageret for at flytte ændringerne til dev-grenen. Testen fuldføres på dev-grenen, før der flettes til produktion. I lighed med en main\dev-forgreningsstrategi vil alle PowerShell Universal-instanser være isolerede og vil ikke dele en database eller en planlægger. Når et sæt funktioner er klar til produktion, oprettes en Pull- eller Merge-anmodning fra dev til main-grenen. * main - Produktionsgren, der kun vil modtage ændringer fra dev * dev - Staging-branch, der modtager ændringer fra funktionsbranches, men ikke ændres direkte * feature - Featuregren, der committes direkte til af udviklere og flettes til dev, når den er klar Afhængigt af kompleksiteten af Deres miljø kan det anbefales at bruge udrulninger frem for git i produktion. Se afsnittet Store teams nedenfor for at få flere oplysninger. ### Store teams I store teams anbefaler vi at bruge git til udviklingsformål, men at bruge udrulninger, eller et lignende koncept, til produktion. [Udrulninger ](/powershell-universal/da/config/deployments.md)giver uforanderlige konfigurationspakker, der er blevet grundigt testet i miljøer på lavere niveau. Ved at bruge udrulninger kan De vælge, hvordan De udvikler og administrerer Deres kode, og blot publicere resultatet til Deres udviklings-, staging-, QA- og produktionsmiljøer. Dette sikrer, at al kode er grundigt testet, før den udrulles til Deres kritiske systemer. De kan bruge automatiserede arbejdsflows, f.eks. GitHub Actions, til at publicere Deres udrulninger uden at skulle opdatere noget system manuelt. ## Git-hosting PowerShell Universal understøtter enhver standardløsning til git-hosting. Vores kunder bruger ofte følgende: * GitHub * GitHub Enterprise * GitLab * Bitbucket * Azure DevOps Selvom disse er de mest almindelige platforme, understøtter vi enhver platform, der bruger git-protokollen. ### Eksempel: Gitea De kan også bruge enkle, selvhostede løsninger som [Gitea](https://gitea.com). Her er et eksempel på, hvordan De nemt konfigurerer en Gitea-dockercontainer til brug med 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 by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.devolutions.net/powershell-universal/da/config/git.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. 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.