{"schema_version":"1.0","service":"Publicasta","type":"article","id":881,"slug":"github_desktop_3_6_7_worktree_edge_cases","title":"GitHub Desktop 3.6.7 corrige los casos límite que vuelven arriesgados los worktrees","excerpt":"GitHub Desktop 3.6.7 es una actualización de mantenimiento centrada en los worktrees: mantiene visible el worktree activo, trata con seguridad las referencias que empiezan por guion, repara una ruta de Cygwin y evita un bloqueo al seguir el progreso de Git LFS.","language":"es","default_language":"en","canonical_url":"https://publicasta.com/open_source_radar/github_desktop_3_6_7_worktree_edge_cases?lang=es","image":{"url":"https://publicasta.com/storage/projects/10/pages/881/2026/10/b7302cd1-7397-4d9d-94fc-ebfd6382ba07.webp","alt":"Fotografía editorial de un portátil y carpetas de proyectos organizadas que representan varios worktrees enlazados de Git."},"publisher":{"id":10,"slug":"open_source_radar","name":"Open Source Radar","url":"https://publicasta.com/open_source_radar"},"author":{"name":"Anton R"},"published_at":"2026-10-14T13:38:42+00:00","updated_at":"2026-10-14T13:38:42+00:00","content_markdown":"GitHub Desktop 3.6.7 es una actualización pequeña, pero apunta a un problema muy concreto: esos momentos en los que un cliente gráfico de Git debe representar más de un checkout del mismo repositorio. La versión incorpora un ajuste para mantener visible el worktree actual, corrige el tratamiento de nombres que empiezan por guion, repara un problema de rutas al usar Open in Cygwin y soluciona un bloqueo en el seguimiento del progreso de Git LFS.\n\n ![Fotografía editorial de un portátil y carpetas de proyectos organizadas que representan varios worktrees enlazados de Git.](https://publicasta.com/storage/projects/10/pages/881/2026/10/b7302cd1-7397-4d9d-94fc-ebfd6382ba07.webp)\n\n Nada de esto cambia la naturaleza básica de GitHub Desktop. Sigue siendo un cliente de escritorio construido alrededor de Git, no un sustituto del modelo de repositorios de Git. Su valor es más acotado y práctico: si tu jornada incluye ramas paralelas, worktrees enlazados, archivos grandes o repositorios con nombres poco convencionales, la versión 3.6.7 elimina varias formas en que la interfaz podía interponerse.\n\n Por eso merece la pena probarla en equipos de mantenimiento y desarrollo que utilizan worktrees con frecuencia. No es motivo para alterar sin comprobaciones un flujo de trabajo estable, y tampoco convierte GitHub Desktop en un entorno completo de gestión de worktrees. El registro de cambios y la etiqueta de la versión describen una actualización de mantenimiento enfocada, mientras que la documentación de Git explica por qué algunas limitaciones restantes son estructurales y no meramente visuales.\n\n ## Qué cambia en la versión 3.6.7\n\n La [etiqueta oficial de la versión 3.6.7](https://github.com/desktop/desktop/releases/tag/release-3.6.7) agrupa los cambios en cuatro áreas.\n\n En primer lugar, los nombres de ramas, remotos y etiquetas que comienzan por un guion se manejan correctamente en las operaciones de fetch, push, checkout, merge, rebase y worktree. Un nombre como `-maintenance` es poco habitual, pero los repositorios de Git sí pueden contener nombres incómodos en los límites de una línea de comandos. Una aplicación gráfica debe pasar esos valores a Git sin alterarlos y distinguir un argumento de una opción. La corrección importa menos porque muchos equipos usen nombres con guion inicial que porque cierra de una vez una clase de ambigüedad de entrada en varios flujos.\n\n En segundo lugar, la actualización corrige la integración Open in Cygwin cuando la carpeta del repositorio contiene espacios o signos de puntuación. Este tipo de fallo puede pasar inadvertido en un directorio de pruebas cuidadosamente nombrado y resultar doloroso en un directorio real de usuario de Windows. El repositorio puede ser válido, el shell puede estar instalado y la integración aun así fallar si la ruta se construye o se cita de forma incorrecta. La nota de la versión es breve, pero su alcance está claro: las rutas son datos y las integraciones de escritorio deben conservarlas exactamente.\n\n En tercer lugar, el seguimiento del progreso de Git LFS ya no bloquea la aplicación cuando encuentra un error de lectura de archivos. Eso no vuelve legible el archivo afectado ni elimina la necesidad de investigar el almacenamiento, los permisos o un checkout dañado. Sí significa que un fallo al informar del progreso no debería arrastrar consigo al cliente. Para repositorios que almacenan binarios, recursos de diseño, conjuntos de datos u otros objetos grandes mediante Git LFS, es la corrección más directamente relacionada con la fiabilidad.\n\n Por último, el nuevo ajuste de apariencia mantiene visible el segmento de la barra correspondiente al worktree actual mediante la opción Always show worktree list. El registro de cambios de la beta anterior describe el comportamiento previsto: el control del worktree actual permanece presente en lugar de desaparecer cuando se contrae el resto de la lista. La diferencia parece pequeña hasta que un repositorio tiene varios checkouts enlazados y la persona necesita confirmar cuál está activo antes de hacer un commit.\n\n La versión también incluye el pulido habitual de una actualización de mantenimiento: mejora el contraste de los iconos de éxito y fallo en el resumen de comprobaciones y valida las rutas de los paquetes de aplicaciones de macOS en el diálogo de clonación. No son funciones protagonistas, pero encajan con el patrón general. La 3.6.7 trata de hacer más legibles y menos frágiles las condiciones de frontera.\n\n ## Por qué importa el ajuste de los worktrees\n\n Los worktrees de Git no son clones adicionales en el sentido habitual. La [documentación de Git sobre worktree](https://git-scm.com/docs/git-worktree) describe un árbol de trabajo principal y cero o más worktrees enlazados que comparten la mayor parte de los datos del repositorio, mientras mantienen separado el estado de elementos como `HEAD` y el índice. En la práctica, un mismo repositorio puede tener un checkout en una rama de funcionalidad, otro en una rama de lanzamiento y un tercero en una rama temporal de investigación sin descargar tres veces toda la base de objetos.\n\n Este modelo resulta especialmente útil cuando el trabajo cambia de contexto con frecuencia. Una persona encargada del mantenimiento puede conservar limpia una rama de lanzamiento mientras revisa una solicitud de cambios en otro directorio. Un desarrollador puede dejar una prueba prolongada o un servidor local en un worktree y pasar a una corrección de errores en otro. Las herramientas de programación automatizada también hacen más visibles estos escenarios, porque a menudo crean checkouts aislados para tareas paralelas. La disposición en el sistema de archivos cambia, pero el problema humano es el mismo: varios directorios parecen pertenecer al mismo proyecto y un descuido puede llevar un cambio al lugar equivocado.\n\n Un cliente que oculta el worktree actual hasta abrir un menú añade una pequeña dosis de incertidumbre a cada acción. Esa incertidumbre casi no pesa cuando el repositorio tiene un solo checkout. Se vuelve costosa cuando los nombres se parecen, las ramas duran poco o una herramienta crea directorios genéricos como `work`, `app` o `checkout`.\n\n La nueva visualización persistente no resuelve por sí sola la identificación. GitHub Desktop todavía necesita mostrar suficiente información sobre la ruta o la rama para distinguir los worktrees, y el gestor de incidencias indica que sigue siendo una preocupación de usabilidad activa. Una incidencia abierta propone mostrar al pasar el cursor la ruta completa de un worktree cuando varios árboles comparten el mismo nombre base de carpeta. Es un recordatorio útil: mantener visible la lista mejora el descubrimiento, pero no sustituye un sistema completo de nombres.\n\n La forma adecuada de interpretar el cambio es, por tanto, moderada. Hace más difícil olvidar el contexto actual. No garantiza que el directorio seleccionado sea el que pretendías usar y tampoco reemplaza la comprobación de la rama y la ruta antes de una acción irreversible.\n\n ## La versión se apoya en las propias restricciones de Git\n\n Algunas sorpresas de los worktrees no pueden resolverse completamente desde un cliente. Git comparte de forma deliberada referencias y objetos entre worktrees, al tiempo que mantiene separado el estado específico de cada uno. La documentación señala que `HEAD` y el índice son independientes, pero muchas referencias siguen siendo compartidas. Normalmente una rama solo puede estar retirada en un worktree a la vez, y Git rechazará determinadas operaciones salvo que el usuario las fuerce explícitamente.\n\n Esta distinción explica por qué un worktree puede ser barato y, aun así, exigir disciplina. Crear un segundo checkout no crea un repositorio totalmente independiente. Un fetch puede actualizar referencias remotas compartidas. La configuración puede ser común salvo que se active la configuración específica del worktree. Los hooks, los archivos generados, las cachés de compilación y los archivos de entorno pueden comportarse como si todos los checkouts formaran parte de un proyecto mayor, aunque los directorios de código fuente estén separados.\n\n También importan las reglas de limpieza. Git guarda la información administrativa de los árboles enlazados dentro del directorio `worktrees` del repositorio. Si alguien elimina una carpeta desde el explorador de archivos, los metadatos pueden permanecer hasta que se haga una poda. La vía admitida es usar `git worktree remove` para un árbol limpio, o `git worktree prune` después de verificar que el árbol ausente realmente ha desaparecido. Si un directorio se mueve manualmente, `git worktree repair` puede volver a conectar los metadatos.\n\n GitHub Desktop puede presentar estos estados con mayor claridad, pero no puede cambiarlos de forma segura. Quien interprete una lista visible de worktrees como una lista de clones independientes todavía puede equivocarse sobre las ramas compartidas, la configuración o el almacenamiento de objetos. La actualización funciona mejor junto al modelo de Git, no como sustituto de él.\n\n ## La corrección de nombres con guion inicial trata sobre el análisis de argumentos\n\n Es fácil descartar los guiones iniciales como una convención de nombres que nadie debería utilizar. Esa lectura pierde la lección de ingeniería que hay detrás de la corrección. Muchos programas de línea de comandos usan un guion para introducir opciones. Cuando una rama, un remoto, una etiqueta o una ruta válida también comienza por un guion, todas las capas que construyen el comando deben conservar la diferencia entre un valor y una bandera.\n\n Un cliente puede abordar el problema de varias maneras: manejar cuidadosamente arrays de argumentos, usar marcadores explícitos de fin de opciones cuando estén disponibles, validar los valores o combinar estas técnicas. Para la persona usuaria, lo importante es que las operaciones normales no vuelvan a interpretar un nombre de repositorio como una opción del comando.\n\n Merece atención la amplitud de la nota de la versión 3.6.7. La corrección no se limita al checkout. Cubre fetch, push, merge, rebase y acciones de worktree, lo que sugiere que el valor problemático puede atravesar varias rutas de comandos. Un repositorio puede parecer normal hasta que entra en juego un remoto o una etiqueta con la misma forma de nombre. Corregir la familia de operaciones es más valioso que parchear un solo elemento visible del menú.\n\n Los responsables del mantenimiento deberían seguir tratando los nombres de referencias poco habituales como una prueba de compatibilidad. Si la automatización del proyecto, los scripts de lanzamiento, los hooks del servicio de alojamiento o la documentación suponen que todos los nombres de rama son palabras convencionales separadas por barras, el cliente de escritorio solo es una parte del sistema. La versión 3.6.7 reduce un riesgo del lado del cliente, pero no vuelve robusta cualquier integración de terceros.\n\n Una matriz de prueba pequeña basta para validar el comportamiento sin convertirlo en un experimento de producción:\n\n - Crea un repositorio desechable y una rama cuyo nombre empiece por un guion.\n- Prueba fetch, checkout, merge y rebase en local antes de involucrar un remoto compartido.\n- Prueba un remoto o una etiqueta con la misma forma solo si la política del repositorio lo permite.\n- Confirma que las interfaces de línea de comandos y web utilizadas por el equipo coinciden en el nombre de la referencia.\n- Elimina las referencias de prueba de forma limpia después de la comprobación.\n\n La finalidad no es recomendar los nombres con guion inicial. Es comprobar que un repositorio existente con nombres incómodos siga siendo operativo.\n\n ## Git LFS: corregir un bloqueo no equivale a diagnosticar el almacenamiento\n\n Git LFS cambia la superficie de fallos de un repositorio. Git guarda archivos puntero en el historial normal, mientras que el contenido grande se gestiona mediante un servidor LFS y se descarga cuando hace falta. Por eso un indicador de progreso se sitúa entre la interfaz de usuario, el sistema de archivos local, el proceso de Git y la transferencia de LFS. Un error de lectura puede deberse a permisos, a un archivo que desaparece, a la interferencia de un antivirus, a un directorio montado en red, a un disco lleno o a un problema en la propia transferencia.\n\n El cambio de la 3.6.7 aborda la respuesta del cliente a uno de esos errores: el seguimiento del progreso no debería bloquear la aplicación. Es útil porque un bloqueo destruye el contexto. La persona puede perder el estado visible de la operación y tener que averiguar si la transferencia terminó, falló o dejó un archivo parcial. Si el cliente sigue abierto, puede mostrar el error y permitir la inspección del repositorio.\n\n Sería un error describirlo como una garantía de integridad de datos de LFS. Es una mejora de resistencia en la ruta de información del progreso. Después de actualizar, los equipos deberían verificar las operaciones con archivos grandes en un repositorio de prueba o en un checkout no crítico, especialmente en máquinas que usan recursos compartidos de red, discos externos, sistemas de seguridad de endpoint agresivos o permisos de sistema de archivos poco habituales.\n\n Si una transferencia falla, conviene revisar lo básico antes de repetirla muchas veces. Comprueba el espacio libre y los permisos de escritura. Verifica que la ruta sea local y estable. Consulta los registros de LFS y el endpoint configurado para el repositorio. Valida el checkout con el proceso normal de compilación o de comprobación de recursos del proyecto. Que la aplicación gráfica permanezca abierta ayuda, pero no demuestra que el objeto esté completo.\n\n Aquí también resulta relevante la naturaleza de código abierto de GitHub Desktop. El [repositorio](https://github.com/desktop/desktop) es público, su registro de cambios conserva referencias a incidencias y los metadatos de la aplicación identifican el proyecto como sujeto a la licencia MIT. Esa licencia permite inspeccionar y reutilizar el código, con las limitaciones de marca del proyecto y las licencias de las dependencias incluidas. No crea un contrato de soporte ni garantiza que todas las integraciones se comporten igual en todas las plataformas.\n\n ## Open in Cygwin y la importancia poco vistosa de las rutas\n\n La corrección de Cygwin pertenece a una categoría amplia de fallos del software de escritorio: la aplicación entiende una ruta de Windows, el shell de destino espera una ruta de estilo POSIX y el límite entre ambos contiene espacios o signos de puntuación. Una ruta como un directorio llamado `Open Source` o una carpeta con paréntesis es normal para un sistema de archivos y una fuente habitual de errores de comillas en los lanzadores.\n\n La pregunta práctica para cada usuario es si la integración reparada coincide con su estructura real de directorios. Si el repositorio está bajo una ruta con espacios, paréntesis, corchetes, ampersands o caracteres no ASCII, prueba la acción del menú después de actualizar. Hazlo desde un repositorio que no sea desechable, pero no uses un checkout de lanzamiento activo para la primera validación. Confirma que Cygwin se abre en el directorio esperado y que el shell ve los mismos archivos que el cliente de escritorio.\n\n Este cambio también muestra por qué las notas de versión de una interfaz gráfica pueden parecer más pequeñas que los errores que corrigen. La función en sí es solo una acción de menú. El fallo puede bloquear un flujo entero para quienes usan una cadena de herramientas similar a Unix en Windows. Entregar una ruta de forma fiable es infraestructura, aunque no sea una función llamativa.\n\n La misma cautela se aplica a los scripts iniciados desde el cliente. No des por hecho que el directorio de trabajo actual aporta todo el contexto necesario. Los scripts deberían resolver la raíz del repositorio, admitir espacios y mostrar un diagnóstico claro cuando la ruta no exista. La aplicación puede pasar una ruta correcta; la herramienta invocada todavía tiene que consumirla correctamente.\n\n ## Quién debería actualizar primero\n\n El caso más sólido para actualizar pronto es el de quien usa varios worktrees enlazados dentro de GitHub Desktop, trabaja con Git LFS, emplea Cygwin en Windows o tiene repositorios con nombres de referencias poco habituales. Son las personas más cercanas a las rutas afectadas y pueden comprobar si las correcciones encajan con su trabajo real.\n\n Un segundo grupo son los equipos de mantenimiento que incorporan colaboradores con sistemas operativos distintos. Una versión que elimina un fallo específico de una ruta o un nombre puede reducir la carga de soporte, pero sigue siendo conveniente publicar las versiones probadas y las expectativas de configuración del proyecto en lugar de tratar la actualización como una solución universal.\n\n Para alguien que usa un solo checkout en una máquina estable, la urgencia es menor. Las notas citadas aquí no anuncian una gran función nueva ni una respuesta de seguridad. Actualizar sigue siendo razonable como mantenimiento normal, pero hay poco beneficio en alterar un entorno controlado sin una comprobación de compatibilidad.\n\n El despliegue más seguro es gradual:\n\n 1. Instala la versión 3.6.7 en una máquina que represente el flujo de trabajo real del equipo.\n2. Abre un repositorio con un worktree enlazado y confirma que el worktree actual sigue visible.\n3. Ejecuta el flujo habitual de rama, commit, fetch, push y solicitud de cambios.\n4. Si corresponde, prueba una transferencia de LFS y la acción Open in Cygwin desde una ruta con espacios.\n5. Comprueba macOS, Windows y Linux por separado si el equipo admite más de una plataforma.\n6. Solo después actualiza la versión base documentada para los colaboradores.\n\n La actualización es lo bastante pequeña como para que este proceso sea rápido. También es lo bastante específica como para que una prueba genérica no detecte exactamente los errores que corrige.\n\n ## Lo que GitHub Desktop sigue sin ser\n\n GitHub Desktop no es un sustituto completo de la línea de comandos de Git. No oculta la diferencia entre un worktree y un clon, y no puede decidir si una rama debe compartirse, eliminarse, bloquearse o podarse. El mantenimiento avanzado del repositorio sigue correspondiendo a los comandos de Git y a la documentación operativa del proyecto.\n\n Tampoco es un sustituto completo del terminal de Cygwin. La integración reparada abre otro entorno; no unifica las semánticas de rutas de Windows y POSIX en todas las herramientas. Un equipo que combine PowerShell, Git Bash, Cygwin, WSL, contenedores y herramientas de compilación nativas debería mantener explícitas sus suposiciones sobre las rutas.\n\n Además, no es una frontera de seguridad para el contenido de los repositorios. Abrir un repositorio puede invocar hooks, representar datos no confiables, llamar a herramientas externas o interactuar con credenciales según el flujo de trabajo. Las mejoras del registro de cambios son valiosas, pero siguen siendo apropiadas las precauciones habituales: revisar los scripts del repositorio, limitar las credenciales, mantener actualizadas las dependencias y separar los checkouts experimentales de los entornos sensibles.\n\n Por último, que sea código abierto no significa que todas las partes de la distribución tengan la misma licencia. El repositorio identifica la aplicación como licenciada bajo MIT, mientras que las dependencias y las marcas de GitHub tienen sus propios términos. Las organizaciones que redistribuyan una compilación modificada deberían revisar los archivos de licencia, los avisos de terceros y las reglas de marca del repositorio, en lugar de tomar la expresión código abierto como una conclusión legal general.\n\n ## Alternativas para equipos que dependen de worktrees\n\n La primera alternativa es la propia línea de comandos de Git. Expone el modelo completo de worktrees y es el punto de referencia para operaciones como add, list, lock, move, repair, prune y remove. Un equipo que dependa mucho de los worktrees debería conocer estos comandos aunque la mayor parte del trabajo diario se haga en una interfaz gráfica.\n\n La segunda es un editor o IDE con soporte explícito para varios directorios raíz y worktrees. La ventaja está cerca del código, los terminales, las pruebas y las herramientas de lenguaje. El coste es que la interfaz puede facilitar la apertura de varias carpetas mientras ofrece menos visibilidad sobre el estado compartido de Git. Los equipos deberían acordar convenciones de nombres y etiquetas para los espacios de trabajo.\n\n La tercera es un gestor específico de worktrees o un conjunto pequeño de scripts de shell. Estas opciones pueden imponer una disposición de directorios, crear nombres previsibles y eliminar árboles obsoletos. También añaden una nueva superficie de mantenimiento. Un script cómodo en una máquina puede volverse peligroso si supone una estructura de rutas concreta, borra un árbol con cambios pendientes o ignora bloqueos y archivos sin seguimiento.\n\n GitHub Desktop 3.6.7 encaja mejor cuando un equipo quiere un cliente visual para las operaciones cotidianas de GitHub, pero acepta las reglas de los worktrees de Git. Es una capa intermedia útil, no una abstracción que borre el estado del repositorio.\n\n ## Veredicto práctico\n\n GitHub Desktop 3.6.7 merece una prueba si los worktrees, Git LFS, Cygwin o los nombres de referencias incómodos forman parte de tu trabajo. El ajuste visible del worktree mejora el contexto, la corrección de nombres con guion inicial cierra una clase real de errores en el manejo de argumentos, la reparación de Cygwin vuelve menos frágil un límite habitual de rutas en Windows y el cambio de LFS evita que un error de lectura de archivo bloquee el cliente.\n\n Para el resto, es una actualización de mantenimiento normal y de perfil tranquilo. La versión resulta más interesante como señal de las presiones que reciben los clientes gráficos de Git: los checkouts paralelos se vuelven habituales, los repositorios contienen más contenido generado y binario, y los desarrolladores se mueven constantemente entre entornos gráficos y de terminal.\n\n Instálala y prueba después los bordes que importan en tu repositorio. Mira cuál es el worktree activo antes de hacer commit. Mantén visibles la rama y la ruta. Usa los comandos propios de Git para eliminar o reparar directorios. Interpreta una corrección de bloqueo de LFS como una mejora de resistencia, no como un paso de verificación. Con eso basta para aprovechar la versión 3.6.7 sin pedirle a una actualización pequeña más de lo que promete.\n\n ## Fuentes\n\n - [Notas de la versión de GitHub Desktop 3.6.7](https://github.com/desktop/desktop/releases/tag/release-3.6.7), GitHub.\n- [Registro de cambios de GitHub Desktop](https://github.com/desktop/desktop/blob/development/changelog.json), GitHub.\n- [Repositorio de código fuente e información de licencias de GitHub Desktop](https://github.com/desktop/desktop), GitHub.\n- [Documentación de git-worktree](https://git-scm.com/docs/git-worktree), proyecto Git.\n- [Los worktrees enlazados son indistinguibles del repositorio principal en el desplegable](https://github.com/desktop/desktop/issues/22211), GitHub Issues.\n- [Mostrar la ruta completa de un worktree al pasar el cursor](https://github.com/desktop/desktop/issues/22946), GitHub Issues.","available_translations":[{"language":"ar","title":"GitHub Desktop 3.6.7 يصلح الحالات الطرفية التي تجعل Worktrees محفوفة بالمخاطر","html_url":"https://publicasta.com/open_source_radar/github_desktop_3_6_7_worktree_edge_cases?lang=ar","markdown_url":"https://publicasta.com/open_source_radar/github_desktop_3_6_7_worktree_edge_cases.md?lang=ar","json_url":"https://publicasta.com/open_source_radar/github_desktop_3_6_7_worktree_edge_cases.json?lang=ar","api_url":"https://publicasta.com/api/public/v1/channels/open_source_radar/articles/github_desktop_3_6_7_worktree_edge_cases?lang=ar"},{"language":"de","title":"GitHub Desktop 3.6.7 behebt die Sonderfälle, die Worktrees riskant machen","html_url":"https://publicasta.com/open_source_radar/github_desktop_3_6_7_worktree_edge_cases?lang=de","markdown_url":"https://publicasta.com/open_source_radar/github_desktop_3_6_7_worktree_edge_cases.md?lang=de","json_url":"https://publicasta.com/open_source_radar/github_desktop_3_6_7_worktree_edge_cases.json?lang=de","api_url":"https://publicasta.com/api/public/v1/channels/open_source_radar/articles/github_desktop_3_6_7_worktree_edge_cases?lang=de"},{"language":"en","title":"GitHub Desktop 3.6.7 fixes the edge cases that make worktrees risky","html_url":"https://publicasta.com/open_source_radar/github_desktop_3_6_7_worktree_edge_cases?lang=en","markdown_url":"https://publicasta.com/open_source_radar/github_desktop_3_6_7_worktree_edge_cases.md?lang=en","json_url":"https://publicasta.com/open_source_radar/github_desktop_3_6_7_worktree_edge_cases.json?lang=en","api_url":"https://publicasta.com/api/public/v1/channels/open_source_radar/articles/github_desktop_3_6_7_worktree_edge_cases?lang=en"},{"language":"es","title":"GitHub Desktop 3.6.7 corrige los casos límite que vuelven arriesgados los worktrees","html_url":"https://publicasta.com/open_source_radar/github_desktop_3_6_7_worktree_edge_cases?lang=es","markdown_url":"https://publicasta.com/open_source_radar/github_desktop_3_6_7_worktree_edge_cases.md?lang=es","json_url":"https://publicasta.com/open_source_radar/github_desktop_3_6_7_worktree_edge_cases.json?lang=es","api_url":"https://publicasta.com/api/public/v1/channels/open_source_radar/articles/github_desktop_3_6_7_worktree_edge_cases?lang=es"},{"language":"fr","title":"GitHub Desktop 3.6.7 corrige les cas limites qui rendent les worktrees risqués","html_url":"https://publicasta.com/open_source_radar/github_desktop_3_6_7_worktree_edge_cases?lang=fr","markdown_url":"https://publicasta.com/open_source_radar/github_desktop_3_6_7_worktree_edge_cases.md?lang=fr","json_url":"https://publicasta.com/open_source_radar/github_desktop_3_6_7_worktree_edge_cases.json?lang=fr","api_url":"https://publicasta.com/api/public/v1/channels/open_source_radar/articles/github_desktop_3_6_7_worktree_edge_cases?lang=fr"},{"language":"pl","title":"GitHub Desktop 3.6.7 naprawia sytuacje brzegowe, które utrudniają pracę z worktree","html_url":"https://publicasta.com/open_source_radar/github_desktop_3_6_7_worktree_edge_cases?lang=pl","markdown_url":"https://publicasta.com/open_source_radar/github_desktop_3_6_7_worktree_edge_cases.md?lang=pl","json_url":"https://publicasta.com/open_source_radar/github_desktop_3_6_7_worktree_edge_cases.json?lang=pl","api_url":"https://publicasta.com/api/public/v1/channels/open_source_radar/articles/github_desktop_3_6_7_worktree_edge_cases?lang=pl"},{"language":"ru","title":"GitHub Desktop 3.6.7 устраняет пограничные случаи, из-за которых worktree становятся рискованными","html_url":"https://publicasta.com/open_source_radar/github_desktop_3_6_7_worktree_edge_cases?lang=ru","markdown_url":"https://publicasta.com/open_source_radar/github_desktop_3_6_7_worktree_edge_cases.md?lang=ru","json_url":"https://publicasta.com/open_source_radar/github_desktop_3_6_7_worktree_edge_cases.json?lang=ru","api_url":"https://publicasta.com/api/public/v1/channels/open_source_radar/articles/github_desktop_3_6_7_worktree_edge_cases?lang=ru"},{"language":"zh","title":"GitHub Desktop 3.6.7 修复了让 worktree 变得棘手的边缘问题","html_url":"https://publicasta.com/open_source_radar/github_desktop_3_6_7_worktree_edge_cases?lang=zh","markdown_url":"https://publicasta.com/open_source_radar/github_desktop_3_6_7_worktree_edge_cases.md?lang=zh","json_url":"https://publicasta.com/open_source_radar/github_desktop_3_6_7_worktree_edge_cases.json?lang=zh","api_url":"https://publicasta.com/api/public/v1/channels/open_source_radar/articles/github_desktop_3_6_7_worktree_edge_cases?lang=zh"}],"_links":{"self":"https://publicasta.com/open_source_radar/github_desktop_3_6_7_worktree_edge_cases.json?lang=es","api":"https://publicasta.com/api/public/v1/channels/open_source_radar/articles/github_desktop_3_6_7_worktree_edge_cases?lang=es","html":"https://publicasta.com/open_source_radar/github_desktop_3_6_7_worktree_edge_cases?lang=es","canonical":"https://publicasta.com/open_source_radar/github_desktop_3_6_7_worktree_edge_cases?lang=es","markdown":"https://publicasta.com/open_source_radar/github_desktop_3_6_7_worktree_edge_cases.md?lang=es","json":"https://publicasta.com/open_source_radar/github_desktop_3_6_7_worktree_edge_cases.json?lang=es","channel":"https://publicasta.com/api/public/v1/channels/open_source_radar","channel_articles":"https://publicasta.com/api/public/v1/channels/open_source_radar/articles","search":"https://publicasta.com/api/public/v1/search","documentation":"https://publicasta.com/api-docs#reading-publicasta","openapi":"https://publicasta.com/api-docs/openapi.json","llms":"https://publicasta.com/llms.txt"}}