O GitHub Codespaces é um ambiente de desenvolvimento instantâneo e baseado na nuvem que usa um contêiner para fornecer linguagens, ferramentas e utilitários de desenvolvimento comuns. Os GitHub Codespaces também são configuráveis, o que permite criar um ambiente de desenvolvimento personalizado para o projeto. Ao configurar um ambiente de desenvolvimento personalizado para seu projeto, você pode ter uma configuração de código reproduzível para todos os usuários do seu projeto.
Criando seu codespace
Há uma série de pontos de entrada para criar um codespace.
- Com base em um modelo do GitHub ou em qualquer repositório de modelos no GitHub para iniciar um novo projeto
- A partir de um branch no seu repositório para o desenvolvimento de novas funcionalidades
- Com base em uma solicitação de pull aberta para explorar o trabalho em andamento
- Com base em um commit no histórico do repositório para investigar um bug em um momento específico
O seu codespace pode ser efêmero se tiver de fazer algum teste, ou você pode voltar ao mesmo codespace para trabalhar no desenvolvimento de funcionalidades de longa duração.
Para saber mais, confira AUTOTITLE, AUTOTITLE e AUTOTITLE.
Observação
Você pode criar mais de um codespace por repositório ou até mesmo por branch. No entanto, há limites para o número de codespaces que você pode criar e para o número que você pode executar ao mesmo tempo. Se você atingir o número máximo de codespaces e tentar criar outro, uma mensagem será exibida informando que você deverá remover um codespace antes de criar um novo.
O processo de criação do codespace
Quando você cria um codespace, várias etapas ocorrem em segundo plano até que o codespace fique disponível para uso.
Etapa 1: A VM e o armazenamento são atribuídos ao seu codespace
Quando você cria um codespace, uma máquina virtual (VM) é criada usando a versão estável ou versão prévia pública da imagem de host da VM. Para saber mais, confira AUTOTITLE. A imagem do host define a versão do Linux usada para a VM. A máquina virtual é dedicada e exclusiva para você. Ter uma VM dedicada garante que você tenha todo o conjunto de recursos de computação daquela máquina disponível para você. Se necessário, isso também permite que você tenha acesso root total ao seu contêiner.
Um clone superficial é feito do seu repositório ou do repositório de modelo, caso você esteja criando um codespace a partir de um modelo. A clonagem é feita no diretório da VM e, posteriormente, montada no contêiner de desenvolvimento. Para obter mais informações, confira Sobre a estrutura de diretório de um codespace abaixo.
Etapa 2: contêiner de desenvolvimento criado
O GitHub Codespaces usa um contêiner do Docker como ambiente de desenvolvimento. Este contêiner é criado com base nas configurações que você pode definir em um arquivo ou em um Dockerfile. Se você criar um codespace com base em um modelo em branco do GitHub ou em um repositório sem um arquivo de configuração, o GitHub Codespaces usará uma imagem padrão, que possui várias linguagens e runtimes disponíveis. Para saber mais, confira AUTOTITLE. Para obter detalhes sobre o que a imagem padrão de contêineres de desenvolvimento inclui, confira o repositório .
Observação
Se você quiser usar ganchos do Git no seu codespace e aplicar qualquer item no diretório de modelos do Git ao codespace, configure ganchos durante a etapa 4 após a criação do contêiner.
Como o repositório é clonado na VM do host antes de o contêiner ser criado, qualquer item contido no diretório de modelos do Git não será aplicado ao seu codespace, a menos que você configure ganchos no arquivo de configuração usando na etapa 4. Para obter mais informações, consulte Etapa 4: Configuração após a criação.
Etapa 3: Conectando-se ao codespace
Quando seu contêiner for criado e qualquer outra inicialização for executada, você estará conectado ao seu codespace. Você pode se conectar a ele usando:
- O navegador da Web
- { %data variables.product.prodname_vscode% }
- GitHub CLI
Configuração após a criação
Depois que você estiver conectado ao codespace, a configuração automatizada poderá continuar sendo compilada com base na configuração especificada no arquivo . Você poderá ver e serem executados.
Caso você queira usar ganchos do Git no seu espaço de código, configure os ganchos usando os scripts de ciclo de vida, como por exemplo:. Para obter informações sobre os scripts de ciclo de vida, confira a especificação de contêineres de desenvolvimento no site de contêineres de desenvolvimento.
Se tiver um repositório público de dotfiles para o GitHub Codespaces, você poderá habilitá-lo para uso com novos codespaces. Quando habilitado, seus dotfiles serão clonados para o contêiner e o script de instalação será invocado. Para saber mais, confira AUTOTITLE.
Por fim, se você criou o codespace a partir de um repositório, todo o histórico do repositório será copiado com um clone completo. Se você criou o codespace com base em um modelo, o histórico completo do repositório de modelos não será preservado. Nesse caso, a menos que você esteja usando o modelo em branco, você começará com um commit inicial do conteúdo do repositório de modelos.
Durante a configuração de pós-criação, você ainda poderá usar o terminal integrado e fazer edições nos seus arquivos, mas tenha cuidado para evitar quaisquer condições de concorrência entre seu trabalho e os comandos que estão sendo executados.
Ciclo de vida de Codespaces
Salvando arquivos no seu codespace
Salve as alterações nos arquivos da maneira normal, dependendo do editor que você esteja usando.
Se você trabalha em codespaces no Visual Studio Code, pode habilitar o Salvamento Automático para garantir que suas alterações sejam sempre salvas.
Fechando ou interrompendo seu codespace
O codespace continuará em execução enquanto você o estiver usando, mas será encerrado após um período de inatividade. As mudanças nos arquivos feitas no editor e a saída do terminal são contadas como atividade, de modo que seu ambiente de código não atingirá o tempo limite se a saída do terminal continuar. O período de tempo limite de inatividade padrão é de 30 minutos. Você pode definir uma configuração pessoal de tempo limite para codespaces criados, mas isso pode ser anulado por uma política de tempo limite da organização. Para saber mais, confira AUTOTITLE.
Se um codespace atingir o tempo limite, ele deixará de ser executado, mas você poderá reiniciá-lo na guia do navegador (se estiver usando o codespace no navegador), de dentro do VS Code ou na lista de codespaces em .
Para interromper o codespace, você pode
- No navegador: na lista de codespaces em , clicar nas reticências ( ... ) à direita do codespace que deseja parar e clicar em Parar codespace.
- Em VS Code: abra o Visual Studio Code Command Palette – por exemplo, pressionando Ctrl+Shift+P (Windows/Linux) ou Shift+Command+P (Mac) – e pressione Enter. Para saber mais, confira AUTOTITLE.
- Em uma janela de terminal, use o comando da GitHub CLI. Para saber mais, confira AUTOTITLE.
Se você sair do codespace sem executar o comando de interrupção (por exemplo, fechando a aba do navegador) ou se você sair do codespace em execução sem interação, o codespace e os processos em execução continuarão até o tempo limite de inatividade seja atingido.
Ao fechar ou interromper o seu codespace, todas as alterações não autorizadas são preservadas até você conectar-se ao codespace novamente.
Executando seu aplicativo
O redirecionamento de porta dá acesso a portas TCP que estão em execução no seu codespace. Por exemplo, se você estiver executando um aplicativo web na porta 4000 dentro do seu codespace, você poderá encaminhar automaticamente a porta para tornar o aplicativo acessível a partir do seu navegador.
O encaminhamento de portas determina quais portas podem ser acessadas por você a partir da máquina remota. Mesmo que você não encaminhe uma porta, essa porta ainda poderá ser acessada por outros processos em execução dentro do próprio codespace.
Quando um aplicativo em execução dentro dos GitHub Codespaces emite uma porta para o console, os GitHub Codespaces detectam o padrão de URL do localhost e encaminham a porta automaticamente. Você pode clicar na URL no terminal ou no link na mensagem de notificação "toast" que aparece no canto inferior direito do VS Code para abrir a porta em um navegador. Por padrão, o GitHub Codespaces encaminha a porta usando HTTP. Para obter mais informações sobre o encaminhamento de porta, confira AUTOTITLE.
Embora as portas possam ser encaminhadas automaticamente, elas não estão acessíveis publicamente na internet. Por padrão, todas as portas são privadas, mas você pode disponibilizar manualmente uma porta para sua organização ou público, e, em seguida, compartilhar o acesso por meio de uma URL. Para saber mais, confira AUTOTITLE.
A execução do seu aplicativo ao iniciar no seu codespace pode facilitar um loop de desenvolvimento ágil interno. À medida que você edita, as alterações são salvas automaticamente e ficam disponíveis na sua porta encaminhada. Para visualizar as alterações, volte para a aba do aplicativo em execução no seu navegador e atualize-as.
Commitando e dando push das suas alterações
O Git é instalado por padrão no codespace. Portanto, você pode confiar no fluxo de trabalho do Git existente. Você pode trabalhar com o Git no codespace por meio do terminal ou usando os recursos de controle do código-fonte do VS Code.
Se você está trabalhando com um repositório existente, pode criar um codespace com base em qualquer ramificação, commit ou solicitação pull no repositório, ou mudar para uma ramificação nova ou existente de dentro do seu codespace ativo. Como o GitHub Codespaces foi projetado para ser efêmero, você poderá usá-lo como um ambiente isolado para experimentar, verificar a solicitação de pull de um colega ou corrigir os conflitos de mesclagem.
Se você tiver apenas acesso de leitura a um repositório, poderá criar um codespace para o repositório, desde que consiga fazer um fork dele. Quando você faz um commit por meio do codespace ou efetua push de um novo branch, o GitHub Codespaces cria automaticamente um fork do repositório para você ou, caso você já tenha um fork para o repositório upstream, vincula o codespace a ele.
Se você estiver trabalhando em um codespace criado com base em um modelo, o Git estará instalado por padrão, mas você precisará publicar o codespace em um repositório remoto para persistir o trabalho e compartilhá-lo com outras pessoas. Se você começar com o modelo em branco do GitHub, primeiro, precisará inicializar o workspace como um repositório Git (por exemplo, inserindo ) para começar a usar o controle do código-fonte no codespace.
Para saber mais, confira AUTOTITLE.
Observação
Commits do seu codespace serão atribuídos ao nome e ao email público configurados em . Um token escopado para o repositório, incluído no ambiente como GITHUB_TOKEN, e suas credenciais do GitHub serão usadas para autenticar.
Personalizando seu codespace com extensões
Você pode adicionar extensões em um codespace para personalizar sua experiência no VS Code.
Extensões do VS Code
Se você trabalhar nos codespaces no aplicativo da área de trabalho do VS Code ou no cliente Web, poderá adicionar todas as extensões necessárias do Visual Studio Code Marketplace. Para obter informações de como as extensões são executadas nos GitHub Codespaces, confira Suporte ao desenvolvimento remoto e ao GitHub Codespaces na documentação do VS Code.
Se você já usa o VS Code, pode usar o Settings Sync para sincronizar automaticamente extensões, configurações, temas e atalhos de teclado entre sua instância local e quaisquer codespaces que você criar.
Sobre a estrutura de diretório de um codespace
Quando você cria um codespace, seu repositório é clonado no diretório /workspaces no seu codespace. Esse é um diretório persistente que é montado no contêiner. Todas as alterações feitas dentro desse diretório, incluindo edição, adição ou exclusão de arquivos, são preservadas quando você para e inicia o codespace e recompila o contêiner no codespace.
Fora do diretório /workspaces, o codespace contém uma estrutura de diretório do Linux que varia conforme a imagem de contêiner de desenvolvimento usada para criar o codespace. Você pode adicionar arquivos ou fazer alterações em arquivos fora do diretório /workspaces. Por exemplo, você pode instalar novos programas ou definir a configuração do shell em um arquivo como o ~/.bashrc. Como um usuário não raiz, talvez você não tenha acesso de gravação automaticamente em alguns diretórios, mas a maioria das imagens permite o acesso raiz a esses diretórios com o comando sudo.
Fora de /workspaces, com exceção do diretório /tmp, os diretórios em um codespace são vinculados ao ciclo de vida do contêiner. Isso significa que todas as alterações feitas são preservadas quando você para e inicia o codespace, mas não são preservadas quando você recompila o contêiner. Para obter mais informações sobre o diretório , confira AUTOTITLE.
A limpeza dos diretórios externos ajuda a garantir que o contêiner recompilado esteja no mesmo estado que estaria em um codespace recém-criado. Se você estiver recompilando um contêiner para aplicar alterações de configuração ao codespace no qual está trabalhando, tenha certeza de que todas as alterações de configuração feitas funcionarão da mesma forma para os usuários que criam codespaces com a mesma configuração. Para saber mais, confira AUTOTITLE.
Caso você deseje fazer alterações no seu codespace que sejam mais robustas em reconstruções e em diferentes codespaces, há várias opções.
- Para instalar programas e ferramentas em todos os codespaces criados com base em um repositório, na configuração do contêiner de desenvolvimento, você pode usar propriedades de comando do ciclo de vida para executar comandos de instalação personalizados, ou pode escolher entre comandos de instalação predefinidos chamados "features". Para saber mais, confira a especificação de contêineres de desenvolvimento no site Contêineres de desenvolvimento e AUTOTITLE.
- Para instalar ferramentas ou personalizar sua configuração em cada codespace criado, como configurar seu perfil , vincule o GitHub Codespaces a um repositório de dotfiles. O repositório de dotfiles também é clonado no diretório persistente . Para saber mais, confira AUTOTITLE.
- Caso você deseje preservar arquivos específicos em uma recompilação, use um arquivo para criar um link simbólico entre os arquivos e um diretório persistente dentro de . Para saber mais, confira AUTOTITLE.
Leitura adicional
- AUTOTITLE
- AUTOTITLE
- AUTOTITLE
- AUTOTITLE