> 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 Sincronice la configuración de PowerShell Universal con un repositorio git remoto, cubriendo ramas, autenticación, comportamiento de sincronización y resolución de conflictos. {% 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 los parámetros 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á volver a configurar la sincronización con git. Para configurar la sincronización con git, navegue hasta Source Control > Git > Settings dentro de la consola de administración. Podrá hacer clic en el botón Create Git Settings. {% hint style="info" %} En PowerShell Universal 5.x y versiones posteriores, las credenciales de Git (Remote URL, Username y Personal Access Token) se almacenan en la base de datos SQL en lugar de en appsettings.json. Editar estos parámetros en la interfaz de usuario actualizará la base de datos. Si edita los parámetros de Git y después hace clic en OK, PSU puede borrar las credenciales almacenadas aunque los campos parezcan 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 los parámetros dentro de la consola de administración no actualizará el fichero appsettings.json. Deberá hacerlo manualmente y reiniciar PowerShell Universal después de cambiar los parámetros. Si los parámetros de sincronización con git se especifican en la base de datos, los parámetros definidos en appsettings.json se ignoran. ## Parámetros 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 parámetro `GitBranch` dentro de su `appsettings.json`. #### Corregir el seguimiento de 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: {% code collapsedlinecount="10" %} ```powershell git fetch git branch --set-upstream-to=origin/main main git pull ``` {% endcode %} ### 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 las credenciales adecuadas para acceder a ese remoto. #### Formato de URL de Azure DevOps Los repositorios de Azure DevOps deben usar el formato de URL moderno `dev.azure.com` en lugar del dominio heredado `visualstudio.com`: **Formato correcto:** {% code collapsedlinecount="10" %} ``` https://dev.azure.com///_git/ ``` {% endcode %} **Ejemplos:** {% code collapsedlinecount="10" %} ``` https://dev.azure.com/mycompany/MyProject/_git/PowerShellUniversal https://dev.azure.com/mycompany/MyProject/_git/PSU%20Scripts ``` {% endcode %} 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 Personal Access Token debe tener el ámbito **Code (Read & Write)**. Los tokens de grano fino 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 cabeceras, es posible que deba usar la opción External Git Client y configurar los asistentes 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 una cabecera `Private-Token`. ### Autenticación Deberá 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. Deberá 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 Source Control > SSH Keys. Genere una nueva clave SSH. A continuación, haga clic en el botón de copia junto a la clave SSH para obtener la clave pública. Registre la clave pública en 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 Git Settings, seleccione la clave SSH que desea usar con la sincronización de git. Al usar claves SSH, asegúrese de seleccionar la URL de SSH para clonar su repositorio. {% code collapsedlinecount="10" %} ``` git@github.com:ironmansoftware/psu-devo ``` {% endcode %} #### Establecer credenciales Al usar 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 con la URL de destino. Es posible que deba cambiar la URL en función de su remoto de git. {% code collapsedlinecount="10" %} ```batch git config --global credential.helper store echo "https://${username}:${password_or_access_token}@github.com" > ~/.git-credentials ``` {% endcode %} También puede almacenar las credenciales directamente en la URL proporcionada a PowerShell Universal. {% code collapsedlinecount="10" %} ``` https://adam:APP_TOKEN@github.com/myOrg/myRepo.git ``` {% endcode %} #### 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 de git. Por ejemplo: {% code collapsedlinecount="10" %} ``` https://username:PAT@github.com/devolutions/powershell-universal ``` {% endcode %} #### Ejemplo: SSH y GitHub Primero, deberá 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 de SSH como URL del remoto de git en PowerShell Universal. La clave SSH configurada se usará para la conexión. {% code collapsedlinecount="10" %} ``` git@github.com:devolutions/powershell-universal.git ``` {% endcode %} #### Problema de certificado SSL {% hint style="warning" %} SSL Certificate problem: unable to get local issuer certificate {% endhint %} Si está ejecutando en Windows y recibe un problema de certificado SSL, es posible que deba asegurarse de haber [habilitado la compatibilidad con 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 sobre la persistencia de credenciales en wincredman, es posible que deba 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 una confirmación (commit) En la página de commit de git, puede ver los ficheros modificados e introducir un mensaje de commit. Una vez confirmados 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 los parámetros de git dentro de la consola de administración o dentro de `appsettings.json`. {% code collapsedlinecount="10" %} ```json "Data": { "RepositoryPath": "%ProgramData%\\UniversalAutomation\\Repository", "ConnectionString": "filename=%ProgramData%\\UniversalAutomation\\database.db;upgrade=true", "RunMigrations": true, "GitRemote": "", "GitUserName": "", "GitPassword": "", "GitBranch": "", "GitSyncBehavior": "TwoWay", "GitInitializeBehavior": "", "GitSyncInterval": "1", "ConfigurationScript": "", "ExternalGitClient": false "Mode": "Manual" // Or Automatic }, ``` {% endcode %} ### Mé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. El directorio de su repositorio debe ser simplemente una carpeta con sus ficheros de PowerShell Universal. Si existe una carpeta `.git` y no desea usar ese repositorio, debe 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. Debe ser un repositorio completamente vacío. Por ejemplo, al crear un repositorio en GitHub, no seleccione que se cree una licencia o un fichero readme.md. Una vez creado el repositorio, puede obtener la URL del remoto de git y proporcionarla al fichero `appsettings.json` de PowerShell Universal. Una vez que tenga la rama, la URL del remoto de git y las credenciales, puede proporcionarlas a su fichero `appsettings.json` y el remoto de git se poblará con sus ficheros locales. ### Método dos: extraer de un remoto de Git {% hint style="info" %} La ubicación predeterminada del repositorio local es `C:\ProgramData\UniversalAutomation\Repository` {% endhint %} Puede configurar PowerShell Universal para que extraiga (pull) de un remoto de git. En esta configuración, debe asegurarse de que la carpeta de su repositorio local esté completamente vacía. Cualquier fichero dentro de la carpeta hará que la sincronización con git falle e impedirá su recuperación. Configure el fichero `appsettings.json` para incluir la rama, las credenciales y la URL del remoto de git que está clonando. Una vez establecidos los campos, puede iniciar el servicio de PowerShell Universal. Lo primero que hará el servicio es clonar el repositorio y configurarlo localmente. ### Tiempo de espera de la sincronización con Git La sincronización con git agotará 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. Es posible que vea 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 parámetro de appsetting.json. El valor está en minutos. {% code collapsedlinecount="10" %} ```json "Data" : { "GitSyncTimeout": 30 } ``` {% endcode %} ### 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`: {% code collapsedlinecount="10" %} ```json "GitSyncInterval": 300 ``` {% endcode %} 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. ### Resolución de problemas #### Azure DevOps: "Too many redirects or authentication replays" Este error suele indicar uno de los siguientes problemas: * **Formato de URL heredado:** Asegúrese de usar `https://dev.azure.com///_git/` en lugar del dominio antiguo `visualstudio.com` * **Ámbito de PAT no válido:** Su Personal Access Token debe tener permisos **Code (Read & Write)** en Azure DevOps * **Credenciales caducadas:** Genere un nuevo PAT y vuelva a introducirlo en los parámetros 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 **Solución:** 1. Actualice la URL del remoto 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 sigue fallando #### Seguimiento de upstream ausente **Error:** "There is no tracking information for the current branch" **Causa:** La rama local de Git no está configurada para realizar el seguimiento de una rama remota. **Solución:** Abra PowerShell en el directorio del repositorio y ejecute: {% code collapsedlinecount="10" %} ```powershell git fetch git branch --set-upstream-to=origin/main main git pull ``` {% endcode %} Sustituya `main` por el nombre real de su rama. A continuación, haga clic en **Synchronize Now** en PSU. #### La sincronización con Git se detiene tras cambiar los parámetros en la interfaz de usuario **Síntomas:** Después de editar los parámetros 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 los parámetros parezcan correctos. **Causa:** En PSU 5.x, las credenciales de Git se almacenan en la base de datos SQL. Realizar cualquier cambio en los parámetros de Git a través de la interfaz de usuario puede borrar las credenciales almacenadas, aunque el campo de contraseña siga apareciendo rellenado en el formulario. **Solución:** 1. Vuelva a introducir el Personal Access Token en **Source Control > Git > Settings** 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 equilibrio 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 versión:** Asegúrese de que todos los servidores y agentes de PSU ejecuten la misma versión * **Reglas de firewall:** 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 External Git Client **Solución:** 1. Verifique que todos los nodos ejecutan la misma versión de PSU 2. Compruebe que las reglas de firewall 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 de git * Monte volúmenes persistentes para `/data` o `%ProgramData%\UniversalAutomation` a fin de conservar el estado de git entre reinicios * Si la sincronización falla de forma silenciosa, revise los registros del contenedor en busca de errores de git o de red #### Editar .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 upstream, puede editar la configuración del repositorio directamente a través del explorador de ficheros de PSU: 1. Navegue hasta **Platform → Configuration → Repository → .git → config** 2. Añada las siguientes líneas (ajuste el nombre de la rama para que coincida con su repositorio): {% code collapsedlinecount="10" %} ```ini [branch "main"] remote = origin merge = refs/heads/main ``` {% endcode %} 3. Haga clic en **Guardar** 4. Vuelva a **Source Control > Git > Settings** y haga clic en **Synchronize Now** Este enfoque le permite configurar el seguimiento de la rama ascendente sin necesidad de comandos `git`, lo que resulta especialmente útil cuando Git for 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 PowerShell Universal * Pruebe a 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 comprobar que los cambios se conservan * Si los cambios se revierten, compruebe si hay software antivirus, objetos de directiva de grupo (GPO) o permisos NTFS que bloqueen las escrituras en el directorio de datos de PSU **Habilite el registro de depuración para la resolución de problemas:** 1. Detenga el servicio PowerShell Universal 2. Edite `appsettings.json` y establezca: {% code collapsedlinecount="10" %} ```json "SystemLogLevel": "Debug" ``` {% endcode %} 3. Guarde y reinicie el servicio 4. Intente guardar de nuevo la configuración de Git 5. Revise `%PROGRAMDATA%\PowerShellUniversal\systemLog.txt` en busca de 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`: {% code collapsedlinecount="10" %} ```json "GitRemote": "https://dev.azure.com/org/project/_git/repo", "GitUserName": "any", "GitPassword": "your-PAT-here", "GitBranch": "main" ``` {% endcode %} Reinicie el servicio y compruebe que la configuración aparece en **Source Control > Git > Settings**. Si vuelve a desaparecer, los registros de depuración indicarán si la causa del restablecimiento es un problema de permisos, un software de protección de endpoints o un error de validación de la configuración. ### unknown certificate lookup failure: 16777280 Al utilizar la biblioteca de git integrada, es posible que encuentre 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 dentro 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 ## Varios repositorios Git PowerShell Universal admite el almacenamiento de varias configuraciones de repositorios git dentro de 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 borrar una configuración de repositorio. Tendrá que 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á por completo su configuración. ## Página de historial y estado de Git La pestaña de historial muestra todo el historial de confirmaciones de git del repositorio actual. La pestaña de estado de sincronización muestra el estado actual de los nodos dentro del clúster de PSU. ### Probar la sincronización de Git La mejor forma de asegurarse de que la 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á comprobar si la configuración introducida ha funcionado correctamente. ### Ver los cambios Puede ver los cambios en la tabla de sincronizaciones de git. Cada sincronización incluye el número de cambios detectados desde la última sincronización, el SHA de la confirmación 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. ### Gestionar los 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 cambios. Verá una lista de los cambios en conflicto en la página de confirmación 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: * Versión actual (local) — entre `<<<<<<< HEAD` y `=======`: `"That endpoint"` * Versión entrante (remota) — entre `=======` y `>>>>>>> main`: `"This endpoint"` Edite el texto para eliminar el conflicto. Guarde los cambios y vuelva a la página de confirmación de git. Introduzca un nuevo mensaje de confirmación 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 extraerá localmente. Si configura la sincronización de git con un remoto de git preexistente, los cambios se extraerá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 extraerá del remoto, pero nunca hará push ni confirmará localmente. {% code collapsedlinecount="10" %} ```javascript "Data": { "RepositoryPath": "%ProgramData%\\UniversalAutomation\\Repository", "ConnectionString": "%ProgramData%\\UniversalAutomation\\database.db", "DatabaseType": "LiteDB", "GitRemote": "https://github.com/myorg/myrepo.git", "GitUserName": "any", "GitPassword": "MYPAT----------------" "GitBranch": "dev", "GitSyncBehavior": "OneWay", "ConfigurationScript": "" }, ``` {% endcode %} ### Solo push El modo de sincronización de git solo de push no extraerá cambios del remoto. Cualquier cambio realizado localmente se enviará al remoto. La consola no será de solo lectura. Esta configuración resulta útil en escenarios en los que se dispone de una máquina que se utiliza como configuración de referencia para un conjunto de servidores de solo lectura. {% code collapsedlinecount="10" %} ```json "Data": { "RepositoryPath": "%ProgramData%\\UniversalAutomation\\Repository", "ConnectionString": "%ProgramData%\\UniversalAutomation\\database.db", "DatabaseType": "LiteDB", "GitRemote": "https://github.com/myorg/myrepo.git", "GitUserName": "any", "GitPassword": "MYPAT----------------" "GitBranch": "dev", "GitSyncBehavior": "PushOnly", "ConfigurationScript": "" }, ``` {% endcode %} ## Token de acceso personal Recomendamos utilizar 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 el `appsettings.json` u otros métodos de configuración. {% 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 %} ### 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 conceder al repositorio el permiso `Read-Write` sobre `Content`. Esto añadirá automáticamente Read al permiso `Metadata`. Puede conceder acceso únicamente al repositorio que desee 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 de Repo. 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 con el fichero `appsettings.json` u otro método de configuración. {% 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 %} ## 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 habituales para la compatibilidad con HTTPS en git son: {% code collapsedlinecount="10" %} ``` http.sslVerify Whether to verify the SSL certificate when fetching or pushing over HTTPS. Can be overridden by the GIT_SSL_NO_VERIFY environment variable. http.sslCAInfo File containing the certificates to verify the peer with when fetching or pushing over HTTPS. Can be overridden by the GIT_SSL_CAINFO environment variable. http.sslCAPath Path containing files with the CA certificates to verify the peer with when fetching or pushing over HTTPS. Can be overridden by the GIT_SSL_CAPATH environment variable. ``` {% endcode %} #### "too many redirects" o repeticiones de autenticación El remoto de git ha rechazado sus credenciales para acceder al repositorio. Es posible 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 función 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. {% code collapsedlinecount="10" %} ``` [safe] directory = C:\ProgramData\UniversalAutomation\Repository ``` {% endcode %} 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 las confirmaciones locales que se han producido desde la última sincronización. Podría lograr esta funcionalidad con un trabajo programado. Dicho esto, una función de la sincronización de git es que analiza la confirmación para garantizar que solo se recarguen los ficheros que han cambiado durante la sincronización. Esto evitará que los dashboards se implementen automáticamente cuando no han cambiado o que los servicios de API se reinicien cuando los entornos no se han actualizado. Por lo tanto, existe una mejora de rendimiento. El otro problema es que, debido a la forma en que PowerShell Universal supervisa 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 la reevaluación de las configuraciones. ## 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 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 con esta rama dev, de modo que los usuarios puedan validar los cambios antes de enviarlos a producción. Al utilizar una configuración con rama de staging, los entornos de PowerShell Universal están completamente separados. Utilizan una base de datos y un programador 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 independiente 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 extraer cambios de main pero nunca enviarlos desde la plataforma. Esto también evita la mayoría de los conflictos de fusión, ya que se abordarán en la rama dev o mediante la herramienta de fusión del repositorio de origen. * main: rama de producción que recibe cambios de las pull requests de la rama dev * dev: la rama de staging utilizada para aceptar confirmaciones y validar 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 ofrece herramientas básicas de fusión, pero existen herramientas mejores para este fin, como las pull requests de GitHub, las merge requests de GitLab y herramientas locales como GitKraken. En equipos de tamaño medio, puede ser conveniente disponer de ramas de funcionalidad adicionales que aíslen cambios concretos en una rama determinada. Por ejemplo, un desarrollador puede estar creando un nuevo conjunto de API para gestionar Azure en PowerShell Universal. Para evitar cambios disruptivos en la rama dev, los desarrolladores crearán su propia rama de funcionalidad que contenga todos sus cambios hasta que esté lo bastante completa como 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 comprar una licencia para cada desarrollador de su equipo. Seguirían siendo necesarias licencias para los entornos de producción y staging. {% endhint %} En este tipo de configuración, el desarrollo local es ideal porque los desarrolladores trabajarán en su instancia local de PowerShell Universal dentro de su rama de funcionalidad. Cuando la funcionalidad esté completa, crearán una 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 programador. Una vez que un conjunto de funcionalidades esté listo para producción, se creará una 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 funcionalidad 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 En función de la complejidad de su entorno, puede ser recomendable utilizar Deployments en lugar de git en producción. Consulte la sección Equipos grandes 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. Las [Deployments ](/powershell-universal/es/config/deployments.md)proporcionan paquetes de configuración inmutables que se han probado a fondo en entornos de nivel inferior. Al utilizar Deployments, puede elegir cómo desarrollar y gestionar 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 se pruebe a fondo antes de implementarlo 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 comunes, admitimos cualquier plataforma que utilice el protocolo git. ### Ejemplo: Gitea También puede utilizar soluciones sencillas y autoalojadas como [Gitea](https://gitea.com). A continuación se muestra 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.