{"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 устраняет пограничные случаи, из-за которых worktree становятся рискованными","excerpt":"GitHub Desktop 3.6.7 — точечный выпуск для параллельных рабочих деревьев: он оставляет текущее worktree на виду, безопаснее обрабатывает refs с дефисом в начале, исправляет путь Cygwin и предотвращает сбой отслеживания прогресса Git LFS.","language":"ru","default_language":"en","canonical_url":"https://publicasta.com/open_source_radar/github_desktop_3_6_7_worktree_edge_cases?lang=ru","image":{"url":"https://publicasta.com/storage/projects/10/pages/881/2026/10/b7302cd1-7397-4d9d-94fc-ebfd6382ba07.webp","alt":"Редакционная фотография ноутбука и организованных папок проектов, символизирующих несколько связанных рабочих деревьев Git."},"publisher":{"id":10,"slug":"open_source_radar","name":"Open Source радар","url":"https://publicasta.com/open_source_radar"},"author":{"name":"Anton R"},"published_at":"2026-10-14T13:38:40+00:00","updated_at":"2026-10-14T13:38:40+00:00","content_markdown":"GitHub Desktop 3.6.7 устраняет пограничные случаи, из-за которых worktree становятся рискованными\n\n ![Редакционная фотография ноутбука и организованных папок проектов, символизирующих несколько связанных рабочих деревьев Git.](https://publicasta.com/storage/projects/10/pages/881/2026/10/b7302cd1-7397-4d9d-94fc-ebfd6382ba07.webp)\n\n GitHub Desktop 3.6.7 — небольшой выпуск с на редкость практичной целью: исправить моменты, когда графическому Git-клиенту приходится представлять несколько checkout одного и того же репозитория. В обновлении появился параметр, который оставляет текущее рабочее дерево видимым, исправлена обработка имен, начинающихся с дефиса, устранена проблема с путем в Open in Cygwin и ликвидирован сбой отслеживания прогресса Git LFS.\n\n Базовая модель GitHub Desktop от этого не меняется. Это по-прежнему настольный клиент поверх Git, а не замена модели репозитория Git. Польза обновления более узкая и потому вполне прикладная: если в повседневной работе появились параллельные ветки, связанные worktree, большие файлы или репозитории с неудобными именами, версия 3.6.7 убирает несколько способов, которыми интерфейс мог мешать работе.\n\n Поэтому выпуск стоит протестировать сопровождающим и разработчикам, которые регулярно используют worktree. Это не повод без проверки менять стабильный командный процесс: обновление нужно проверить на каждой используемой операционной системе. Кроме того, GitHub Desktop не превращается в полноценную среду управления рабочими деревьями. Собственный журнал изменений и тег релиза описывают точечное техническое обновление, а документация Git объясняет, почему некоторые оставшиеся ограничения имеют структурную, а не косметическую природу.\n\n ## Что изменилось в версии 3.6.7\n\n Официальный [тег релиза 3.6.7](https://github.com/desktop/desktop/releases/tag/release-3.6.7) перечисляет четыре группы изменений.\n\n Во-первых, имена веток, remote и тегов, начинающиеся с дефиса, теперь корректно обрабатываются при fetch, push, checkout, merge, rebase и операциях с worktree. Имя вроде `-maintenance` необычно, но Git-репозитории действительно могут содержать названия, неудобные на границе командной строки. Графическое приложение все равно должно безопасно передать такое значение Git и отличить аргумент от опции. Исправление важно не потому, что большинство команд использует имена с начальным дефисом, а потому, что оно закрывает целый класс неоднозначностей ввода сразу в нескольких сценариях.\n\n Во-вторых, исправлена интеграция Open in Cygwin, когда папка репозитория содержит пробелы или знаки пунктуации. Такой дефект может быть незаметен в тестовом каталоге с аккуратным именем и сразу стать болезненным в настоящем домашнем каталоге Windows. Репозиторий может быть корректным, оболочка — установленной, а интеграция все равно не сработает, если путь собран или заключен в кавычки неправильно. Примечание к выпуску короткое, но его смысл ясен: пути — это данные, и настольные интеграции должны сохранять их без искажений.\n\n В-третьих, отслеживание прогресса Git LFS больше не приводит к падению приложения при ошибке чтения файла. Это не делает сам файл доступным для чтения и не отменяет необходимость проверить хранилище, права доступа или поврежденный checkout. Но ошибка, возникшая на этапе отображения прогресса, больше не должна увлекать за собой весь клиент. Для репозиториев, где через Git LFS хранятся бинарные файлы, дизайн-материалы, наборы данных или другие крупные объекты, это наиболее явно ориентированное на надежность исправление в выпуске.\n\n Наконец, новая настройка Appearance оставляет сегмент панели текущего worktree видимым благодаря параметру Always show worktree list. В более раннем beta-журнале изменений описывалось предполагаемое поведение: элемент управления текущим рабочим деревом остается на месте, даже когда остальной список свернут. Разница кажется небольшой, пока в репозитории не появляется несколько связанных checkout и пользователю не требуется перед коммитом убедиться, какое дерево активно.\n\n В релиз вошла и небольшая полировка, ожидаемая от настольного технического обновления: улучшен контраст значков успеха и ошибки в сводке проверок, а в диалоге клонирования добавлена проверка путей пакета приложения macOS. Это не главные функции, но они соответствуют общей логике выпуска. Версия 3.6.7 делает пограничные состояния более заметными и менее хрупкими.\n\n ## Почему настройка worktree имеет значение\n\n Git worktree — это не дополнительные клоны в обычном смысле. В [документации Git по worktree](https://git-scm.com/docs/git-worktree) описываются основное рабочее дерево и ноль или больше связанных рабочих деревьев, которые совместно используют большую часть данных репозитория, но хранят такие состояния, как HEAD и index, отдельно. Практически это означает, что один репозиторий может иметь один checkout ветки функции, второй — ветки релиза, а третий — временной ветки для расследования, не загружая всю базу объектов трижды.\n\n Такая модель особенно полезна для работы, в которой приходится часто менять контекст. Сопровождающий может оставить релизную ветку чистой, одновременно просматривая pull request в другом каталоге. Разработчик может держать длительный тест или локальный сервер в одном worktree, а исправление ошибки выполнять в другом. Инструменты автоматизированной разработки тоже сделали worktree заметнее, поскольку часто создают изолированные checkout для параллельных задач. Структура файлов меняется, но человеческая проблема остается прежней: несколько каталогов выглядят как один и тот же проект, и ошибка может отправить изменения не туда.\n\n Клиент, который скрывает текущее рабочее дерево до открытия меню, добавляет небольшую неопределенность к каждому действию. В репозитории с одним checkout это почти не ощущается. Но когда имена похожи, ветки живут недолго или инструмент создает каталоги с общими названиями вроде `work`, `app` или `checkout`, такая неопределенность начинает дорого обходиться.\n\n Постоянное отображение списка само по себе не решает задачу идентификации. GitHub Desktop все еще должен показывать достаточно сведений о пути или ветке, чтобы различать worktree, а текущий трекер задач показывает, что это остается активной проблемой удобства. В одной открытой задаче предлагается показывать полный путь рабочего дерева при наведении, если несколько деревьев имеют одинаковое базовое имя папки. Это полезное напоминание: видимый список улучшает обнаруживаемость, но не заменяет продуманную схему именования.\n\n Поэтому изменение стоит воспринимать сдержанно. Оно снижает вероятность забыть текущий контекст. Но оно не гарантирует, что выбран именно нужный каталог, и не отменяет проверки ветки и пути перед необратимым действием.\n\n ## Выпуск опирается на собственные ограничения Git\n\n Некоторые неожиданности worktree невозможно полностью исправить на уровне клиента. Git намеренно разделяет refs и объекты между рабочими деревьями, одновременно сохраняя состояние каждого дерева отдельно. Документация отмечает, что HEAD и index разделены, но многие refs остаются общими. Обычно ветку можно checkout только в одном worktree одновременно, и Git откажется выполнять некоторые операции, если пользователь явно не запросит принудительное выполнение.\n\n Это различие объясняет, почему второе рабочее дерево создается дешево, но все равно требует дисциплины. Создание второго checkout не создает полностью независимый репозиторий. Fetch может обновить общие remote-tracking refs. Конфигурация может быть общей, если не включена конфигурация, специфичная для worktree. Hooks, сгенерированные файлы, кэши сборки и файлы окружения могут вести себя так, будто все checkout принадлежат одному большому проекту, даже когда исходные каталоги разделены.\n\n Важны и правила очистки. Git хранит административную информацию о связанных деревьях внутри каталога `worktrees` репозитория. Если удалить папку worktree в файловом менеджере, метаданные могут остаться до тех пор, пока их не очистят. Поддерживаемый путь — использовать `git worktree remove` для чистого дерева или `git worktree prune` после проверки, что отсутствующее дерево действительно удалено. Если каталог был перемещен вручную, `git worktree repair` может восстановить связь с метаданными.\n\n GitHub Desktop способен понятнее показать эти состояния, но безопасно изменить их он не может. Пользователь, который воспринимает видимый список worktree как список независимых клонов, все еще может ошибиться насчет общих веток, конфигурации или хранения объектов. Выпуск следует использовать вместе с моделью Git, а не вместо нее.\n\n ## Исправление имен с дефисом связано с разбором аргументов, а не со стилем\n\n Начальные дефисы легко списать на соглашение об именовании, которого просто не стоит придерживаться. Такой взгляд упускает инженерный смысл исправления. Многие программы командной строки используют дефис для обозначения опций. Если допустимая ветка, remote, тег или путь тоже начинается с дефиса, каждый слой, формирующий команду, должен сохранить различие между значением и флагом.\n\n Клиент может решить эту задачу несколькими способами: аккуратно работать с массивом аргументов, явно использовать маркер окончания опций там, где он поддерживается, применять валидацию или сочетать эти приемы. Для пользователя важен результат: обычные операции не должны интерпретировать имя репозитория как параметр команды.\n\n Стоит обратить внимание на широту примечания к версии 3.6.7. Исправление ограничено не checkout. Оно охватывает fetch, push, merge, rebase и действия с worktree, то есть проблемное значение, вероятно, проходило через несколько командных путей. Репозиторий может выглядеть совершенно обычным, пока не появится remote или тег с таким же типом имени. Исправить семейство операций полезнее, чем добавить заплатку в один заметный пункт меню.\n\n Сопровождающим все же следует рассматривать необычные имена refs как проверку совместимости. Если автоматизация проекта, релизные скрипты, hooks хостинга или документация предполагают, что каждое имя ветки — это обычное слово, разделенное слешами, настольный клиент остается лишь одной частью системы. Версия 3.6.7 снижает один клиентский риск, но не делает устойчивой каждую стороннюю интеграцию.\n\n Небольшой набор проверок позволяет убедиться в поведении, не превращая тест в эксперимент над рабочей системой:\n\n - Создайте временный репозиторий и ветку с дефисом в начале имени.\n- Локально проверьте fetch, checkout, merge и rebase до подключения общего remote.\n- Попробуйте remote или тег с такой же формой имени, только если это разрешено политикой репозитория.\n- Убедитесь, что интерфейсы командной строки и веб-сервис, которыми пользуется команда, одинаково понимают имя ref.\n- После проверки аккуратно удалите тестовые refs.\n\n Цель не в том, чтобы рекомендовать имена с начальным дефисом. Нужно убедиться, что существующий репозиторий с неудобными именами остается работоспособным.\n\n ## Git LFS: исправление падения не заменяет диагностику хранилища\n\n Git LFS меняет поверхность отказов репозитория. Git хранит в обычной истории файлы-указатели, а крупное содержимое управляется сервером LFS и загружается по мере необходимости. Поэтому индикатор прогресса находится на границе между интерфейсом пользователя, локальной файловой системой, процессом Git и передачей LFS. Ошибка чтения может быть вызвана правами доступа, исчезнувшим файлом, вмешательством антивируса, сетевым каталогом, переполненным диском или самой проблемой передачи.\n\n Изменение в версии 3.6.7 касается реакции клиента на одну из таких ошибок: отслеживание прогресса не должно приводить к падению приложения. Это полезно, потому что при падении теряется контекст. Пользователь может лишиться видимого состояния операции и будет вынужден выяснять, завершилась ли передача, закончилась ошибкой или оставила частичный файл. Работающий клиент способен показать ошибку и дать возможность проверить репозиторий.\n\n Было бы ошибкой описывать это как гарантию целостности данных LFS. Это улучшение устойчивости пути отображения. После обновления командам все равно следует проверять операции с большими файлами на тестовом репозитории или не критичном checkout, особенно на машинах с сетевыми ресурсами, внешними дисками, агрессивными средствами защиты конечных точек или необычными правами файловой системы.\n\n Если передача не удалась, перед многократным повтором проверьте базовые условия. Убедитесь, что достаточно свободного места и есть права на запись. Проверьте, находится ли путь на локальном и стабильном носителе. Посмотрите журналы LFS и настроенный endpoint репозитория. Проверьте checkout обычной для проекта сборкой или процедурой валидации ресурсов. То, что графическое приложение осталось открытым, полезно, но не доказывает завершенность объекта.\n\n Здесь важна и открытая природа GitHub Desktop. [Репозиторий](https://github.com/desktop/desktop) публичен, его журнал изменений содержит ссылки на задачи, а метаданные приложения указывают на лицензию MIT. Эта лицензия делает код доступным для изучения и повторного использования с учетом ограничений проекта на товарные знаки и лицензий встроенных зависимостей. Она не создает договора поддержки и не гарантирует одинаковое поведение каждой интеграции на каждой платформе.\n\n ## Open in Cygwin и неприметная важность путей\n\n Исправление Cygwin относится к более широкой категории отказов настольного ПО: приложение понимает путь Windows, целевая оболочка ожидает путь в POSIX-подобном формате, а на границе между ними встречаются пробелы или знаки пунктуации. Путь вроде каталога с названием `Open Source` или папки со скобками обычен для файловой системы и часто становится источником ошибок кавычек в средствах запуска.\n\n Практический вопрос для пользователя — соответствует ли исправленная интеграция реальной структуре его каталогов. Если репозиторий находится по пути с пробелами, круглыми или квадратными скобками, амперсандами либо не-ASCII символами, после обновления проверьте действие меню. Используйте репозиторий, который не является одноразовым, но первую проверку не проводите на активном checkout релиза. Убедитесь, что Cygwin открывается в нужном каталоге и оболочка видит те же файлы, что и настольный клиент.\n\n Это изменение также показывает, почему заметки к релизам GUI иногда кажутся меньше, чем исправленные ими проблемы. Сама функция — всего лишь пункт меню. Но ее отказ способен заблокировать весь рабочий процесс тех, кто использует Unix-подобный инструментарий в Windows. Надежная передача пути — инфраструктура, даже если это не эффектная новая возможность.\n\n Такая же осторожность нужна для скриптов, запускаемых из клиента. Не стоит считать текущий рабочий каталог достаточным контекстом. Скрипты должны находить корень репозитория, корректно обрабатывать пробелы и выдавать понятную диагностику, если путь не существует. Приложение может передать правильный путь, но вызываемый инструмент все равно должен правильно его принять.\n\n ## Кому стоит обновиться в первую очередь\n\n Самый сильный аргумент за быстрое обновление есть у разработчика, который использует несколько связанных worktree внутри GitHub Desktop, работает с Git LFS, применяет Cygwin в Windows или имеет репозитории с необычными именами refs. Эти пользователи ближе всего к затронутым сценариям и быстрее заметят, соответствуют ли исправления их рабочему процессу.\n\n Вторая группа — сопровождающие, которые подключают участников с разными операционными системами. Выпуск, устраняющий сбой, зависящий от пути или имени, может уменьшить нагрузку на поддержку. Но лучше публиковать проверенные версии и требования к настройке проекта, а не считать обновление настольного клиента универсальным исправлением.\n\n Для пользователя с одним checkout на стабильной машине срочность ниже. В процитированных здесь заметках выпуск не представлен как крупное функциональное обновление или ответ на проблему безопасности. Обновиться в рамках обычного обслуживания разумно, но нет большой пользы в нарушении контролируемого окружения без проверки совместимости.\n\n Безопаснее всего распространять обновление поэтапно:\n\n 1. Установите версию 3.6.7 на одной машине, которая отражает реальный рабочий процесс команды.\n2. Откройте репозиторий со связанным worktree и убедитесь, что текущее дерево остается видимым.\n3. Выполните обычный сценарий работы с веткой, коммитом, fetch, push и pull request.\n4. Если это актуально, проверьте передачу LFS и действие Open in Cygwin из пути с пробелами.\n5. Отдельно проверьте macOS, Windows и Linux, если команда поддерживает больше одной платформы.\n6. Только после этого обновите зафиксированную в документации базовую версию для участников.\n\n Выпуск достаточно мал, чтобы такая процедура заняла немного времени. Но он и достаточно специфичен, поэтому общий smoke-тест может не затронуть ровно те ошибки, которые были исправлены.\n\n ## Чем GitHub Desktop по-прежнему не является\n\n GitHub Desktop не заменяет Git в командной строке. Он не скрывает различие между worktree и клоном и не может решить, следует ли ветку сделать общей, удалить, заблокировать или очистить. Расширенное обслуживание репозитория по-прежнему относится к командам Git и собственной эксплуатационной документации проекта.\n\n Это также не полная замена терминалу Cygwin. Исправленная интеграция открывает другую среду, но не объединяет семантику путей Windows и POSIX во всех инструментах. Команде, которая смешивает PowerShell, Git Bash, Cygwin, WSL, контейнеры и нативные инструменты сборки, нужно явно фиксировать предположения о путях.\n\n Клиент не является и границей безопасности для содержимого репозитория. Открытие репозитория может запускать hooks, отображать ненадежные данные, вызывать внешние инструменты или взаимодействовать с учетными данными — в зависимости от рабочего процесса. Улучшения из журнала изменений полезны, но обычные меры предосторожности остаются уместными: проверяйте скрипты репозитория, ограничивайте учетные данные, обновляйте зависимости и отделяйте экспериментальные checkout от чувствительных окружений.\n\n Наконец, открытый исходный код не означает, что все части дистрибутива имеют одну лицензию. Репозиторий определяет приложение как распространяемое по лицензии MIT, тогда как зависимости и товарные знаки GitHub регулируются собственными условиями. Организациям, которые распространяют измененную сборку, следует проверить файлы лицензий, уведомления о сторонних компонентах и правила брендинга, а не делать общий юридический вывод только из слов «открытый исходный код».\n\n ## Альтернативы для команд, активно использующих worktree\n\n Первая альтернатива — сама командная строка Git. Она показывает полную модель worktree и служит эталоном для операций `add`, `list`, `lock`, `move`, `repair`, `prune` и `remove`. Команде, которая сильно зависит от рабочих деревьев, стоит знать эти команды, даже если большая часть ежедневной работы проходит в GUI.\n\n Вторая — редактор или IDE с явной поддержкой нескольких корней и worktree. Преимущество в близости к коду, терминалам, тестам и языковым инструментам. Компромисс в том, что интерфейс может упростить открытие нескольких папок, одновременно хуже показывая общее состояние Git. Команде стоит договориться о соглашениях по именам и подписям рабочих пространств.\n\n Третья — специализированный менеджер worktree или небольшой набор shell-скриптов. Они могут навязать структуру каталогов, создавать предсказуемые имена и удалять устаревшие деревья. Но вместе с этим появляется новая поверхность обслуживания. Скрипт, удобный на одной машине, становится опасным, если предполагает конкретную раскладку путей, удаляет измененное дерево или игнорирует блокировки и неотслеживаемые файлы.\n\n GitHub Desktop 3.6.7 лучше всего подходит команде, которой нужен визуальный клиент для повседневных операций GitHub и которая при этом принимает правила Git для worktree. Это полезный промежуточный слой, а не абстракция, стирающая состояние репозитория.\n\n ## Практический вывод\n\n GitHub Desktop 3.6.7 стоит протестировать, если в рабочей жизни присутствуют worktree, Git LFS, Cygwin или неудобные имена refs. Видимая настройка рабочего дерева улучшает понимание текущего контекста, исправление имен с начальным дефисом закрывает реальный класс ошибок обработки аргументов, обновление Cygwin делает распространенную границу путей Windows менее хрупкой, а изменение в LFS не позволяет ошибке чтения файла обрушить клиент.\n\n Для остальных это обычное техническое обновление без драматического профиля. Выпуск интересен скорее как сигнал о том, где настольные Git-клиенты испытывают нагрузку: параллельные checkout становятся привычными, репозитории содержат больше сгенерированного и бинарного содержимого, а разработчики постоянно переходят между графическими и терминальными средами.\n\n Установите обновление и проверьте именно те пограничные случаи, которые важны для вашего репозитория. Перед коммитом смотрите на активное worktree. Держите имена веток и пути на виду. При удалении или восстановлении каталогов пользуйтесь собственными командами Git для worktree. Считайте исправление падения LFS улучшением устойчивости, а не заменой проверки. Этого достаточно, чтобы получить пользу от версии 3.6.7 и не требовать от небольшого выпуска обещаний, которых он не дает.\n\n ## Источники\n\n Фактические сведения и контекст сохранены по материалам релиза GitHub Desktop и документации проекта:\n\n - [Заметки к релизу GitHub Desktop 3.6.7](https://github.com/desktop/desktop/releases/tag/release-3.6.7) — факты о выпуске.\n- [Журнал изменений GitHub Desktop](https://github.com/desktop/desktop/blob/development/changelog.json) — факты о поведении и исправлениях.\n- [Исходный репозиторий GitHub Desktop](https://github.com/desktop/desktop) — сведения о проекте и лицензировании.\n- [Документация git-worktree](https://git-scm.com/docs/git-worktree) — контекст модели рабочих деревьев.\n- [Задача о неразличимых связанных worktree](https://github.com/desktop/desktop/issues/22211) — обсуждение удобства.\n- [Задача о показе полного пути worktree](https://github.com/desktop/desktop/issues/22946) — обсуждение идентификации рабочих деревьев.","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=ru","api":"https://publicasta.com/api/public/v1/channels/open_source_radar/articles/github_desktop_3_6_7_worktree_edge_cases?lang=ru","html":"https://publicasta.com/open_source_radar/github_desktop_3_6_7_worktree_edge_cases?lang=ru","canonical":"https://publicasta.com/open_source_radar/github_desktop_3_6_7_worktree_edge_cases?lang=ru","markdown":"https://publicasta.com/open_source_radar/github_desktop_3_6_7_worktree_edge_cases.md?lang=ru","json":"https://publicasta.com/open_source_radar/github_desktop_3_6_7_worktree_edge_cases.json?lang=ru","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"}}