Как восстановить исходное состояние Visual Studio

Обновлено: 05.07.2024

Команда git reset — это сложный и универсальный инструмент для отмены изменений. Он имеет три основные формы вызова. Эти формы соответствуют аргументам командной строки --soft, --mixed, --hard . Каждый из трех аргументов соответствует трем внутренним механизмам управления состоянием Git: дереву коммитов ( HEAD ), промежуточному индексу и рабочему каталогу.

Перезагрузка Git и три дерева Git

Чтобы правильно понять использование git reset, мы должны сначала понять внутренние системы управления состоянием Git. Иногда эти механизмы называют «тремя деревьями» Git. Деревья могут быть неправильным названием, поскольку они не являются строго традиционными древовидными структурами данных. Однако они представляют собой структуры данных на основе узлов и указателей, которые Git использует для отслеживания временной шкалы правок. Лучший способ продемонстрировать эти механизмы — создать набор изменений в репозитории и пройтись по трем деревьям.

Для начала мы создадим новый репозиторий с помощью следующих команд:

Приведенный выше пример кода создает новый репозиторий git с одним пустым файлом reset_lifecycle_file . На данный момент в примере репозитория есть одна фиксация ( d386d86 ) от добавления reset_lifecycle_file .

Рабочий каталог

Первое дерево, которое мы рассмотрим, это "Рабочий каталог". Это дерево синхронизировано с локальной файловой системой и отражает немедленные изменения, внесенные в содержимое файлов и каталогов.

В нашем демонстрационном репозитории мы изменяем и добавляем некоторый контент в файл reset_lifecycle_file. Вызов git status показывает, что Git знает об изменениях в файле. Эти изменения в настоящее время являются частью первого дерева «Рабочий каталог». Статус Git можно использовать для отображения изменений в рабочем каталоге. Они будут отображаться красным цветом с префиксом «изменено».

Промежуточный индекс

Далее идет дерево "Промежуточный индекс". Это дерево отслеживает изменения рабочего каталога, которые были повышены с помощью git add , для сохранения в следующем коммите. Это дерево представляет собой сложный внутренний механизм кэширования. Обычно Git пытается скрыть от пользователя детали реализации промежуточного индекса.

Чтобы точно просмотреть состояние промежуточного индекса, мы должны использовать менее известную команду Git git ls-files . Команда git ls-files по сути представляет собой утилиту отладки для проверки состояния дерева промежуточных индексов.

Здесь мы выполнили git ls-файлы с параметром -s или --stage. Без опции -s вывод git ls-files представляет собой просто список имен файлов и путей, которые в настоящее время являются частью индекса. Параметр -s отображает дополнительные метаданные для файлов в промежуточном индексе. Эти метаданные представляют собой биты режима поэтапного содержимого, имя объекта и номер этапа. Здесь нас интересует имя объекта, второе значение ( d7d77c1b04b5edd5acfc85de0b592449e5303770 ). Это стандартный хэш SHA-1 объекта Git. Это хэш содержимого файлов. В истории коммитов хранятся собственные SHA объектов для идентификации указателей на коммиты и ссылки, а в промежуточном индексе есть собственные SHA объектов для отслеживания версий файлов в индексе.

Далее мы добавим измененный файл reset_lifecycle_file в промежуточный индекс.

Здесь мы вызвали команду git add reset_lifecycle_file, которая добавляет файл в промежуточный индекс. При вызове статуса git теперь reset_lifecycle_file отображается зеленым цветом в разделе «Изменения, которые необходимо зафиксировать». Важно отметить, что статус git не является истинным представлением промежуточного индекса. Выходные данные команды git status отображают изменения между историей фиксации и промежуточным индексом. На этом этапе давайте рассмотрим содержимое промежуточного индекса.

Мы видим, что SHA объекта для reset_lifecycle_file был обновлен с e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 на d7d77c1b04b5edd5acfc85de0b592449e5303770 .

История коммитов

Последнее дерево — это история коммитов. Команда git commit добавляет изменения в постоянный снимок, который хранится в истории коммитов. Этот моментальный снимок также включает состояние промежуточного индекса на момент фиксации.

Здесь мы создали новую фиксацию с сообщением «обновить содержимое файла resetlifecyclefile». Набор изменений добавлен в историю коммитов. Вызов git status в этот момент показывает, что ни в одном из деревьев нет ожидающих изменений. Выполнение git log отобразит историю коммитов. Теперь, когда мы прошли этот набор изменений по трем деревьям, мы можем начать использовать git reset .

Как это работает

На поверхностном уровне git reset похож на git checkout . Там, где git checkout работает исключительно с указателем HEAD ref, git reset будет перемещать указатель HEAD ref и указатель текущей ветки ref. Чтобы лучше продемонстрировать это поведение, рассмотрим следующий пример:

В этом примере показана последовательность коммитов в основной ветке. Ссылка HEAD и ссылка основной ветки в настоящее время указывают на коммит d. Теперь давайте выполним и сравним как git checkout b, так и git reset b.

git checkout b

С git checkout главная ссылка по-прежнему указывает на d . Ссылка HEAD была перемещена и теперь указывает на коммит b. Теперь репозиторий находится в состоянии "отсоединен HEAD".

git reset b

Для сравнения, git reset перемещает как HEAD, так и ссылки на ветки в указанный коммит.

Помимо обновления указателей ссылок фиксации, git reset изменит состояние трех деревьев. Модификация указателя ref всегда происходит и является обновлением третьего дерева, дерева фиксации. Аргументы командной строки --soft, --mixed и --hard указывают, как изменить промежуточный индекс и деревья рабочего каталога.

Основные параметры

Вызов git reset по умолчанию имеет неявные аргументы --mixed и HEAD . Это означает, что выполнение git reset эквивалентно выполнению git reset --mixed HEAD. В этой форме HEAD является указанным коммитом. Вместо HEAD можно использовать любой хэш коммита Git SHA-1.

Это самый прямой, ОПАСНЫЙ и часто используемый вариант. При передаче --hard указатели ссылок истории коммитов обновляются до указанного коммита. Затем промежуточный индекс и рабочий каталог сбрасываются, чтобы соответствовать указанному коммиту. Все ранее отложенные изменения промежуточного индекса и рабочего каталога сбрасываются, чтобы соответствовать состоянию дерева фиксации. Это означает, что любая незавершенная работа, которая находилась в промежуточном индексе и рабочем каталоге, будет потеряна.

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

Эти команды создали новый файл с именем new_file и добавили его в репозиторий. Кроме того, содержимое файла reset_lifecycle_file будет изменено. После внесения этих изменений давайте теперь проверим состояние репозитория с помощью git status .

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

Прежде чем двигаться дальше, давайте также рассмотрим состояние промежуточного индекса:

Мы видим, что файл new_file был добавлен в индекс. Мы внесли обновления в файл reset_lifecycle_file, но SHA промежуточного индекса ( d7d77c1b04b5edd5acfc85de0b592449e5303770 ) остался прежним. Это ожидаемое поведение, поскольку git add не используется для продвижения этих изменений в промежуточный индекс. Эти изменения существуют в рабочем каталоге.

Теперь давайте выполним git reset --hard и проверим новое состояние репозитория.

Здесь мы выполнили "аппаратный сброс" с помощью параметра --hard. Git отображает вывод, указывающий, что HEAD указывает на последнюю фиксацию dc67808. Далее мы проверяем состояние репо с помощью git status. Git указывает, что ожидающих изменений нет. Мы также проверяем состояние промежуточного индекса и видим, что он был сброшен до точки, предшествующей добавлению new_file. Наши модификации reset_lifecycle_file и добавление new_file были уничтожены. Эта потеря данных не может быть восстановлена, это очень важно принять к сведению.

--смешанный

Это режим работы по умолчанию. Указатели ref обновлены. Промежуточный индекс сбрасывается до состояния указанной фиксации. Любые отмененные изменения из промежуточного индекса перемещаются в рабочий каталог. Продолжим.

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

Здесь мы выполнили "смешанный сброс". Повторюсь, --mixed является режимом по умолчанию и имеет тот же эффект, что и выполнение git reset . Изучение выходных данных git status и git ls-files показывает, что промежуточный индекс был сброшен до состояния, в котором reset_lifecycle_file является единственным файлом в индексе. SHA объекта для reset_lifecycle_file был сброшен до предыдущей версии.

Важно отметить, что статус git показывает нам, что в файле reset_lifecycle_file есть изменения и есть неотслеживаемый файл: new_file . Это явное --mixed поведение. Промежуточный индекс был сброшен, а ожидающие изменения перемещены в рабочий каталог. Сравните это со случаем --hard reset, когда был сброшен промежуточный индекс и рабочий каталог, что привело к потере этих обновлений.

При передаче аргумента --soft указатели ref обновляются, и сброс на этом останавливается. Промежуточный индекс и рабочий каталог остаются нетронутыми. Такое поведение может быть трудно четко продемонстрировать. Давайте продолжим работу с нашим демонстрационным репозиторием и подготовим его к мягкому сбросу.

Здесь мы снова использовали git add для продвижения измененного файла reset_lifecycle_file в промежуточный индекс. Мы подтверждаем, что индекс был обновлен выводом git ls-files. Вывод из состояния git теперь отображает «Изменения, которые необходимо зафиксировать» зеленым цветом. Файл new_file из наших предыдущих примеров плавает в рабочем каталоге как неотслеживаемый файл. Давайте быстро выполним rm new_file, чтобы удалить файл, так как он нам не понадобится для следующих примеров.

С репозиторием в этом состоянии мы теперь выполняем программный сброс.

Мы выполнили «программный сброс». Изучение состояния репо с помощью git status и git ls-files показывает, что ничего не изменилось. Это ожидаемое поведение. Мягкий сброс сбрасывает только историю коммитов. По умолчанию git reset вызывается с HEAD в качестве целевого коммита. Поскольку наша история коммитов уже находилась в HEAD, и мы неявно сбросили ее в HEAD, на самом деле ничего не произошло.

Чтобы лучше понять и использовать --soft, нам нужна целевая фиксация, отличная от HEAD . У нас есть файл reset_lifecycle_file, ожидающий в промежуточном индексе. Давайте создадим новый коммит.

На данный момент в нашем репозитории должно быть три коммита. Мы вернемся во времени к первому коммиту. Для этого нам понадобится идентификатор первого коммита. Это можно узнать, просмотрев вывод журнала git .

Имейте в виду, что идентификатор истории фиксации будет уникальным для каждой системы. Это означает, что идентификатор фиксации в этом примере будет отличаться от того, что вы видите на своем персональном компьютере. Идентификатор коммита, который нас интересует для этого примера, — 780411da3b47117270c0e3a8d5dcfd11d28d04a4. Это идентификатор, который соответствует «начальной фиксации». Как только мы найдем этот идентификатор, мы будем использовать его в качестве цели для нашего мягкого сброса.

Прежде чем отправиться в прошлое, давайте сначала проверим текущее состояние репозитория.

Здесь мы выполняем комбинированную команду git status и git ls-files -s, это показывает нам, что есть ожидающие изменения в репозитории, а reset_lifecycle_file в промежуточном индексе имеет версию 67cc52710639e5da6b515416fd779d0741e3762e . Имея это в виду, давайте выполним мягкий сброс до нашего первого коммита.

Приведенный выше код выполняет «программный сброс», а также вызывает комбинированную команду git status и git ls-files, которая выводит состояние репозитория. Мы можем изучить вывод состояния репо и отметить некоторые интересные наблюдения. Во-первых, статус git указывает на наличие изменений в файле reset_lifecycle_file и выделяет их, указывая на то, что они подготовлены для следующей фиксации. Во-вторых, ввод git ls-files показывает, что промежуточный индекс не изменился и сохраняет SHA 67cc52710639e5da6b515416fd779d0741e3762e, который мы использовали ранее.

Чтобы уточнить, что произошло при этом сбросе, давайте изучим журнал git:

Вывод журнала теперь показывает, что в истории коммитов есть одна фиксация. Это помогает ясно проиллюстрировать, что сделал --soft. Как и при всех вызовах git reset, первое действие, которое нужно выполнить, — это сбросить дерево коммитов. Наши предыдущие примеры с --hard и --mixed были против HEAD и не переместили дерево коммитов назад во времени. Это все, что происходит во время мягкого сброса.

Тогда это может сбивать с толку, почему статус git указывает на наличие измененных файлов. --soft не затрагивает промежуточный индекс, поэтому обновления нашего промежуточного индекса следовали за нами в прошлое через историю коммитов. Это может быть подтверждено выводом git ls-files -s, показывающим, что SHA для reset_lifecycle_file не изменился. Напоминаем, что статус git не показывает состояние «трех деревьев», он, по сути, показывает разницу между ними. В этом случае отображается, что промежуточный индекс опережает изменения в истории коммитов, как будто мы уже их промежуточно разместили.

Сброс и возврат

Если git revert — это «безопасный» способ отмены изменений, вы можете считать git reset опасным методом. Есть реальный риск потерять работу с git reset. Git reset никогда не удалит коммит, однако коммиты могут стать «осиротевшими», что означает, что нет прямого пути от ссылки для доступа к ним. Эти потерянные коммиты обычно можно найти и восстановить с помощью git reflog. Git безвозвратно удалит любые потерянные коммиты после запуска внутреннего сборщика мусора. По умолчанию Git настроен на запуск сборщика мусора каждые 30 дней. История коммитов — это одно из «трех деревьев git», два других, промежуточный индекс и рабочий каталог, не так постоянны, как коммиты. При использовании этого инструмента следует соблюдать осторожность, так как это одна из немногих команд Git, которые могут привести к потере результатов вашей работы.

В то время как откат предназначен для безопасной отмены общедоступной фиксации, git reset предназначен для отмены локальных изменений в промежуточном индексе и рабочем каталоге.Из-за разных целей эти две команды реализованы по-разному: при сбросе полностью удаляется набор изменений, а при возврате сохраняется исходный набор изменений и используется новая фиксация для применения отмены.

Не сбрасывать общедоступную историю

Вы никогда не должны использовать git reset, если какие-либо моментальные снимки были отправлены в общедоступный репозиторий. После публикации коммита вы должны исходить из того, что другие разработчики полагаются на него.

Удаление фиксации, которую продолжают разрабатывать другие члены команды, создает серьезные проблемы для совместной работы. Когда они попытаются синхронизироваться с вашим репозиторием, это будет выглядеть так, будто часть истории проекта внезапно исчезла. Последовательность ниже демонстрирует, что происходит, когда вы пытаетесь сбросить общедоступную фиксацию. Исходная/основная ветка — это версия вашей локальной основной ветки в центральном репозитории.

Как только вы добавите новые коммиты после сброса, Git подумает, что ваша локальная история отличается от origin/main , и коммит слияния, необходимый для синхронизации ваших репозиториев, может запутать и расстроить вашу команду.

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

Примеры

Удалить указанный файл из промежуточной области, но оставить рабочий каталог без изменений. Это удаляет файл без перезаписи каких-либо изменений.

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

Сбросьте промежуточную область и рабочий каталог, чтобы они соответствовали самой последней фиксации. В дополнение к неустановленным изменениям флаг --hard указывает Git также перезаписывать все изменения в рабочем каталоге. Другими словами: это стирает все незафиксированные изменения, поэтому убедитесь, что вы действительно хотите выбросить свои локальные разработки, прежде чем использовать его.

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

Переместите текущую ветку назад и сбросьте промежуточную область и рабочий каталог, чтобы они совпадали. Это стирает не только незафиксированные изменения, но и все последующие фиксации.

Отключение файла

Команда git reset часто используется при подготовке промежуточного снимка. В следующем примере предполагается, что у вас есть два файла с именами hello.py и main.py, которые вы уже добавили в репозиторий.

Как видите, git reset помогает сосредоточить внимание на коммитах, позволяя отменить изменения, не связанные со следующим коммитом.

Удаление локальных коммитов

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

Команда git reset HEAD~2 перемещает текущую ветку назад на две фиксации, эффективно удаляя два только что созданных снимка из истории проекта. Помните, что этот вид сброса следует использовать только для неопубликованных коммитов. Никогда не выполняйте описанную выше операцию, если вы уже отправили свои коммиты в общий репозиторий.

Обзор

Напомним, что git reset — это мощная команда, которая используется для отмены локальных изменений состояния репозитория Git. Сброс Git работает на «Трех деревьях Git». Этими деревьями являются история фиксации ( HEAD ), промежуточный индекс и рабочий каталог. Есть три параметра командной строки, соответствующие трем деревьям. Параметры --soft, --mixed и --hard можно передать в git reset .

В этой статье мы использовали несколько других команд Git, чтобы продемонстрировать процессы сброса. Узнайте больше об этих командах на их отдельных страницах: git status, git log, git add, git checkout, git reflog и git revert .

Этот форум перенесен в раздел вопросов и ответов Майкрософт. Посетите Microsoft Q&A, чтобы публиковать новые вопросы.

Вопрос:

Вопрос

Я изменил множество настроек в своей версии Visual Studio. Я попытался переустановить, восстановить и сбросить свои настройки в Tools-> Import Export Settings Visual Studio 2017, и у него все еще есть мои настройки. Примером может служить темная тема или заглавные буквы вверху. Я предполагаю, что мои настройки не были полностью перезаписаны и сброшены.Хотя я помню, что когда я переустанавливал Visual Studio и открывал его в первый раз, он показывал настройки Visual Studio по умолчанию (белая тема, нет последних файлов, все чисто), но через 3-4 секунды все вернулось, как было до переустановки Visual Studio (темная тема, полный список последних файлов и т. д.). Есть ли способ сбросить все настройки?

Все ответы

Добро пожаловать на форум MSDN.

Согласно вашему описанию, вы хотите очистить недавний проект и восстановить цветовую тему, верно?

После выполнения команды «Сбросить все настройки» (нажмите «Инструменты» -> «Настройки импорта и экспорта…»), цветовая тема и недавний проект не были затронуты. Насколько я понимаю, «Сбросить все настройки» сбрасывает все настройки среды из набора настроек по умолчанию, возможно, цветовая тема и последний проект не включены в набор настроек по умолчанию. Значит, это не возврат.

Чтобы изменить цветовую тему вручную.

Для последнего проекта нажмите Пуск->Командная строка разработчика для VS-> введите «devenv.exe /Resetuserdata», очистите данные пользователя.

Кроме того, вы можете установить расширение «Очистить недавние», нажав «Файл» -> «Последние проекты и решения» -> «Очистить все», очистить последний проект.

Кроме того, если вы хотите сообщить об этой проблеме, вы можете опубликовать отзыв по следующей ссылке:

У меня был установлен подключаемый модуль в Visual Studio 2008, и он создал несколько дополнительных закрепляемых окон. Я удалил его, и я не могу избавиться от созданных им окон - я закрываю их, но они всегда возвращаются. Теперь это просто пустые окна, так как плагина больше нет, но я ничего не пробовал, чтобы избавиться от них. Я пробовал:

Окно -> Сбросить макет окна
Удаление файлов .suo в каталогах моего проекта
Удаление папки Visual Studio 9.0 в моем каталоге настроек приложения

12 ответов 12

Вы пробовали это? В Visual Studio выберите Инструменты > Настройки импорта и экспорта > Сбросить все настройки

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

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

Ребята, бэкап настроек работает на 100%. Только небольшая проблема: вам нужно выбрать «все файлы», когда вы визуализируете список резервных копий настроек. И скрытые файлы должны быть видны. ДА, сохраненные настройки скрыты. Это в VS2010.

После резервного копирования и сброса импортируйте те же настройки, которые вы только что заархивировали, но снимите флажок «Макеты окон» (в «Общих настройках») из материалов для импорта. Отлично сработало для меня

Чтобы вернуть сочетания клавиш Resharper после описанной выше операции (VS2015): Resharper -> Параметры -> Клавиатуры и меню -> Сочетания клавиш -> Применить схему

Попробуйте devenv.exe /resetuserdata. Я думаю, что это более агрессивно, чем предлагаемые параметры «Инструменты»> «Импорт и экспорт».

Также выберите "Инструменты" > "Диспетчер надстроек" и убедитесь, что там нет сирот.

Спасатель! /resetuserdata у меня сработало. У меня были проблемы с очень медленным запуском, медленным отображением диалогового окна «Добавить -> Новый элемент», сбоем при открытии решений MVC2.

Как насчет запуска следующего из командной строки,

Вы также можете сохранить эти настройки в файле, например,

Переключатель /ResetSettings восстанавливает настройки Visual Studio по умолчанию. При необходимости сбрасывает настройки в указанный файл .vssettings.

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

Windows -> Rest Windows Layout, исправил это для меня без проблем. Это дает настройку по умолчанию, на которую я совсем не возражаю :)

У меня тоже возникла эта проблема, но в сети об этом ничего не было. Зашел сюда в поисках другой проблемы и нашел эту - спасибо!

Если у вас есть старая резервная копия CurrentSettings.vssettings, попробуйте восстановить ее.

У меня был полностью поврежден макет Visual Studio. Когда я попытался войти в отладку, мне сказали, что VS стал нестабильным. Когда я перезапустился, мой макет окна был бы полностью испорчен. Я попытался восстановить текущие пользовательские настройки VS в реестре из резервной копии, но это не помогло.Однако восстановление CurrentSettings.vssettings, похоже, помогло.

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

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

VS Code предоставляет две разные области для настроек:

Пользовательские настройки — настройки, которые применяются глобально ко всем открытым вами экземплярам VS Code.
Настройки рабочей области. Настройки хранятся в вашей рабочей области и применяются только при открытии рабочей области.

В этой статье мы сначала опишем пользовательские настройки, так как это ваши личные настройки для настройки VS Code. Позже мы рассмотрим настройки рабочей области, которые будут специфичны для проекта, над которым вы работаете.

Редактор настроек

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

Чтобы открыть редактор настроек, используйте следующую команду меню VS Code:

Вы также можете открыть редактор настроек из палитры команд ( ⇧⌘P (Windows, Linux Ctrl+Shift+P )) с настройками: открыть настройки или использовать сочетание клавиш ( ⌘, (Windows, Linux Ctrl+, ) ) .

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

В приведенном ниже примере расположение боковой панели и тема значка файла были изменены.

Изменения в настройках перезагружаются VS Code по мере их изменения. Измененные настройки обозначаются синей линией, похожей на измененные строки в редакторе.

Значок шестеренки (Дополнительные действия. ⇧F9 (Windows, Linux Shift+F9)) открывает контекстное меню с параметрами для сброса параметра до значения по умолчанию, а также для копирования идентификатора параметра или пары "имя-значение" в формате JSON.< /p>

Изменить настройки

Каждый параметр можно изменить с помощью флажка, поля ввода или раскрывающегося списка. Отредактируйте текст или выберите параметр, который вы хотите изменить на нужные настройки.

Группы настроек

Настройки представлены в группах, чтобы вы могли легко перемещаться по ним. В верхней части есть группа «Часто используемые», в которой показаны популярные настройки.

Под настройками управления версиями (SCM) можно сфокусироваться, выбрав SCM в представлении в виде дерева.

Примечание. Расширения VS Code также могут добавлять свои собственные настройки, и они будут отображаться в разделе «Расширения».

Изменение настройки

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

Откройте редактор настроек ( kb((workbench.action.openSettings)) и введите «активность» в строке поиска. Вы должны увидеть пять настроек.

Вы можете дополнительно ограничить область действия только теми настройками, которые находятся в группе «Внешний вид» в дереве слева. Не должно быть только трех настроек.

Теперь вы можете установить или снять флажок Workbench > Панель активности: видимый, чтобы скрыть или показать панель активности. Обратите внимание, что если вы изменили настройку по умолчанию, вы увидите синюю линию слева.

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

Фильтры редактора настроек

В строке поиска редактора настроек есть несколько фильтров, упрощающих управление настройками.

Измененные настройки

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

Другие фильтры

Есть еще несколько удобных фильтров для поиска настроек.

Вот некоторые из доступных фильтров:

Панель поиска запоминает ваши настройки поисковых запросов и поддерживает отмену/возврат ( ⌘Z (Windows, Linux Ctrl+Z ) / ⇧⌘Z (Windows, Linux Ctrl+Y ) ). Вы можете быстро очистить поисковый запрос или фильтр с помощью кнопки «Очистить параметры поиска» справа от панели поиска.

Настройки расширения

Установленные расширения VS Code также могут иметь собственные настройки, которые можно просмотреть в разделе "Расширения" редактора настроек.

Вы также можете просмотреть настройки расширения в представлении «Расширения» ( ⇧⌘X (Windows, Linux Ctrl+Shift+X ) ), выбрав расширение и просмотрев вкладку Feature Contributions.

Авторы расширений могут узнать больше о добавлении пользовательских настроек в документации по настройке.

settings.json

Редактор настроек — это пользовательский интерфейс, который позволяет просматривать и изменять значения настроек, сохраненные в файле settings.json. Вы можете просмотреть и отредактировать этот файл напрямую, открыв его в редакторе с помощью команды Preferences: Open Settings (JSON). Параметры записываются в формате JSON путем указания идентификатора и значения параметра.

Файл settings.json содержит полный набор функций IntelliSense с интеллектуальными дополнениями для настроек и значений, а также при наведении курсора на описание. Также выделяются ошибки из-за неверных названий параметров или форматирования JSON.

Некоторые настройки можно редактировать только в settings.json, например Workbench: настройки цвета, и отображать ссылку «Изменить в settings.json» в редакторе настроек.

Удалите блок кода настройки workbench.colorCustomizations, чтобы вернуть цвет номера строки по умолчанию.

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

Если вы предпочитаете всегда работать напрямую с settings.json , вы можете установить "workbench.settings.editor": "json", чтобы Файл > Настройки > Настройки и привязка клавиш ⌘ (Windows, Linux Ctrl+, ) всегда открывались файл settings.json, а не пользовательский интерфейс редактора настроек.

Расположение файла настроек

Windows %APPDATA%\Code\User\settings.json
macOS $HOME/Library/Application\ Support/Code/User/settings.json
Linux $HOME/.config/Code/User/settings.json

Сбросить все настройки

Хотя вы можете сбросить настройки по отдельности с помощью команды «Сбросить настройки» редактора настроек, вы можете сбросить все измененные настройки, открыв файл settings.json и удалив записи между фигурными скобками <> . Будьте осторожны, так как восстановить предыдущие значения настроек будет невозможно.

Настройки рабочего пространства

Настройки рабочей области зависят от проекта и могут быть общими для всех разработчиков проекта. Настройки рабочей области имеют приоритет над настройками пользователя.

Примечание. «Рабочее пространство» VS Code обычно представляет собой корневую папку вашего проекта. Параметры рабочей области, а также конфигурации отладки и задач хранятся в корневом каталоге в папке .vscode. Вы также можете иметь более одной корневой папки в рабочей области VS Code с помощью функции, называемой многокорневыми рабочими областями. Вы можете узнать больше в разделе Что такое «рабочая область» VS Code? статья.

Редактировать можно с помощью вкладки "Рабочее пространство" редактора настроек или открыть эту вкладку непосредственно с помощью команды "Настройки: Открыть настройки рабочего пространства".

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

Расположение рабочей области settings.json

Подобно пользовательским настройкам, настройки рабочей области также хранятся в файле settings.json, который можно редактировать непосредственно с помощью команды «Настройки: Открыть настройки рабочей области (JSON)».

Файл настроек рабочей области находится в папке .vscode в корневой папке.

Примечание. В случае многокорневой рабочей области настройки рабочей области находятся в файле конфигурации рабочей области.

Когда вы добавляете файл settings.json настроек рабочей области в свой проект или систему управления версиями, настройки по умолчанию для проекта будут общими для всех пользователей этого проекта

Примечание. Вы не можете использовать редактор настроек для создания параметра рабочей области, который соответствует значению параметра по умолчанию. Если вы хотите, чтобы ваша рабочая область принудительно задавала для определенного параметра значение по умолчанию, даже если кто-то настроил этот параметр как пользовательский, вы должны добавить его в файл settings.json рабочей области вручную.

Настройки редактора для конкретного языка

Вы также можете настроить свой редактор по языку программирования, что может быть полезно, когда языковые соглашения различаются. Чтобы изменить настройки языка, запустите глобальную команду Preferences: Configure Language Specific Settings (идентификатор команды: workbench.action.configureLanguageBasedSettings) из палитры команд ( ⇧⌘P (Windows, Linux Ctrl+Shift+P)), которая открывает выбор языка. Выберите нужный язык, после чего откроется ваш пользовательский файл settings.json с записью языка, где вы можете добавить применимые настройки.

Выберите язык в раскрывающемся списке:

Добавьте языковые настройки в свои пользовательские настройки:

Если у вас открыт файл и вы хотите настроить редактор для этого типа файла, выберите языковой режим в строке состояния в правом нижнем углу окна VS Code. Откроется окно выбора языкового режима с параметром «Настроить языковые настройки 'language_name». При выборе этого параметра открывается ваш пользовательский файл settings.json с записью языка, где вы можете добавить применимые настройки.

Настройки редактора для конкретного языка в ваших пользовательских настройках переопределяют настройки рабочей области.

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

Следующие примеры настраивают параметры редактора для языковых режимов typescript и markdown .

Вы можете использовать IntelliSense в settings.json, чтобы найти разрешенные языковые настройки.Поддерживаются все настройки редактора и некоторые настройки, не относящиеся к редактору. Для некоторых языков уже заданы настройки по умолчанию для конкретного языка, которые можно просмотреть в файле defaultSettings.json, открытом с помощью команды «Настройки: Открыть настройки по умолчанию».

Приоритет настроек

Конфигурации могут быть переопределены на нескольких уровнях с помощью различных областей настройки:

Пользовательские настройки: применяются глобально ко всем экземплярам VS Code.
Настройка рабочей области — применяется к открытой папке или рабочей области и переопределяет настройки пользователя.
Настройки папки рабочей области — применяются к определенной папке многокорневой рабочей области. Переопределить настройки пользователя и рабочей области.
Настройки редактора для конкретного языка — переопределить настройки рабочей области.

Значения параметров могут быть разных типов:

Строка — "files.autoSave": "afterDelay"
Логическое значение – "editor.minimap.enabled": true
Число – "files.autoSaveDelay": 1000
Массив — "editor.rulers": []
Объект – "search.exclude": < "**/node_modules": true, "**/bower_components": true >

Значения примитивных типов и типа Array переопределяются, а значения типа Object объединяются. Например, workbench.colorCustomizations принимает объект, который указывает группу элементов пользовательского интерфейса и их желаемые цвета.

Если в настройках пользователя для фона редактора выбран синий и зеленый:

А в настройках вашего открытого рабочего пространства передний план редактора становится красным:

Результатом, когда это рабочее пространство открыто, является комбинация этих двух настроек цвета, как если бы вы указали:

При наличии конфликтующих значений, таких как editor.selectionBackground в приведенном выше примере, происходит обычное поведение переопределения, при котором значения рабочей области имеют приоритет над пользовательскими значениями.

Настройки и безопасность

Некоторые настройки позволяют указать исполняемый файл, который VS Code будет запускать для выполнения определенных операций. Например, вы можете выбрать, какую оболочку должен использовать интегрированный терминал. В целях повышения безопасности такие параметры можно задать только в параметрах пользователя, а не в области рабочей области.

Вот список настроек, не поддерживаемых в настройках рабочей области:

git.path
терминал.внешний.windowsExec
терминал.внешний.osxExec
терминал.внешний.linuxExec

При первом открытии рабочей области, в которой определены какие-либо из этих параметров, VS Code выдает предупреждение, а затем всегда игнорирует значения после этого.

Синхронизация настроек

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

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

Частые вопросы

VS Code сообщает "Невозможно записать настройки".

Если вы пытаетесь изменить настройку (например, включить автосохранение или выбрать новую цветовую тему) и видите сообщение «Невозможно записать в пользовательские настройки. Откройте пользовательские настройки, чтобы исправить ошибки/предупреждения в них, и повторите попытку. ", это означает, что ваш файл settings.json имеет неправильный формат или содержит ошибки. Ошибка может быть такой простой, как отсутствие запятой или неправильное значение параметра. Откройте файл settings.json с помощью команды Preferences: Open Settings (JSON). Вы должны увидеть ошибку, выделенную красными волнистыми линиями.

Как сбросить настройки пользователя?

Самый простой способ сбросить настройки VS Code до значений по умолчанию — очистить файл user settings.json. Вы можете открыть файл settings.json с помощью команды Preferences: Open Settings (JSON) в палитре команд ( ⇧⌘P (Windows, Linux Ctrl+Shift+P )). Когда файл будет открыт в редакторе, удалите все, что находится между двумя фигурными скобками <> , сохраните файл, и VS Code вернется к использованию значений по умолчанию.

Когда имеет смысл использовать настройки рабочей области?

Если вы используете рабочее пространство, для которого нужны пользовательские настройки, но вы не хотите применять их к другим проектам VS Code. Хорошим примером являются правила линтинга для конкретного языка.

Читайте также: