GitHub Codespaces — это современная облачная среда разработки, которая использует контейнер для предоставления популярных языков, инструментов и служебных программ для разработки. GitHub Codespaces также настраивается, что позволяет создавать настраиваемую среду разработки для проекта. Настроив пользовательскую среду разработки для проекта, вы получите воспроизводимую конфигурацию кодового пространства для всех пользователей проекта.
Создание кодового пространства
Кодовое пространство можно создавать в нескольких точках входа:
- Из шаблона GitHub или любого репозитория шаблонов на GitHub для запуска нового проекта
- Ветвь в репозитории для новой функции
- Из открытого запроса на вытягивание для изучения хода выполнения работы
- Из фиксации в журнале репозитория для изучения ошибки в определенный момент времени
Пространство кода можно создать на GitHub, в Visual Studio Codeили с помощью GitHub CLI.
Кодовое пространство может быть временным, если вам нужно протестировать что-то или вернуться в то же кодовое пространство для выполнения более долгосрочных задач.
Дополнительные сведения см. в разделе[ "AUTOTITLE", "Создание пространства кода для репозитория" и "Открытие существующего пространства кода](/codespaces/developing-in-a-codespace/creating-a-codespace-from-a-template)".
Примечание. Вы можете создать несколько пространств кода для каждого репозитория или даже для каждой ветви. Однако количество создаваемых сред codespace ограничено, как и количество одновременно выполняемых сред codespace. Если вы достигнете максимального количества сред codespace и попытаетесь создать еще одну среду, появится сообщение о том, что необходимо удалить существующую среду codespace, прежде чем создать новую.
Процесс создания пространства кода
При создании пространства кода различные шаги выполняются в фоновом режиме, прежде чем пространство кода будет доступно для вас.
Шаг 1. Кодовому пространству назначаются виртуальная машина и хранилище
При создании пространства кода виртуальная машина создается с помощью стабильного или public preview образа узла виртуальной машины. Дополнительные сведения см. в разделе Выбор стабильного или бета-образа узла. Образ узла определяет версию Linux, используемую для виртуальной машины. Виртуальная машина является выделенной и частной. Выделение виртуальной машины обеспечит вам полный набор вычислительных ресурсов, доступных на этом компьютере. При необходимости это также позволит вам получить полный корневой доступ к контейнеру.
Затем неглубокий клон создается из репозитория или из репозитория шаблонов, если вы создаете пространство кода из шаблона. Это клонируется в /workspaces каталог виртуальной машины и впоследствии подключается к контейнеру разработки. Дополнительные сведения см. в разделе "Сведения о структуре каталога пространства кода" ниже.
Шаг 2. Создание контейнера разработки
GitHub Codespaces использует контейнер Docker в качестве среды разработки. Этот контейнер создается на основе конфигураций, которые можно определить в devcontainer.json файле и, при необходимости, Dockerfile. Если вы создаете пространство кода из пустого шаблона GitHubили из репозитория devcontainer.json без файла, GitHub Codespaces использует образ по умолчанию, который имеет множество языков и сред выполнения. Дополнительные сведения см. в разделе Основные сведения о контейнерах разработки. Дополнительные сведения о том, что включает образ по умолчанию для контейнеров разработки, см. в репозитории devcontainers/images .
Примечание. Если вы хотите использовать перехватчики Git в кодовом пространстве и применить что-то из каталога шаблонов Git к своему кодовому пространству, перехватчики необходимо настроить при выполнении шага 4 после того, как будет создан контейнер.
Поскольку репозиторий клонируется на виртуальную машину узла до создания контейнера, никакое содержимое каталога шаблонов Git не будет применяться в вашем кодовом пространстве, пока вы не настроите перехватчики в файле конфигурации devcontainer.json с помощью postCreateCommand в шаге 4. Дополнительные сведения см. в разделе Шаг 4. Настройка после создания.
Шаг 3. Подключение к кодовому пространству
После создания контейнера и выполнения любой другой инициализации вы будете подключены к своему кодовому пространству. Вы можете подключиться к нему с помощью:
Шаг 4. Настройка после создания
После подключения к пространству кода автоматическая настройка может продолжить сборку на основе конфигурации, указанной в devcontainer.json файле. Могут быть выполнены команды postCreateCommand и postAttachCommand.
Если вы хотите использовать перехватчики Git в пространстве кода, настройте перехватчики с помощью devcontainer.json скриптов жизненного цикла, например postCreateCommand. Сведения о скриптах жизненного цикла см . в спецификации контейнеров разработки на веб-сайте "Контейнеры разработки".
Если у вас есть общедоступный репозиторий файлов с точкой для GitHub Codespaces, его можно включить для использования с новыми кодовыми пространствами. Если он включен, файлы с точкой будут клонированы в контейнер и будет вызван скрипт установки. Дополнительные сведения см. в разделе Персонализация GitHub Codespaces для вашей учетной записи.
Наконец, если вы создали пространство кода из репозитория, весь журнал репозитория копируется с полным клоном. Если вы создали пространство кода из шаблона, полная история репозитория шаблонов не сохраняется; Вместо этого, если вы не используете пустой шаблон, вы начнете с первоначальной фиксации для содержимого репозитория шаблонов.
В процессе настройки после создания можно использовать интегрированный терминал и вносить изменения в файлы, но нужно стараться избегать любых конфликтов между работой и выполняемыми командами.
Жизненный цикл Codespaces
Сохранение файлов в кодовом пространстве
Сохраните изменения в файлах обычным образом в зависимости от используемого редактора.
Если вы работаете с пространствами кода в Visual Studio Code, вы можете включить автоматическое сохранение , чтобы убедиться, что изменения всегда сохраняются.
Закрытие или остановка кодового пространства
Пространство кода будет продолжать работать во время его использования, но будет истекать после периода бездействия. Изменения в файлах редактора и выходных данных терминала считаются действием, поэтому пространство кода не будет истекает, если выходные данные терминала продолжаются. Период времени ожидания бездействия по умолчанию составляет 30 минут. Вы можете определить свой личный параметр времени ожидания для создаваемых пространств кода, но это может быть переопределено политикой времени ожидания организации. Дополнительные сведения см. в разделе Настройка периода ожидания для GitHub Codespaces.
Если время ожидания пространства кода перестанет работать, но его можно перезапустить на вкладке браузера (если вы использовали пространство кода в браузере), из VS Codeили из списка пространств кода.https://github.com/codespaces
Чтобы остановить пространство кода, можно
- В браузере: в списке пространств https://github.com/codespacesкода щелкните многоточие (...) справа от пространства кода, которое вы хотите остановить, и нажмите кнопку "Остановить пространство кода".
- В VS Code: откройте Visual Studio Code Command Palette — например, нажав клавиши CTRL+SHIFT+P (Windows/Linux) или SHIFT+COMMAND+P (Mac) — введите клавишу
Codespaces: stopВВОД. Дополнительные сведения см. в разделе Использование палитры команд Visual Studio Code в GitHub Codespaces. - В клиенте JetBrains нажмите кнопку остановки в верхней части окна инструментов GitHub Codespaces . Дополнительные сведения см. на вкладке "IdEs JetBrains" элементаОстановка и запуск пространства кода.
- В окне терминала: используйте команду
gh codespace stopGitHub CLI . Дополнительные сведения см. в разделе Использование GitHub Codespaces с GitHub CLI.
Если вы выходите из пространства кода без выполнения команды остановки (например, закрыв вкладку браузера), или если пространство кода не выполняется без взаимодействия, пространство кода и его выполняемые процессы будут продолжаться в течение периода времени ожидания бездействия.
При закрытии или остановке кодового пространства все незафиксированные изменения сохраняются, пока вы не подключитесь к кодовому пространству еще раз.
Запуск приложения
Переадресация портов обеспечивает доступ к TCP-портам, работающим в кодовом пространстве. Например, если веб-приложение выполняется через порт 4000 в кодовом пространстве, можно настроить автоматическую переадресацию этого порта с тем, чтобы приложение было доступно из браузера.
Переадресация портов определяет, какие порты будут вам доступны с удаленного компьютера. Даже если вы не переадресуете порт, он будет по-прежнему доступен другим процессам, выполняемым в самом кодовом пространстве.
Когда приложение, работающее внутри GitHub Codespaces выводит порт в консоль, GitHub Codespaces обнаруживает шаблон URL-адреса localhost и автоматически перенаправит порт. Вы можете щелкнуть URL-адрес в терминале или ссылку в сообщении уведомления toast, которое отображается в правом нижнем углу VS Code, чтобы открыть порт в браузере. По умолчанию GitHub Codespaces перенаправит порт с помощью HTTP. Дополнительные сведения о переадресации портов см. в разделе "Переадресация портов в вашем codespace".
Порты могут переадресовываться автоматически, но не являются общедоступными в Интернете. По умолчанию все порты являются частными, но любой порт можно сделать доступным для вашей организации или общедоступным, а затем предоставить к нему доступ по URL-адресу. Дополнительные сведения см. в разделе Переадресация портов в вашем codespace.
Запуск приложения при первом подключении к кодовому пространству может сопровождаться быстрым внутренним циклом разработки. При редактировании изменения автоматически сохраняются и становятся доступными через переадресованный порт. Для просмотра изменений вернитесь на вкладку запущенного приложения в браузере и обновите ее.
Фиксация и отправка изменений
Git устанавливается по умолчанию в пространстве кода и позволяет использовать существующий рабочий процесс Git. Вы можете работать с Git в пространстве кода через терминал или с помощью функций управления версиями VS Code или JetBrains.
Если вы работаете с существующим репозиторием, вы можете создать пространство кода из любой ветви, фиксации или запроса на вытягивание в репозитории или переключиться на новую или существующую ветвь из активного пространства кода. Поскольку среда GitHub Codespaces предназначена для временного использования, она может служить изолированной средой для экспериментов, проверки запроса на вытягивание, созданного членом команды, или устранения конфликтов слияния.
Если у вас есть доступ только на чтение к репозиторию, можно создать пространство кода для репозитория до тех пор, пока его можно вставить. При выполнении фиксации из пространства кода или отправке новой ветви GitHub Codespaces автоматически создает вилку репозитория или связывает пространство кода с существующим вилком, если у вас уже есть один для вышестоящего репозитория.
Если вы работаете в пространстве кода, созданном на основе шаблона, Git устанавливается по умолчанию, но вам потребуется опубликовать пространство кода в удаленный репозиторий, чтобы сохранить работу и поделиться ею с другими пользователями. Если вы начинаете с пустого шаблона GitHub, сначала необходимо инициализировать рабочую область в качестве репозитория Git (например, введя git init) для начала использования системы управления версиями в пространстве кода.
Дополнительные сведения см. в разделе Использование системы управления версиями в codespace.
Примечание. Фиксации из кодового пространства будут соотнесены с именем и общедоступный адресом электронной почты, настроенным в https://github.com/settings/profile. Токен, ограниченный репозиторием, включается в среду как GITHUB_TOKEN, а для проверки подлинности используются учетные данные GitHub.
Персонализация пространства кода с помощью расширений или подключаемых модулей
Подключаемые модули и расширения можно добавить в пространство кода, чтобы персонализировать интерфейс в JetBrains и VS Code соответственно.
Расширения VS Code
Если вы работаете над пространствами кода в классическом приложении VS Code или веб-клиенте, можно добавить любые расширения, необходимые из Visual Studio Code Marketplace. Сведения о том, как модули выполняются в GitHub Codespaces, см . в документации по GitHub Codespaces в документации VS Code.
Если вы уже используете VS Code, вы можете использовать синхронизацию параметров для автоматической синхронизации расширений, параметров, тем и сочетаний клавиш между локальным экземпляром и любыми создаваемыми пространствами кода.
Подключаемые модули JetBrains
Если вы работаете над пространствами кода в интегрированной среде разработки JetBrains, вы можете добавить подключаемые модули из JetBrains Marketplace.
-
Щелкните "Клиент JetBrains", а затем нажмите кнопку "Параметры".
-
В диалоговом окне "Настройки" щелкните подключаемые модули на узле , чтобы установить подключаемый модуль в полной интегрированной среде разработки JetBrains, которая выполняется удаленно, или подключаемые модули, чтобы установить подключаемый модуль на локальном клиенте, например, чтобы изменить тему пользовательского интерфейса.
-
Перейдите на вкладку Marketplace .
-
Нажмите кнопку "Установить рядом с необходимым подключаемым модулем".
Сведения о структуре каталогов пространства кода
При создании пространства кода репозиторий клонируется в /workspaces каталог в пространстве кода. Это постоянный каталог, подключенный к контейнеру. Все изменения, внесенные в этот каталог, включая редактирование, добавление или удаление файлов, сохраняются при остановке и запуске пространства кода, а также при перестроении контейнера в пространстве кода.
/workspaces За пределами каталога пространство кода содержит структуру каталогов Linux, которая зависит от образа контейнера разработки, используемого для сборки пространства кода. Вы можете добавлять файлы или вносить изменения в файлы за пределами /workspaces каталога. Например, можно установить новые программы или настроить конфигурацию оболочки в файле, ~/.bashrcнапример. В качестве пользователя, не являющегося корневым, вы не можете автоматически записывать доступ к определенным каталогам, но большинство образов разрешают корневой доступ к этим каталогам с sudo помощью команды.
За пределами /workspaces``/tmp каталога каталоги в пространстве кода привязаны к жизненному циклу контейнера. Это означает, что все внесенные изменения сохраняются при остановке и запуске пространства кода, но не сохраняются при перестроении контейнера. Дополнительные сведения о каталоге /tmp см. в разделе "Сохранение переменных среды и временных файлов".
Очистка каталогов за пределами /workspaces помогает убедиться, что перестроенный контейнер находится в том же состоянии, что и в созданном пространстве кода. Если вы перестроите контейнер для применения изменений конфигурации к пространству кода, в который вы работаете, вы можете быть уверены, что все внесенные изменения конфигурации будут работать одинаково для пользователей, создающих новые пространства кода с той же конфигурацией. Дополнительные сведения см. в разделе Основные сведения о контейнерах разработки.
Если вы хотите внести изменения в пространство кода, которое будет более надежным над перестроениями и в разных пространствах кода, у вас есть несколько вариантов.
- Чтобы установить программы и средства во всех пространствах кода, созданных из репозитория, в конфигурации контейнера разработки можно использовать свойства команд жизненного цикла, такие как
postCreateCommandвыполнение пользовательских команд установки, или вы можете выбрать из предварительно написанных команд установки с именем "компоненты". Дополнительные сведения см. в спецификации контейнеров разработки на веб-сайте "Контейнеры разработки" и "Добавление функций в файл devcontainer.json". - Чтобы установить средства или настроить установку в каждом создаваемом пространстве кода, например настройке
bashпрофиля, можно связать GitHub Codespaces с репозиторием dotfiles. Репозиторий dotfiles также клонируется в постоянный/workspacesкаталог. Дополнительные сведения см. в разделе Персонализация GitHub Codespaces для вашей учетной записи. - Если вы хотите сохранить определенные файлы при перестроении, можно использовать
devcontainer.jsonфайл для создания связи между файлами и постоянным каталогом./workspacesДополнительные сведения см. в разделе Перестроение контейнера в пространстве кода.