Para que eu usaria o git-worktree?

Eu li o post do Github no git-worktree . Eles escrevem:

Suponha que você esteja trabalhando em um repositório Git em uma ramificação chamada feature, quando um usuário relatar um erro de alta urgência master. Primeiro, você cria uma árvore de trabalho vinculada com uma nova ramificação, com hotfixcheck-out relativo ao mestre […] Você pode corrigir o bug, enviar hotfix e criar uma solicitação de recebimento.

Quando estou trabalhando em uma ramificação chamada feature e algum bug de alta urgência no master é relatado, geralmente escondo o que estiver trabalhando e crio uma nova ramificação. Quando terminar, posso continuar trabalhando. Este é um modelo muito simples, eu trabalho assim há anos.

Por outro lado, o uso do git-worktree tem suas próprias limitações:

Por exemplo, não é permitido o check-out do mesmo ramo em duas árvores de trabalho vinculadas ao mesmo tempo, porque isso permitiria que as alterações confirmadas em uma árvore de trabalho deixassem a outra fora de sincronia.

Por que eu escolheria um fluxo de trabalho mais complicado para um problema que já foi resolvido?

Existe algo sobre git-worktreeisso que não possa ser feito antecipadamente e que justifique todo esse novo e complexo recurso?

Para mim, o git worktree é a maior melhoria desde muito tempo. Estou trabalhando no desenvolvimento de software corporativo. Lá, é muito comum que você tenha que manter versões antigas como as que você lançou há 3 anos. É claro que você tem uma ramificação para cada versão, para poder alternar facilmente para ela e corrigir um bug. No entanto, a troca é cara, porque, entretanto, você reestruturou completamente o repositório e talvez construa o sistema. Se você alternar, seu IDE ficará louco ao tentar adaptar as configurações do projeto.

Com a árvore de trabalho, você pode evitar essa reconfiguração constante. Faça o checkout desses galhos antigos em pastas separadas usando a árvore de trabalho. Para cada filial, você tem um projeto IDE independente.

É claro que isso poderia ter sido feito no passado, clonando o repositório várias vezes e essa foi a minha abordagem até agora. No entanto, isso também significava desperdiçar espaço no disco rígido e pior necessidade de buscar as mesmas alterações no repositório várias vezes.

Eu posso ver alguns usos para isso.

Se você tem um conjunto de testes que é executado por um longo período de tempo, imagine horas e o inicia, efetivamente bloqueia essa cópia de trabalho até que os testes sejam concluídos. A troca de ramificações durante esses testes os quebraria de maneiras difíceis de entender.

Então, com git-worktreeeu poderia ter uma segunda idéia lançada para outro ramo que trabalha lá.

Além disso, quando mudo para outra ramificação para fazer uma investigação rápida, meu IDE acha que muitos arquivos foram alterados repentinamente e indexarão todas essas alterações, apenas para ter que re-indexá-las novamente quando voltar.

Um terceiro caso de uso seria fazer a comparação de arquivos usando outras ferramentas além de git-diff, normalmente diff, entre dois diretórios em vez de duas ramificações.

Um uso óbvio é comparar simultaneamente o comportamento (não a fonte) de versões diferentes - por exemplo, versões diferentes de um site ou apenas uma página da web.

Eu tentei isso localmente.

• criar um diretório page1.

• dentro de criar o diretório srce git initele.

• em srccriar page1.htmlcom um pouco de conteúdo e enviá-lo.

• $ git branch ver0

• $ git worktree add ../V0 ver0

• no srcmaster adicione mais texto page1.htmle confirme.

• $ git branch sty1

• edite page1.htmlna sty1ramificação (adicione um estilo CSS distinto) e adicione commit.

• $ git worktree add ../S1 sty1

Agora você pode usar um navegador da web para abrir e visualizar essas três versões simultaneamente:

• ..\page1\src\page1.html // qualquer que seja o git atual

• ..\page1\V0\page1.html // a versão inicial

• ..\page1\S1\page1.html // a versão com estilo experimental

1. Existem razões legítimas pelas quais você pode querer / precisar de várias árvores de trabalho no sistema de arquivos de uma só vez.

   • manipular os arquivos com check-out enquanto precisar fazer alterações em outro lugar (por exemplo, compilação / teste)

   • diferenciando os arquivos por meio de ferramentas diff normais

   • durante conflitos de mesclagem, geralmente desejo navegar pelo código-fonte, pois está do lado da fonte enquanto resolvo conflitos nos arquivos.

   • Se você precisar alternar muito, haverá perda de tempo no check-out e verificação de que você não precisa fazer com várias ruas de trabalho.

   • o custo mental da alternância do contexto mental entre os ramos por meio do armazenamento em cache do Git não é realmente mensurável. Algumas pessoas acham que existe um custo mental para esconder isso simplesmente abrindo arquivos de um diretório diferente.

2. Algumas pessoas perguntam "por que não fazer vários clones locais". É verdade que, com o sinalizador "--local", você não precisa se preocupar com o uso extra de espaço em disco. Isso (ou idéias semelhantes) é o que eu fiz até este ponto. As vantagens funcionais das ruas de trabalho vinculadas aos clones locais são:

   1. Com os clones locais, suas ruas de trabalho extras (que estão nos clones locais) simplesmente não têm acesso à origem ou ramificações upstream. A 'origem' no clone não será a mesma que a 'origem' no primeiro clone.

      • Correr git log @{u}..ou git diff origin/feature/other-featurepode ser muito útil e isso não é mais possível ou é mais difícil. Tecnicamente, essas idéias são possíveis com clones locais por meio de uma variedade de soluções alternativas, mas todas as soluções alternativas que você pode executar são realizadas de maneira melhor e / ou mais simples por meio de ruas de trabalho vinculadas.

   2. Você pode compartilhar referências entre worktrees. Se você deseja comparar ou emprestar alterações de outra filial local, agora pode.

tl; dr: sempre que você quiser fazer o check-out de duas árvores de trabalho ao mesmo tempo, por qualquer motivo, git-worktree é uma maneira rápida e com economia de espaço.

Se você criar outra árvore de trabalho, a maior parte do repositório (ou seja .git) será compartilhada, ou seja, se você criar uma ramificação ou buscar dados enquanto estiver em uma árvore de trabalho, ele também estará acessível a partir de qualquer outra árvore de trabalho que você tenha. Digamos que você queira executar seu conjunto de testes no branch foo sem precisar empurrá-lo para algum lugar para cloná-lo, e deseja evitar o incômodo de clonar seu repositório localmente, usar git-worktreeuma boa maneira de criar apenas uma nova verificação de algum estado em um local separado, temporária ou permanentemente. Assim como em um clone, tudo o que você precisa fazer quando terminar é excluí-lo, e a referência a ele será coletada como lixo após algum tempo.

Originalmente, eu tropecei nessa questão depois de me perguntar para que essas workstes sofisticadas poderiam ser usadas. Desde então, eu os integrei ao meu fluxo de trabalho e, apesar do meu ceticismo inicial, cheguei a considerá-los bastante úteis.

Eu trabalho em uma base de código bastante grande, que leva algum tempo para compilar. Normalmente, tenho a ramificação de desenvolvimento atual em minha máquina, juntamente com a ramificação de recursos em que estou trabalhando, mais a ramificação mestre, que representa o estado atual do sistema ativo.

Um dos maiores benefícios para mim é obviamente que não preciso recompilar a coisa toda toda vez que troco de ramificação (ou seja, ruas de trabalho). Um bom efeito colateral é que eu posso ir para a área de trabalho de desenvolvimento, fazer coisas lá, alterar o diretório para a área de trabalho da minha ramificação de recursos atual e depois refazê-la sem ter que puxar primeiro.

Eu tenho um problema bastante incomum: estou desenvolvendo o Windows e Linux na mesma máquina . Eu tenho um VirtualBox executando o Linux dentro da minha caixa do Windows. O VirtualBox monta alguns diretórios do Windows e os usa diretamente dentro da máquina Linux. Isso me permite usar o Windows para gerenciar arquivos, mas criar no Linux. Este é um projeto de plataforma cruzada, desenvolvido com base no Windows e Linux a partir da mesma estrutura de diretório.

O problema é que o Linux e o Windows constroem sistemas colidem um com o outro quando usados ​​no mesmo diretório; existem algumas etapas complicadas de compilação para fazer o download de bibliotecas, etc., que usam os mesmos nomes de diretório. A versão do Windows do sistema de construção baixa as bibliotecas específicas do Windows e a versão do Linux do sistema de construção baixa as bibliotecas específicas do Linux.

Em um mundo ideal, o sistema de compilação seria modificado para que o Windows e Linux coexistissem no diretório, mas, por enquanto, o problema está sendo resolvido com as ruas de trabalho. A pasta "Linux" pode gerar artefatos de construção específicos do Linux e a pasta "Windows" pode gerar artefatos de construção específicos do Windows. Embora essa dificilmente seja uma solução ideal, ela oferece uma boa pausa enquanto aguarda a correção dos erros do sistema de compilação.

É certo que a árvore de trabalho não foi projetada para isso; Eu tenho que manter a versão do Windows e a versão do Linux em ramificações separadas, mesmo que eu realmente prefira que elas estejam na mesma ramificação. Ainda assim, ele está fazendo o trabalho e é um caso não convencional de uma árvore de trabalho que salva o dia.

Em um novo projeto para mim, criei um recurso. Mas algumas especificações falharam. Para comparar os resultados master, criei um work-treerepositório. Comparei os resultados passo a passo no código de execução, até entender o que deu errado.

Estou usando git worktreepara o desenvolvimento de aprendizado de máquina.

Eu tenho um código funcional principal e, em seguida, quero dividir ramificações de diferentes experimentos (algoritmos diferentes e hiperparâmetros diferentes). git worktreepermite integrar o dvc ao lado de diferentes versões do meu código, especializadas em diferentes algoritmos. Depois de executar todos os trabalhos de treinamento, avalio as métricas finais e mesclo para dominar o melhor ramo / modelo.