> 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/es/config/git.md). # Git {% hint style="info" %} La integración con Git requiere una [licencia](https://store.devolutions.net/package#psu). {% endhint %} PowerShell Universal es capaz de sincronizar los scripts de configuración con un repositorio git remoto. ## Configuración ### Consola de administración La sincronización con git se puede configurar en la base de datos ajustando la configuración dentro de la consola de administración. Este es el enfoque preferido. La ventaja es que, cuando conecte nuevas instancias de PowerShell Universal a su instancia de SQL, no necesitará configurar de nuevo la sincronización con git. Para configurar la sincronización con git, navegue a Configuración \ Git dentro de la consola de administración. Podrá hacer clic en el botón Create Git Settings.

Diálogo de configuración de Git

{% hint style="info" %} En PowerShell Universal 5.x y posteriores, las credenciales de Git (URL remota, nombre de usuario y token de acceso personal) se almacenan en la base de datos SQL en lugar de en appsettings.json. Editar estos ajustes en la interfaz de usuario actualizará la base de datos. Si edita la configuración de Git y después hace clic en OK, PSU puede borrar las credenciales almacenadas incluso si los campos aparecen rellenados. En entornos de varios nodos, debe volver a introducir las credenciales en cada nodo individualmente después de realizar cambios. {% endhint %} ### appsettings.json También puede usar la [configuración](/powershell-universal/es/config/settings.md) para establecer la sincronización con git. Esto resulta útil si tiene una única instancia de PSU y desea hacer una copia de seguridad de su fichero appsettings.json. Ajustar la configuración dentro de la consola de administración no actualizará el fichero appsettings.json. Deberá hacerlo manualmente y reiniciar PowerShell Universal después de cambiar la configuración. Si la configuración de sincronización con git se especifica en la base de datos, se ignoran los ajustes definidos en appsettings.json. ## Configuración de sincronización con Git ### Rama De forma predeterminada, PowerShell Universal se sincronizará con la rama `master`. Si desea usar una rama diferente, especifique el ajuste `GitBranch` dentro de su `appsettings.json`. #### Corregir el seguimiento upstream ausente Si encuentra el error **"There is no tracking information for the current branch"**, la rama local no está vinculada a la remota. Para corregirlo: 1. Abra PowerShell en `%ProgramData%\UniversalAutomation\Repository` (o la ruta del repositorio configurada) 2. Ejecute: ```powershell git fetch git branch --set-upstream-to=origin/main main git pull ``` ### Remoto Los remotos no son obligatorios. Si no se especifica un remoto, el repositorio git se almacena localmente en el directorio Repository. Si se especifica, PowerShell Universal se sincronizará con el remoto. Se requieren credenciales adecuadas para acceder a ese remoto. #### Formato de URL de Azure DevOps Los repositorios de Azure DevOps deberían usar el formato de URL moderno `dev.azure.com` en lugar del dominio heredado `visualstudio.com`: **Formato correcto:** ``` https://dev.azure.com///_git/ ``` **Ejemplos:** ``` https://dev.azure.com/mycompany/MyProject/_git/PowerShellUniversal https://dev.azure.com/mycompany/MyProject/_git/PSU%20Scripts ``` Si el nombre de su repositorio contiene espacios, deben codificarse como `%20` en la URL. Evite usar URL con el dominio antiguo `visualstudio.com`, ya que pueden provocar bucles de redirección o fallos de autenticación con el error "too many redirects or authentication replays". Para Azure DevOps, su token de acceso personal debe tener el ámbito **Code (Read & Write)**. Los tokens de granularidad fina funcionan, pero se recomiendan los PAT clásicos por compatibilidad entre versiones de PSU. **Nota para usuarios de GitLab:** si su instancia de GitLab requiere autenticación basada en encabezados, puede que necesite usar la opción de cliente Git externo y configurar los ayudantes de credenciales de Git, ya que el cliente Git integrado de PSU usa autenticación HTTP Basic con el PAT como contraseña. Algunas configuraciones de GitLab esperan en su lugar un encabezado `Private-Token`. ### Autenticación Necesitará configurar la autenticación con su repositorio git remoto. Recomendamos un token de acceso personal. ### Cliente Git externo Puede optar por usar un cliente git externo en lugar de la biblioteca integrada en PowerShell Universal. Esto le permite opciones de configuración adicionales, como el uso de autenticación SSH. PowerShell Universal no usará el nombre de usuario, las contraseñas ni los PAT configurados al habilitar este método. Necesitará tener instalado un cliente git. #### Uso de claves SSH Puede usar PowerShell Universal para generar y gestionar claves SSH. Dentro de la consola de administración, haga clic en Platform \ SSH Keys. Genere una nueva clave SSH. A continuación, haga clic en el botón de copiar junto a la clave SSH para obtener la clave pública. Registre la clave pública con el repositorio o la cuenta de destino. Por ejemplo, puede seguir la [guía de GitHub](https://docs.github.com/en/authentication/connecting-to-github-with-ssh) aquí. Dentro de la ventana de configuración de Git, seleccione la clave SSH que desea usar con la sincronización con git. Cuando use claves SSH, asegúrese de que se selecciona la URL SSH para clonar su repositorio. ``` git@github.com:ironmansoftware/psu-devo ```

URL SSH de GitHub

#### Establecer credenciales Cuando use el cliente git externo, usted es responsable de configurar las credenciales antes de realizar una sincronización. Puede configurar las credenciales mediante la configuración de git o la URL pasada a PowerShell Universal. El siguiente comando almacenará las credenciales en texto plano en el servidor de PowerShell Universal. Deberá ejecutar este comando como el usuario de la cuenta de servicio para que tenga acceso a las credenciales. Esto creará un fichero `.git-credentials` que se usará al autenticarse contra la URL de destino. Puede que necesite cambiar la URL en función de su remoto git. ```batch git config --global credential.helper store echo "https://${username}:${password_or_access_token}@github.com" > ~/.git-credentials ``` También puede almacenar las credenciales directamente en la URL proporcionada a PowerShell Universal. ``` https://adam:APP_TOKEN@github.com/myOrg/myRepo.git ``` #### Ejemplo: nombre de usuario y PAT Para usar un cliente git externo y pasar un nombre de usuario y un PAT con los que autenticarse, puede especificarlos en la URL del remoto git. Por ejemplo: ``` https://username:PAT@github.com/ironmansoftware/universal ``` #### Ejemplo: SSH y GitHub En primer lugar, necesitará configurar su ssh-agent local y su cuenta de GitHub con claves SSH. Puede seguir su [guía aquí](https://docs.github.com/en/authentication/connecting-to-github-with-ssh). A continuación, proporcionará un URI SSH para la URL del remoto git en PowerShell Universal. La clave SSH configurada se usará para la conexión. ``` git@github.com:ironmansoftware/universal.git ``` #### Problema con el certificado SSL {% hint style="warning" %} SSL Certificate problem: unable to get local issuer certificate {% endhint %} Si está ejecutando en Windows y recibe un problema con el certificado SSL, puede que necesite asegurarse de que ha [habilitado el soporte de schannel](https://stackoverflow.com/questions/23885449/unable-to-resolve-unable-to-get-local-issuer-certificate-using-git-on-windows). #### Persistencia de credenciales {% hint style="warning" %} Unable to persist credentials with the 'wincredman' credential store. {% endhint %} Si está en Windows y recibe un error acerca de la persistencia de credenciales en wincredman, puede que necesite establecer la persistencia de credenciales en DAPI. Puede [aprender cómo hacerlo aquí](https://github.com/GitCredentialManager/git-credential-manager/issues/633). ### Modo manual El modo manual requiere que los usuarios que editen la instancia de PowerShell Universal hagan clic en Edit para realizar cambios en el sistema.
Una vez completados los cambios, el usuario puede hacer clic en Save Changes para iniciar un commit
En la página de commit de git, puede ver los ficheros modificados e introducir un mensaje de commit.
Una vez que se han confirmado los cambios, se enviarán al remoto y el servicio comenzará a sincronizarse de nuevo con git. También existe la posibilidad de que se produzca un conflicto de fusión de git en ese momento. Consulte [Tratar los conflictos](#dealing-with-conflicts) para obtener más información. El modo manual se puede establecer en la configuración de git dentro de la consola de administración o dentro de `appsettings.json`. ```json "Data": { "RepositoryPath": "%ProgramData%\\UniversalAutomation\\Repository", "ConnectionString": "filename=%ProgramData%\\UniversalAutomation\\database.db;upgrade=true", "RunMigrations": true, "GitRemote": "", "GitUserName": "", "GitPassword": "", "GitBranch": "", "GitSyncBehavior": "TwoWay", "GitInitializeBehavior": "", "GitSyncInterval": "1", "ConfigurationScript": "", "ExternalGitClient": false "Mode": "Manual" // Or Automatic }, ``` ### Método uno: enviar ficheros locales al remoto {% hint style="info" %} La ubicación predeterminada del repositorio local es `C:\ProgramData\UniversalAutomation\Repository` {% endhint %} Debe asegurarse de que su carpeta local no sea un repositorio git preexistente. Su directorio de repositorio debería ser simplemente una carpeta con sus ficheros de PowerShell Universal. Si existe una carpeta `.git` y no desea usar ese repositorio, debería eliminarla y PowerShell Universal creará un nuevo repositorio. Si está poblando un nuevo repositorio git, debe asegurarse de que el remoto no tenga ningún fichero en él. Debería ser un repositorio completamente vacío. Por ejemplo, al crear un repositorio en GitHub, no seleccione la creación de una licencia ni de un fichero readme.md. ![](/files/QPS8RamDtsbL9eIpm89q) Una vez creado el repositorio, puede obtener la URL del remoto git y proporcionarla al fichero `appsettings.json` de PowerShell Universal. ![](/files/4PhWLxQh6G8evhDlD1ty) Una vez que tenga la rama, la URL del remoto git y las credenciales, puede proporcionarlas a su fichero `appsettings.json` y el remoto git se poblará con sus ficheros locales. ### Método dos: extraer desde un remoto Git {% hint style="info" %} La ubicación predeterminada del repositorio local es `C:\ProgramData\UniversalAutomation\Repository` {% endhint %} Puede configurar PowerShell Universal para extraer desde un remoto git. En esta configuración, debe asegurarse de que su carpeta de repositorio local esté completamente vacía. Cualquier fichero dentro de la carpeta hará que la sincronización con git falle y le impedirá recuperarse. Configure el fichero `appsettings.json` para incluir la rama, las credenciales y la URL del remoto git que está clonando. Una vez establecidos los campos, puede iniciar el servicio de PowerShell Universal. Lo primero que hará el servicio será clonar el repositorio y configurarlo localmente. ### Tiempo de espera de la sincronización con Git La sincronización con git superará el tiempo de espera si no puede contactar con el remoto después de 60 minutos. Esto permite disponer de tiempo para descargar repositorios grandes o para retrasos en redes lentas. Puede ver que el servicio de PowerShell Universal se queda bloqueado en "Synchronizing with git" durante el inicio mientras el servidor espera a que esto ocurra. Si desea reducir este tiempo, puede usar el siguiente ajuste de appsetting.json. El valor está en minutos. ```json "Data" : { "GitSyncTimeout": 30 } ``` ### Intervalo de sincronización **Tipo:** Entero\ **Predeterminado:** 60\ **appsettings.json:** `GitSyncInterval` El intervalo, en segundos, entre los intentos automáticos de sincronización con Git cuando la sincronización automática está habilitada. El valor predeterminado es de 60 segundos (1 minuto). Para ajustar la frecuencia de sincronización, edite `appsettings.json`: ```json "GitSyncInterval": 300 ``` Esto cambiaría el intervalo de sincronización a 5 minutos. Los valores más bajos aumentan la frecuencia de sincronización, pero pueden afectar al rendimiento en repositorios grandes o redes lentas. No se recomienda establecer este valor demasiado bajo (por debajo de 30 segundos) en entornos de producción. ### Solución de problemas #### Azure DevOps: "Too many redirects or authentication replays" Este error normalmente indica uno de los siguientes problemas: * **Formato de URL heredado:** asegúrese de que está usando `https://dev.azure.com///_git/` en lugar del dominio antiguo `visualstudio.com` * **Ámbito de PAT no válido:** su token de acceso personal debe tener permisos **Code (Read & Write)** en Azure DevOps * **Credenciales caducadas:** genere un nuevo PAT y vuelva a introducirlo en la configuración de Git de PSU * **Espacios codificados:** si el nombre de su repositorio tiene espacios, asegúrese de que están codificados como `%20` en la URL **Resolución:** 1. Actualice la URL remota para usar `dev.azure.com` 2. Genere un nuevo PAT con el ámbito Code (Read & Write) 3. Habilite **Use External Git Client** e instale Git para Windows si el cliente integrado continúa fallando #### Seguimiento upstream ausente **Error:** "There is no tracking information for the current branch" **Causa:** la rama local de Git no está configurada para seguir una rama remota. **Resolución:** abra PowerShell en el directorio del repositorio y ejecute: ```powershell git fetch git branch --set-upstream-to=origin/main main git pull ``` Sustituya `main` por el nombre real de su rama. Después, haga clic en **Synchronize Now** en PSU. #### La sincronización con Git se detiene tras cambiar la configuración en la interfaz de usuario **Síntomas:** después de editar la configuración de Git (URL remota, credenciales, intervalo de sincronización, etc.) en la interfaz de usuario de PSU y hacer clic en OK, la sincronización deja de funcionar aunque la configuración parezca correcta. **Causa:** en PSU 5.x, las credenciales de Git se almacenan en la base de datos SQL. Realizar cualquier cambio en la configuración de Git a través de la interfaz de usuario puede borrar las credenciales almacenadas, incluso si el campo de contraseña sigue apareciendo rellenado en el formulario. **Resolución:** 1. Vuelva a introducir el token de acceso personal en **Configuración → Git** 2. Haga clic en **OK** para guardar 3. En entornos de varios nodos, **repita este proceso en cada nodo**: las credenciales deben introducirse individualmente en cada servidor 4. Haga clic en **Synchronize Now** para verificar que la sincronización vuelve a funcionar El sistema no propaga automáticamente las credenciales entre nodos en una configuración con balanceo de carga o de alta disponibilidad. #### Problemas de agente y de red **Síntomas:** la sincronización funciona en un nodo pero falla en otros, o ve errores `RpcException` o "service is unavailable" en los registros. **Causas comunes:** * **Discrepancia de versiones:** asegúrese de que todos los servidores y agentes de PSU ejecutan la misma versión * **Reglas de cortafuegos:** los agentes se comunican con el servidor de PSU mediante gRPC en los puertos **5000** (HTTP) o **5001** (HTTPS) * **Bloqueo de proxy o WebSocket:** los proxies corporativos pueden bloquear o inspeccionar el tráfico gRPC; configure git para usar el proxy o habilite el cliente Git externo **Resolución:** 1. Verifique que todos los nodos ejecutan la misma versión de PSU 2. Compruebe que las reglas de cortafuegos permiten el tráfico en los puertos 5000/5001 3. Pruebe la conectividad gRPC entre nodos 4. Si usa un proxy, configure las variables de entorno `http_proxy` y `https_proxy` para la cuenta de servicio de PSU #### Despliegues en Docker y en contenedores * Asegúrese de que la imagen del contenedor incluye `git` (ejecute `git --version` para verificarlo) * Verifique el acceso de red saliente al remoto git * Monte volúmenes persistentes para `/data` o `%ProgramData%\UniversalAutomation` para preservar el estado de git entre reinicios * Si la sincronización falla silenciosamente, revise los registros del contenedor para detectar errores de git o de red #### Edición de .git/config sin la CLI de Git Si la herramienta de línea de comandos de Git no está instalada en el servidor y encuentra errores de seguimiento de la rama upstream, puede editar la configuración del repositorio directamente a través del explorador de ficheros de PSU: 1. Vaya a **Platform → Configuration → Repository → .git → config** 2. Añada las siguientes líneas (ajuste el nombre de la rama para que coincida con su repositorio): ```ini [branch "main"] remote = origin merge = refs/heads/main ``` 3. Haga clic en **Save** 4. Vuelva a **Settings → Git** y haga clic en **Synchronize Now** Este enfoque le permite configurar el seguimiento de la rama upstream sin necesidad de comandos `git`, lo cual resulta especialmente útil cuando Git para Windows no está instalado o cuando se ejecuta con cuentas de servicio restringidas. #### La configuración de Git no se conserva Si los cambios en la configuración de Git no se guardan o se revierten inmediatamente después de hacer clic en OK: **Compruebe los permisos del sistema de ficheros:** * Detenga el servicio de PowerShell Universal * Intente editar manualmente `%ProgramData%\PowerShellUniversal\appsettings.json` (o `%ProgramData%\UniversalAutomation\appsettings.json` en versiones anteriores) * Añada una línea de comentario, guarde y vuelva a abrir el fichero para verificar que sus cambios se conservan * Si los cambios se revierten, compruebe si algún software antivirus, objetos de directiva de grupo (GPO) o permisos NTFS están bloqueando la escritura en el directorio de datos de PSU **Habilite el registro de depuración para la resolución de problemas:** 1. Detenga el servicio de PowerShell Universal 2. Edite `appsettings.json` y establezca: ```json "SystemLogLevel": "Debug" ``` 3. Guarde y reinicie el servicio 4. Intente guardar de nuevo la configuración de Git 5. Revise `%PROGRAMDATA%\PowerShellUniversal\systemLog.txt` para buscar errores relacionados con las escrituras de configuración **Rellene manualmente la configuración de Git:** Con el servicio detenido, puede rellenar directamente los campos de Git en `appsettings.json`: ```json "GitRemote": "https://dev.azure.com/org/project/_git/repo", "GitUserName": "any", "GitPassword": "your-PAT-here", "GitBranch": "main" ``` Reinicie el servicio y compruebe que la configuración aparece en **Settings → Git**. Si vuelve a desaparecer, los registros de depuración indicarán si un problema de permisos, un software de protección de puntos finales o un error de validación de la configuración está causando el restablecimiento. ### unknown certificate lookup failure: 16777280 Al utilizar la biblioteca git integrada, puede encontrar problemas con el certificado al conectarse a repositorios git alojados localmente. En esta configuración, recomendamos utilizar el cliente git externo para disponer de mayor compatibilidad con la configuración del proceso de búsqueda del certificado. ## Ficheros incluidos Los ficheros que se incluyen en una sincronización de git son todos los ficheros del repositorio local. Esto incluye los ficheros de configuración PS1, los ficheros XML de páginas y cualquier otro fichero que pueda añadir manualmente. No se incluyen los siguientes: * appsettings.json * database.db * web.config * Binarios de la aplicación PowerShell Universal ## Múltiples repositorios Git PowerShell Universal admite el almacenamiento de múltiples configuraciones de repositorios git en la base de datos. De este modo, puede cambiar rápidamente entre distintas configuraciones de PowerShell Universal. Haga clic en la pestaña Repositories para ver los repositorios configurados actualmente. Desde aquí puede eliminar y editar las configuraciones de los repositorios. {% hint style="warning" %} PowerShell Universal no elimina la carpeta .git al eliminar una configuración de repositorio. Deberá hacerlo manualmente para poder configurar un nuevo repositorio. {% endhint %} Cuando añade una nueva configuración de repositorio, puede hacer clic en el botón Apply para cambiar al repositorio seleccionado. Esto eliminará todos los ficheros del directorio del repositorio y clonará el repositorio seleccionado. No puede aplicar una configuración de repositorio si hay cambios sin confirmar en su repositorio. Después de clonar el repositorio, PowerShell Universal recargará completamente su configuración. ## Página de historial y estado de Git La pestaña de historial muestra todo el historial de commits de git del repositorio actual.
La pestaña de estado de sincronización muestra el estado actual de los nodos del clúster de PSU.
### Prueba de la sincronización de Git La mejor forma de asegurarse de que su sincronización de git funciona correctamente es hacer clic en el botón Synchronize Now. Esto forzará la ejecución de una sincronización y podrá verificar si la configuración introducida funcionó correctamente. ![](/files/A8fd3bJK3NvpbrCdR0do) ### Visualización de los cambios Puede ver los cambios en la tabla de sincronizaciones de git. Cada sincronización incluye el número de cambios encontrados desde la última sincronización, el SHA del commit y una lista de los cambios entre ese SHA y el anterior. Cuando los ficheros están en estado modificado, podrá ver las diferencias mediante la herramienta de comparación de ficheros. ![](/files/FAhFqrs9DpfKCLMcZXe1) ### Gestión de conflictos {% hint style="info" %} La resolución de conflictos solo está disponible en el modo de sincronización manual de git. {% endhint %} Cuando varios usuarios editan los ficheros de configuración de PowerShell Universal, pueden producirse conflictos. PowerShell Universal mostrará que un nodo concreto se encuentra en estado de conflicto al intentar confirmar los cambios. Verá una lista de los cambios en conflicto en la página de commits de git. Haga clic en el botón Resolve Conflict para ver el conflicto en un editor.
En este ejemplo, la cadena de este endpoint se editó tanto en el repositorio remoto como en el local.
Edite el texto para eliminar el conflicto.
Guarde los cambios y vuelva a la página de commits de git. Introduzca un nuevo mensaje de commit para el conflicto de fusión y haga clic en Commit Changes.
Esto resolverá el conflicto de fusión y realizará el push al remoto. ## Comportamiento de la sincronización de Git ### Bidireccional De forma predeterminada, la sincronización de git funciona en ambos sentidos. Si realiza cambios en la consola de administración de PSU, esos cambios se confirmarán y se sincronizarán con el remoto configurado. Cualquier cambio realizado en el remoto se descargará localmente. Si configura la sincronización de git con un remoto de git preexistente, los cambios se descargarán y se sincronizarán localmente. No puede tener ningún cambio localmente. Si configura la sincronización de git con un repositorio vacío (bare), los cambios locales se sincronizarán y el repositorio se inicializará. ### Unidireccional Puede ajustar el comportamiento de la sincronización de git cambiando el ajuste `GitSyncBehavior` en `appsettings.json`. Cuando se establece en `OneWay`, la consola de administración y la API de gestión pasarán a ser de solo lectura. El sistema PowerShell Universal descargará desde el remoto, pero nunca hará push ni confirmará cambios 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 El modo de sincronización de git solo push no descargará los cambios del remoto. Cualquier cambio realizado localmente se enviará al remoto. La consola no será de solo lectura. Esta configuración es útil para escenarios en los que se dispone de una máquina que se utiliza como configuración de referencia (fuente de verdad) para un conjunto de servidores de solo lectura. ```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 de acceso personal Recomendamos que utilice un token de acceso personal (PAT) en lugar de un nombre de usuario y una contraseña. Puede configurar un token de acceso personal estableciendo la propiedad de contraseña en `appsettings.json` u otros métodos de configuración. ```javascript "Data": { "RepositoryPath": "%ProgramData%\\UniversalAutomation\\Repository", "ConnectionString": "%ProgramData%\\UniversalAutomation\\database.db", "GitRemote": "https://github.com/myorg/myrepo.git", "GitUserName": "any", "GitPassword": "MYPAT----------------" }, ``` ### Tokens de granularidad fina de GitHub En GitHub, puede obtener un token de granularidad fina haciendo clic en su avatar en la esquina superior derecha, seleccionando Settings, Developers Settings, Personal Access Tokens y, a continuación, Fine-Grained Tokens. #### Ámbitos del token Al generar el token, asegúrese de otorgar al repositorio el permiso `Read-Write` sobre `Content`. Esto añadirá automáticamente el permiso de lectura sobre `Metadata`. Puede proporcionar acceso únicamente al repositorio que desea clonar. ### Tokens de GitHub (clásicos) En GitHub, puede obtener un token de acceso personal haciendo clic en su avatar en la esquina superior derecha, seleccionando Settings, Developer Settings, Personal Access Tokens y, a continuación, Tokens (Classic). Al generar su token de acceso, asegúrese de seleccionar los permisos Repo. ![](/files/VECPuFplAjhCzqPEnVe2) Tenga en cuenta que, si utiliza BitBucket, deberá especificar el nombre de usuario además del PAT en `appsettings.json`. ## Nombre de usuario y contraseña También puede configurar un remoto de git para autenticarse con un nombre de usuario y una contraseña. Establezca el nombre de usuario y la contraseña mediante el fichero `appsettings.json` u otro método de configuración. ```javascript "Data": { "RepositoryPath": "%ProgramData%\\UniversalAutomation\\Repository", "ConnectionString": "%ProgramData%\\UniversalAutomation\\database.db", "GitRemote": "https://github.com/myorg/myrepo.git", "GitUserName": "myusername", "GitPassword": "mypassword" }, ``` ## Errores comunes #### Git synchronization failed. unknown certificate lookup failure: 16777280 La biblioteca lib2gitsharp no pudo validar el certificado del repositorio git remoto. Deberá utilizar el [cliente git externo](#external-git-client) y una configuración de git personalizada para solucionarlo. Algunas opciones comunes para la compatibilidad con HTTPS en git incluyen: ``` 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 repeticiones de autenticación El remoto de git ha rechazado sus credenciales para acceder al repositorio. Puede que su token de acceso personal haya caducado o que no tenga acceso al remoto. #### repository not owned by current user El repositorio git local no tiene los controles de acceso adecuados para el usuario que intenta acceder a él. Esto puede ocurrir si PowerShell Universal clonó el repositorio y después se estableció una cuenta de servicio diferente en el servicio. Como los controles de acceso no coinciden, git no accederá a la carpeta. Se trata de una característica de seguridad de git. Puede actualizar el propietario de la carpeta para evitarlo o configurar git para que confíe en la carpeta. Establezca el siguiente valor en la configuración global de git. ``` [safe] directory = C:\ProgramData\UniversalAutomation\Repository ``` La configuración global se encuentra en: `C:\Program Files\git\etc\gitconfig` ## Ventajas de la sincronización de Git frente a la sincronización manual de Git Es posible sincronizar manualmente un repositorio con git. PowerShell Universal utiliza comandos muy básicos al trabajar con git. Cualquier cambio realizado en PowerShell Universal a través de la consola de administración o la API invoca un `git commit` y el autor se establece como la identidad del usuario que realiza el cambio. Durante una operación de sincronización de git, primero realizamos un `git pull` para asegurarnos de tener la última versión de los ficheros del remoto. A continuación, realizamos un `git push` para enviar los commits locales que se hayan producido desde la última sincronización. Podría lograr esta funcionalidad con un trabajo programado. Dicho esto, una de las funciones de la sincronización de git es que analiza el commit para asegurarse de que solo se recarguen los ficheros que se modificaron durante la sincronización. Esto evitará que los dashboards se despliguen automáticamente cuando no han cambiado o que los servicios de API se reinicien cuando los entornos no se han actualizado. Por lo tanto, aquí se obtiene una mejora de rendimiento. El otro problema es que, debido a la forma en que PowerShell Universal vigila los ficheros (con un `FileSystemWatcher`) y a la forma en que git actualiza los ficheros, las configuraciones no se recargarán automáticamente después de un pull. Tendrá que asegurarse de forzar que las configuraciones se vuelvan a evaluar. ## Estrategias de ramificación Las estrategias de ramificación en git determinan cómo se trasladan los cambios de una rama a otra. Utilizar distintos tipos de estrategias de ramificación en PowerShell Universal puede garantizar que equipos de diferentes tamaños trabajen juntos de forma eficaz en la plataforma. ### Usuarios individuales y equipos pequeños Para usuarios individuales y equipos pequeños, puede que no sea necesario tener más de una única rama. La rama se utiliza para el seguimiento del historial y ofrece la posibilidad de revertir cambios. Los usuarios accederán directamente a PowerShell Universal para realizar cambios o confirmarán los cambios en la rama única desde clones locales del directorio del repositorio utilizando una herramienta como VS Code. * main: rama única que acepta todos los cambios directamente ### Usuarios individuales y equipos pequeños con una rama de staging Incluso los usuarios individuales y los equipos pequeños pueden encontrar ventajoso emplear una rama de staging o dev. Esta rama recibirá los cambios durante el desarrollo. Se configurará una instancia independiente de PowerShell Universal para ejecutarse contra esta rama dev, de modo que los usuarios puedan validar los cambios antes de enviarlos a producción. Cuando se utiliza una configuración con una rama de staging, los entornos de PowerShell Universal están completamente separados. Utilizan una base de datos y un planificador diferentes. Los datos como las identidades, los tokens de aplicación y el historial de trabajos no se comparten entre los entornos. {% hint style="info" %} Cada instancia de PowerShell Universal requiere una [licencia](/powershell-universal/es/licensing.md). En esta configuración, se necesitarían dos licencias. {% endhint %} A continuación, se puede configurar una instancia separada de PowerShell Universal para que apunte a una rama main, o de producción, que recibirá actualizaciones mediante fusiones o Pull Requests en un sistema como GitHub. En esta configuración, es posible utilizar la sincronización de git unidireccional para descargar los cambios de main, pero sin enviar nunca cambios desde la plataforma. Esto también evita la mayoría de los conflictos de fusión, ya que se resolverán en la rama dev o mediante la herramienta de fusión del repositorio de origen. * main: rama de producción que recibe los cambios de los pull requests de la rama dev * dev: la rama de staging utilizada para aceptar commits y validar los cambios antes de enviarlos a master. ### Equipos de tamaño medio a grande Cuando se trata de equipos con más de un par de desarrolladores, una estrategia de ramificación más compleja puede resultar útil para evaluar mejor los cambios de código y evitar conflictos de fusión. PowerShell Universal proporciona herramientas de fusión básicas, pero existen herramientas mejores para este propósito, como los pull requests de GitHub, los merge requests de GitLab y herramientas locales como GitKraken. En equipos de tamaño medio, puede ser deseable disponer de ramas de funcionalidades adicionales que aíslen cambios concretos en una rama determinada. Por ejemplo, un desarrollador puede estar creando un nuevo conjunto de APIs para gestionar Azure en PowerShell Universal. Para evitar cambios que rompan la rama dev, los desarrolladores crearán su propia rama de funcionalidad que contenga todos sus cambios hasta que esté lo suficientemente completa para fusionarse en la rama de desarrollo. {% hint style="info" %} PowerShell Universal ofrece [licencias de desarrollador](/powershell-universal/es/licensing.md) para evitar tener que adquirir una licencia por cada desarrollador de su equipo. Seguirían siendo necesarias licencias para los entornos de producción y de staging. {% endhint %} En este tipo de configuración, el desarrollo local es ideal, ya que los desarrolladores trabajarán en su instancia local de PowerShell Universal dentro de su rama de funcionalidad. Cuando la funcionalidad esté completa, crearán un Pull o Merge request en el repositorio de origen para trasladar los cambios a la rama dev. Las pruebas se completarán en la rama dev antes de fusionar a producción. De forma similar a una estrategia de ramificación main\dev, todas las instancias de PowerShell Universal estarán aisladas y no compartirán base de datos ni planificador. Una vez que un conjunto de funcionalidades esté listo para producción, se realizará un Pull o Merge request de dev a la rama main. * main: rama de producción que solo recibirá cambios de dev * dev: rama de staging que recibe cambios de las ramas de funcionalidades, pero que no se modifica directamente * feature: rama de funcionalidad en la que los desarrolladores confirman directamente y que se fusiona con dev cuando está lista Según la complejidad de su entorno, puede ser aconsejable utilizar Deployments en lugar de git en producción. Consulte la sección Equipos grandes que aparece más abajo para obtener más información. ### Equipos grandes En equipos grandes, recomendamos utilizar git con fines de desarrollo, pero emplear Deployments, o un concepto similar, para producción. [Deployments ](/powershell-universal/es/config/deployments.md)proporciona paquetes de configuración inmutables que han sido probados exhaustivamente en entornos de nivel inferior. Al utilizar Deployments, puede elegir cómo desarrolla y gestiona su código y simplemente publicar el resultado en sus entornos de desarrollo, staging, QA y producción. Esto garantiza que todo el código esté bien probado antes de desplegarlo en sus sistemas críticos. Puede utilizar flujos de trabajo automatizados, como GitHub Actions, para publicar sus Deployments sin tener que actualizar manualmente ningún sistema. ## Alojamiento de Git PowerShell Universal admite cualquier solución estándar de alojamiento de git. Nuestros clientes utilizan con frecuencia las siguientes: * GitHub * GitHub Enterprise * GitLab * Bitbucket * Azure DevOps Aunque estas son las plataformas más habituales, admitimos cualquier plataforma que utilice el protocolo git. ### Ejemplo: Gitea También puede utilizar soluciones sencillas y autoalojadas como [Gitea](https://gitea.com). Aquí tiene un ejemplo de cómo configurar fácilmente un contenedor docker de Gitea para su uso 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/es/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.