Как просматривать проблемы GitHub из Visual Studio 2022?

К сожалению, представление «Рабочие элементы» и интеграция связанных проблем с репозиториями GitHub в настоящее время недоступны в Visual Studio 2022 из коробки.

Возможно, вы сможете найти расширение Visual Studio, предоставляющее эту функциональность, но я не знаю ни одного из них.

Альтернативным вариантом может быть использование GitHub API для получения проблем и создание пользовательского расширения для отображения проблем в Visual Studio 2022. Однако это потребует специальной разработки с вашей стороны.

«Старый» командный обозреватель делал ряд действительно хороших вещей, но его также было очень сложно интегрировать для других поставщиков инструментов. С новым интерфейсом Git команда Visual Studio выбрала более независимый подход.

Старый Team Explorer был написан на .NET 4 и в значительной степени ориентирован на интеграцию с Azure DevOps. Это связано с 2005 годом, когда впервые был выпущен Team Foundation Server. Со временем другие поставщики проникли в Team Explorer, но в основном недокументированными и неподдерживаемыми путями. Это вызвало много интересных проблем в прошлом. Концепция окна Team Explorer также не была идеальной для размещения GitHub, Azure DevOps, BitBucket и любых других поставщиков инструментов, которые хотели быть перечислены, и у пользователей было очень мало контроля над установкой порядка элементов или скрыть определенные плитки. Таким образом, это рассадник ошибок, и его необходимо было перенести на .NET Core и x64, а также обеспечить поддержку внепроцессного расширения для правильной поддержки Visual Studio 2022 в любом случае.

Поэтому Team Explorer и его старые недокументированные точки расширения были отброшены, и появилось новое Git Window. Это окно является чистым клиентом git и не зависит от поставщика. Поставщики могут добавлять элементы меню в меню верхнего уровня, но в настоящее время они не могут расширять новое окно git.

В то же время Visual Studio 2022 отказалась от поддержки встроенного окна браузера, которое потребляло много памяти, загружало IE11, а также требовало полного переоснащения для поддержки внепроцессной загрузки x64, которую теперь требует Visual Studio 2022.

Вся эта работа теперь позволяет Visual Studio использовать больше памяти, она работает быстрее, а перемещение расширений вне процесса значительно повысило производительность и стабильность платформы Visual Studio. К сожалению, все это произошло за счет некоторых функций.

Новый интерфейс git больше не ограничен окном Team Explorer, он является гражданином высшего уровня в Visual Studio и, наконец, может использовать более простые для запоминания сочетания клавиш. Это также намного быстрее, и новая архитектура позволила команде создать интерактивную перебазировку, поддержку нескольких репозиториев, поддержку подмодулей и многое другое. Но их приоритеты долгое время были в расширенных сценариях git, а не в создании поддержки для интеграции проблем конкретного поставщика. Хотя похоже, что это может измениться. Автозаполнение #... теперь доступно в предварительной версии Visual Studio 17.5:

Некоторые поставщики инструментов могут инвестировать средства в встроенную интеграцию с Visual Studio в будущем. Многие старые расширения больше не доступны в VS2022 или авторы все еще работают над новой версией, соответствующей новым требованиям.

С другой стороны, у вас есть VS Code, который используется самим GitHub для внутренних целей, работает в браузере, поддерживает кодовые пространства github.dev и github и не несет в себе наследие Visual Studio 2022. Это не Microsoft. , но GitHub, который расширил vscode и добавил поддержку своей платформы через расширения и вклад с открытым исходным кодом напрямую в редактор. GitHub имеет другую долю в vscode, у них есть инженерный персонал, который знает, как расширять приложения на основе атома (они в основном создали эту технологию), поэтому их функции были добавлены в vscode.

Это справедливо? Хотим ли мы этого и в большом VS? Конечно, но, к сожалению, в настоящее время деньги тратятся не на это.

Есть несколько способов добиться желаемого. Но ни один из них не является именно тем, что вы хотите.

Паутина

Основной способ — начать работу из браузера. В каждой проблеме есть раздел «Разработка», из которого вы можете создать ветку или инициировать запрос на извлечение из связанной ветки:

Затем вы можете сразу же проверить это локально

Или перейдите на панель кода для ветки и щелкните ссылку «Открыть в Visual Studio». Это запустит визуальную студию в правильном контексте, используя выбранный вами репозиторий, и проверит ветку локально, чтобы вы могли начать работу.

Любые коммиты, которые вы делаете в этой ветке, автоматически связываются с проблемой, поэтому нет необходимости каждый раз передавать #issuenumber.

Кли

Альтернативой работе из браузера является использование интерфейса командной строки. Если у вас установлен GitHub CLI, он подберет контекст вашего репо из списка удаленных устройств, и вы сможете выполнять быстрые команды прямо из встроенного терминала Visual Studio.

gh pr create

Создать новый PR.

gh issue list

Чтобы быстро перечислить открытые вопросы

gh issue develop #issuenumber

Чтобы создать ветку на удаленном компьютере, свяжите ее со своей проблемой и извлеките ветку локально.

Требуется некоторое время, чтобы привыкнуть к командам, но если вам нравится интерфейс командной строки, это быстрый способ работы.

В Visual Studio

Вы можете создавать запросы на вытягивание из своего текущего состояния, которые затем перенаправят вас в браузер с большей частью предварительно заполненных данных. С этого момента автозаполнение задач также работает в браузере.

Чтобы получить другие функции, которые вы хотите, вы должны установить расширения. К сожалению, GitHub прекратил разработку старого расширения GitHub для Visual Studio, поскольку большинство его функций теперь перенесено в Visual Studio. Нелегко создавать и поддерживать расширение для нескольких версий Visual Studio, поэтому я не ожидаю, что это вернется к жизни.

Я полагаюсь на расширение Git Web links для быстрого переключения между веб- и визуальной студией из контекста моих рабочих файлов:

В настройках вы можете установить поведение по умолчанию, чтобы не копировать, а открывать в браузере.

Другие функции, которые вам нужны, в настоящее время недоступны через общедоступное расширение. Большинство из этих функций также были удалены или объявлены устаревшими для самой Azure DevOps, поэтому я не ожидаю, что команда Visual Studio будет спешить с первоклассной поддержкой отслеживания проблем.

Похоже, что VS2022 будет иметь эту функцию в будущем (сейчас она находится в предварительной версии).

Https://thewikihow.com/video_0NiHvdoMBO8?t=95 [Предварительный просмотр VS2022]