Árvores de trabalho
Árvores de trabalho
Utilize árvores de trabalho do Git no Codex, na aplicação ChatGPT para computador, para executar conversas em paralelo
As árvores de trabalho permitem ao Codex executar várias conversas independentes no mesmo projeto sem interferirem entre si. O repositório, a árvore de trabalho e os comandos permanecem no computador ou no ambiente de desenvolvimento remoto que contém o projeto. Pode trabalhar diretamente na aplicação ChatGPT para computador ou utilizar Remote na aplicação ChatGPT para dispositivos móveis para iniciar, orientar, aprovar e rever conversas em árvores de trabalho num computador ligado.
Nos repositórios Git, as tarefas agendadas podem ser executadas em árvores de trabalho dedicadas em segundo plano para não entrarem em conflito com o trabalho em curso. Em projetos sem controlo de versões, as tarefas agendadas são executadas diretamente no diretório do projeto. Também pode iniciar manualmente conversas numa árvore de trabalho e utilizar a Transferência para mover uma conversa entre Local e Worktree.
O que é uma árvore de trabalho
As árvores de trabalho só funcionam em projetos que façam parte de um repositório Git, uma vez que utilizam internamente as árvores de trabalho do Git. Uma árvore de trabalho permite criar uma segunda cópia ("checkout") do repositório. Cada árvore de trabalho tem a sua própria cópia de todos os ficheiros do repositório, mas todas partilham os mesmos metadados (pasta .git) relativos a commits, ramos, etc. Isto permite efetuar checkout e trabalhar em vários ramos em paralelo.
Terminologia
- Checkout local: o repositório que criou. Por vezes, é referido simplesmente como Local na aplicação ChatGPT para computador.
- Árvore de trabalho: uma árvore de trabalho do Git criada a partir do seu checkout local na aplicação ChatGPT para computador.
- Transferência: o fluxo que move uma conversa entre Local e Worktree. O Codex trata das operações Git necessárias para mover o seu trabalho em segurança entre ambos.
Porquê utilizar uma árvore de trabalho
- Trabalhar em paralelo com o Codex sem perturbar a configuração Local atual.
- Colocar trabalho em fila de espera em segundo plano enquanto mantém a atenção no primeiro plano.
- Mover posteriormente uma conversa para Local quando estiver pronto para inspecionar, testar ou colaborar de forma mais direta.
Introdução
As árvores de trabalho requerem um repositório Git. Certifique-se de que o projeto selecionado se encontra num repositório.
Selecionar "Worktree"
Na vista de nova conversa, selecione Worktree sob a caixa de composição. Opcionalmente, escolha um ambiente local para executar scripts de configuração para a árvore de trabalho.
Selecionar o ramo inicial
Sob a caixa de composição, escolha o ramo Git no qual pretende basear a árvore de trabalho. Pode ser o seu ramo
main/master, um ramo de funcionalidade ou o ramo atual com alterações locais não preparadas.Enviar o pedido
Envie o pedido e o Codex criará uma árvore de trabalho Git baseada no ramo selecionado. Por predefinição, o Codex trabalha num "HEAD desanexado".
Escolher onde continuar a trabalhar
Quando estiver pronto, pode continuar a trabalhar diretamente na árvore de trabalho ou transferir a conversa para o seu checkout local. A transferência de ou para Local move a conversa e o código, para que possa continuar no outro checkout.
Trabalhar entre Local e Worktree
As árvores de trabalho têm um aspeto e funcionamento muito semelhantes aos do checkout local. A diferença reside no lugar que ocupam no seu fluxo. Pode considerar Local como o primeiro plano e Worktree como o segundo plano. A Transferência permite mover uma conversa entre ambos.
Internamente, a Transferência trata das operações Git necessárias para mover trabalho em segurança entre dois checkouts. Isto é importante porque o Git só permite que um ramo tenha checkout efetuado num local de cada vez. Se efetuar o checkout de um ramo numa árvore de trabalho, não pode efetuar simultaneamente o respetivo checkout no checkout local, e vice-versa.
Na prática, existem dois percursos comuns:
- Trabalhar exclusivamente na árvore de trabalho. Este percurso é mais adequado quando pode verificar as alterações diretamente na árvore de trabalho, por exemplo, porque instalou dependências e ferramentas através de um script de configuração do ambiente local.
- Transferir a conversa para Local. Utilize este percurso quando pretender trazer a conversa para o primeiro plano, por exemplo, porque pretende inspecionar as alterações no IDE habitual ou apenas pode executar uma instância da aplicação.
Opção 1: Trabalhar na árvore de trabalho
Se pretender permanecer exclusivamente na árvore de trabalho com as suas alterações, transforme-a num ramo através do botão Create branch here no cabeçalho da conversa.
A partir daqui, pode fazer commit das alterações, enviar o ramo para o repositório remoto e abrir um pull request no GitHub.
Pode abrir o seu IDE na árvore de trabalho utilizando o botão Abrir no cabeçalho, utilizar o terminal integrado ou qualquer outra ferramenta de que necessite a partir do diretório da árvore de trabalho.
Opção 2: Transferir uma conversa para Local
Se pretender trazer uma conversa para o primeiro plano, selecione Transferir no cabeçalho da conversa e mova-a para Local.
Este percurso é adequado quando pretende ler as alterações na janela habitual do IDE, executar o servidor de desenvolvimento existente ou validar o trabalho no mesmo ambiente que já utiliza diariamente.
O Codex trata dos passos do Git necessários para mover a conversa em segurança entre a árvore de trabalho e o checkout local.
Cada conversa mantém a mesma árvore de trabalho associada ao longo do tempo. Se, mais tarde, voltar a transferir a conversa para uma árvore de trabalho, o Codex devolve-a ao mesmo ambiente em segundo plano, para que possa retomar o trabalho onde o deixou.
Uma vez que a Transferência utiliza operações Git, os ficheiros que façam parte do seu ficheiro .gitignore não serão movidos com a conversa, a menos que o Codex os copie para uma árvore de trabalho local gerida com .worktreeinclude.
Detalhes avançados
Árvores de trabalho geridas pelo Codex e permanentes
Por predefinição, as conversas utilizam uma árvore de trabalho gerida pelo Codex. Estas foram concebidas para serem leves e descartáveis. Normalmente, uma árvore de trabalho gerida pelo Codex é dedicada a uma conversa, e o Codex devolve essa conversa à mesma árvore de trabalho se a transferir novamente para lá mais tarde.
Se pretender um ambiente de longa duração, crie uma árvore de trabalho permanente no menu de três pontos de um projeto na barra lateral. Esta ação cria uma nova árvore de trabalho permanente como projeto independente. As árvores de trabalho permanentes não são eliminadas automaticamente, e pode iniciar várias conversas a partir da mesma árvore de trabalho.
Como o Codex gere as árvores de trabalho por si
O Codex cria árvores de trabalho em $CODEX_HOME/worktrees. O commit inicial é o commit HEAD do ramo selecionado quando inicia a conversa. Se tiver escolhido um ramo com alterações locais, o Codex também aplica as alterações não confirmadas à árvore de trabalho. A árvore de trabalho não tem um ramo em checkout. Encontra-se num estado de HEAD desanexado. Isto permite ao Codex criar várias árvores de trabalho sem sobrecarregar os seus ramos.
Copiar ficheiros locais ignorados para árvores de trabalho geridas
As árvores de trabalho locais geridas pelo Codex começam a partir de um checkout do Git, pelo que os ficheiros controlados já estão presentes. Se o repositório ignorar ficheiros de configuração locais necessários para uma nova árvore de trabalho, adicione um ficheiro .worktreeinclude à raiz do repositório e indique os caminhos ignorados ou padrões ao estilo de .gitignore que devem ser copiados quando o Codex criar uma árvore de trabalho gerida.
Utilize esta opção para ficheiros que o Git ignora intencionalmente, como .env, .env.local ou config/secrets.json. O Codex apenas copia ficheiros ignorados que correspondam a .worktreeinclude; não copia outros ficheiros locais que não sejam controlados pelo Git. Não indique ficheiros controlados.
O Codex copia automaticamente um AGENTS.override.md ignorado para árvores de trabalho locais geridas, pelo que não precisa de o indicar em .worktreeinclude.
# .worktreeinclude
.env
.env.local
config/secrets.jsonO Codex ignora ligações simbólicas na origem e não substitui ficheiros que já existam no novo checkout. Este comportamento aplica-se às árvores de trabalho locais geridas pela aplicação ChatGPT para computador, não a árvores de trabalho remotas nem a árvores de trabalho Git que crie diretamente na linha de comandos.
Limitações dos ramos
Suponha que o Codex conclui algum trabalho numa árvore de trabalho e que opta por criar nela um ramo feature/a através de Create branch here. Agora pretende experimentá-lo no checkout local. Se tentasse efetuar o checkout do ramo, obteria o seguinte erro:
fatal: 'feature/a' is already used by worktree at '<WORKTREE_PATH>'Para resolver este problema, teria de efetuar o checkout de outro ramo, em vez de feature/a, na árvore de trabalho.
Se pretender efetuar o checkout do ramo localmente, utilize a Transferência para mover a conversa para Local, em vez de tentar manter simultaneamente o mesmo ramo com checkout efetuado em ambos os locais.
Por que motivo existe esta limitação
O Git impede que o mesmo ramo tenha checkout em mais do que uma árvore de trabalho em simultâneo, porque um ramo representa uma única referência mutável (`refs/heads/Quando é efetuado o checkout de um ramo, o Git considera que o respetivo HEAD pertence a essa árvore de trabalho e espera que operações como commits, reposições, rebases e integrações façam avançar essa referência de forma bem definida e sequencial. Permitir que várias árvores de trabalho tivessem simultaneamente o mesmo ramo com checkout efetuado criaria ambiguidades e condições de corrida quanto às operações de que árvore de trabalho atualizariam a referência do ramo, o que poderia originar commits perdidos, índices inconsistentes ou uma resolução de conflitos pouco clara.
Ao impor a regra de um ramo por árvore de trabalho, o Git garante que cada ramo tem uma única cópia de trabalho autoritativa, permitindo simultaneamente que outras árvores de trabalho referenciem os mesmos commits em segurança através de HEADs desanexados ou ramos distintos.
Limpeza de árvores de trabalho
As árvores de trabalho podem ocupar muito espaço em disco. Cada uma tem o seu próprio conjunto de ficheiros do repositório, dependências, caches de compilação, etc. Por conseguinte, a aplicação ChatGPT para computador procura manter o número de árvores de trabalho dentro de um limite razoável.
Por predefinição, o Codex conserva as 15 árvores de trabalho geridas pelo Codex mais recentes. Pode alterar este limite ou desativar a eliminação automática nas definições, se preferir gerir pessoalmente a utilização do disco.
O Codex procura evitar eliminar árvores de trabalho que ainda sejam importantes. As árvores de trabalho geridas pelo Codex não são eliminadas automaticamente se:
- Estiverem associadas a uma conversa afixada
- A conversa ainda estiver em curso
- A árvore de trabalho for permanente
As árvores de trabalho geridas pelo Codex são eliminadas automaticamente quando:
- Arquiva a conversa associada
- O Codex precisa de eliminar árvores de trabalho mais antigas para respeitar o limite configurado
Antes de eliminar uma árvore de trabalho gerida pelo Codex, o Codex guarda uma captura do trabalho existente. Se abrir uma conversa depois de a respetiva árvore de trabalho ter sido eliminada, verá a opção de a restaurar.