Executar operações Git em pastas Git Databricks (Repos)

O artigo descreve como executar operações comuns do Git em seu espaço de trabalho Databricks usando pastas Git, incluindo clonagem, ramificação, confirmação e envio por push.

Clone um repositório conectado a um repositório Git remoto

1. Na barra lateral, selecione Espaço de trabalho e, em seguida, navegue até a pasta onde deseja criar o clone de repositório Git.

2. Clique na seta para baixo à direita de Adicionar no canto superior direito do espaço de trabalho e selecione a pasta Git na lista suspensa.

   

3. Na caixa de diálogo Criar pasta Git, forneça as seguintes informações:

   • A URL do repositório Git que você deseja clonar, no formato https://example.com/organization/project.git
   • O provedor Git para o repositório que você deseja clonar. As opções incluem GitHub, GitHub Enterprise, GitLab e Azure DevOps (Azure Repos)
   • O nome da pasta em seu espaço de trabalho que conterá o conteúdo do repositório clonado
   • Se você usará ou não check-out esparso, no qual apenas subdiretórios especificados usando um padrão de cone são clonados

   

Nesta etapa, você tem a opção de clonar apenas um subconjunto dos diretórios do repositório usando check-out esparso. Isso é útil se o repositório for maior do que os limites suportados pelo Databricks

1. Clique em Criar pasta Git. O conteúdo do repositório remoto é clonado para o repositório Databricks e você pode começar a trabalhar com eles usando operações Git suportadas em seu espaço de trabalho.

Prática recomendada: Colaborando em pastas Git

As pastas Git do Databricks efetivamente se comportam como clientes Git incorporados em seu espaço de trabalho para que os usuários possam colaborar usando o controle de origem e o controle de versão baseados no Git. Para tornar a colaboração em equipe mais eficaz, use uma pasta Git Databricks separada mapeada para um repositório Git remoto para cada usuário que trabalha em sua própria ramificação de desenvolvimento. Embora vários usuários possam contribuir com conteúdo para uma pasta Git, apenas um usuário designado deve executar operações Git, como pull, push, commit e branch switching. Se vários usuários executarem operações Git em uma pasta Git, o gerenciamento de ramificações pode se tornar difícil e propenso a erros, como quando um usuário alterna uma ramificação e a alterna involuntariamente para todos os outros usuários dessa pasta.

Para compartilhar uma pasta Git com um colaborador, clique em Copiar link para criar a pasta Git no banner na parte superior do espaço de trabalho Databricks. Esta ação copia um URL para a área de transferência local que pode ser enviado para outro utilizador. Quando o usuário destinatário carrega essa URL em um navegador, ele será levado para o espaço de trabalho, onde poderá criar sua própria pasta Git clonada a partir do mesmo repositório Git remoto. Eles verão uma caixa de diálogo modal Criar pasta Git na interface do usuário, pré-preenchida com os valores retirados de sua própria pasta Git. Quando eles clicam no botão azul Criar pasta Git no modal, o repositório Git é clonado no espaço de trabalho sob sua pasta de trabalho atual, onde agora eles podem trabalhar diretamente com ele.

Ao acessar a pasta Git de outra pessoa em um espaço de trabalho compartilhado, clique em Criar pasta Git no banner na parte superior. Esta ação abre a caixa de diálogo Criar pasta Git para você, pré-preenchida com a configuração para o repositório Git que a apoia.

Importante

Atualmente, você não pode usar a CLI do Git para executar operações do Git em uma pasta Git. Se você clonar um repositório Git usando a CLI por meio do terminal Web de um cluster, os arquivos não serão exibidos na interface do usuário do Azure Databricks.

Acesse a caixa de diálogo Git

Você pode acessar a caixa de diálogo Git de um bloco de anotações ou do navegador de pastas Git Databricks.

• Em um bloco de anotações, clique no botão ao lado do nome do bloco de anotações que identifica a ramificação atual do Git.

  

• No navegador de pastas Databricks Git, clique no botão à direita do nome do repositório. Você também pode clicar com o botão direito do mouse no nome do repositório e selecionar Git... no menu.

  

Você verá uma caixa de diálogo em tela cheia onde você pode executar operações Git.

1. O seu ramo de trabalho atual. Você pode selecionar outras filiais aqui. Se outros usuários tiverem acesso a essa pasta do Git, alterar a ramificação também alterará a ramificação para eles se compartilharem o mesmo espaço de trabalho. Consulte uma prática recomendada para evitar esse problema.
2. O botão para criar uma nova ramificação.
3. A lista de ativos de arquivo e subpastas verificados em sua ramificação atual.
4. Um botão que leva você ao seu provedor Git e mostra o histórico atual da filial.
5. O botão para extrair conteúdo do repositório Git remoto.
6. Caixa de texto onde você adiciona uma mensagem de confirmação e uma descrição expandida opcional para suas alterações.
7. O botão para confirmar seu trabalho na ramificação de trabalho e empurrar a ramificação atualizada para o repositório Git remoto.

Clique no kebab no canto superior direito para escolher entre operações adicionais de ramificação do Git, como uma redefinição forçada, uma mesclagem ou uma rebase.

Esta é a sua casa para executar operações Git na pasta Git do seu espaço de trabalho. Você está limitado às operações do Git apresentadas na interface do usuário.

Criar um novo ramo

Você pode criar uma nova ramificação com base em uma ramificação existente na caixa de diálogo Git:

Mudar para uma ramificação diferente

Você pode alternar para (checkout) uma ramificação diferente usando a lista suspensa de ramificação na caixa de diálogo do Git:

Importante

Depois de fazer checkout de uma ramificação em uma pasta Git, há sempre uma chance de que a ramificação possa ser excluída no repositório Git remoto por outra pessoa. Se uma ramificação for excluída no repositório remoto, a versão local poderá permanecer presente na pasta Git associada por até 7 dias. As ramificações locais no Databricks não podem ser excluídas, portanto, se você precisar removê-las, também deverá excluir e reclonar o repositório.

Confirmar e enviar alterações por push para o repositório Git remoto

Quando você tiver adicionado novos blocos de anotações ou arquivos, ou feito alterações em blocos de anotações ou arquivos existentes, a interface do usuário da pasta Git realça as alterações.

Adicione uma mensagem de confirmação necessária para as alterações e clique em Confirmar & Push para enviar essas alterações por push para o repositório Git remoto.

Se você não tiver permissão para se comprometer com a ramificação padrão (como a main ramificação), crie uma nova ramificação e use a interface do seu provedor Git para criar uma solicitação pull (PR) para mesclá-la na ramificação padrão.

Nota

• As saídas do bloco de notas não são incluídas nas confirmações por predefinição quando os blocos de notas são guardados em formatos de ficheiro de origem (.py, .scala, .sql.r, ). Para obter informações sobre como confirmar saídas de notebook usando o formato IPYNB, consulte Controlar confirmações de artefato de saída de notebook IPYNB

Extrair alterações do repositório Git remoto

Para extrair alterações do repositório Git remoto, clique em Pull na caixa de diálogo de operações Git. Blocos de anotações e outros arquivos são atualizados automaticamente para a versão mais recente em seu repositório Git remoto. Se as alterações extraídas do repositório remoto entrarem em conflito com as alterações locais no Databricks, você precisará resolver os conflitos de mesclagem.

Importante

As operações do Git que puxam as alterações upstream limpam o estado do notebook. Para obter mais informações, consulte Alterações de entrada limpar o estado do bloco de anotações.

Mesclar ramificações

Acesse a operação Git Merge selecionando-a no kebab no canto superior direito da caixa de diálogo de operações do Git.

A função de mesclagem nas pastas Databricks Git mescla uma ramificação em outra usando git mergeo . Uma operação de mesclagem é uma maneira de combinar o histórico de confirmação de uma ramificação para outra; A única diferença é a estratégia que utiliza para o conseguir. Para iniciantes no Git, recomendamos o uso de mesclagem (sobre rebase) porque ele não requer forçar o envio para uma ramificação e, portanto, não reescreve o histórico de confirmação.

• Se houver um conflito de mesclagem, resolva-o na interface do usuário de pastas do Git.
• Se não houver conflito, a mesclagem será enviada por push para o repositório Git remoto usando git pusho .

Rebase uma sucursal noutro ramo

Acesse a operação Git Rebase selecionando-a no menu kebab no canto superior direito da caixa de diálogo de operações Git.

A refundação altera o histórico de confirmação de uma filial. Como git merge, git rebase integra mudanças de um ramo para outro. Rebase faz o seguinte:

1. Salva as confirmações em sua ramificação atual em uma área temporária.
2. Redefine a ramificação atual para a ramificação escolhida.
3. Reaplica cada confirmação individual salva anteriormente na ramificação atual, resultando em um histórico linear que combina alterações de ambas as ramificações.

Aviso

O uso do rebase pode causar problemas de controle de versão para os colaboradores que trabalham no mesmo repositório.

Um fluxo de trabalho comum é rebasear uma ramificação de recurso na ramificação principal.

Para rebasear uma ramificação em outra filial:

1. No menu Ramificação na interface do usuário de pastas do Git, selecione a ramificação que deseja rebasear.

2. Selecione Rebase no menu kebab.

   

3. Selecione a ramificação na qual você deseja rebasear.

   A operação de rebase integra as alterações da ramificação escolhida aqui na ramificação atual.

As pastas Databricks Git são executadas git commit e git push --force para atualizar o repositório Git remoto.

Resolver conflitos de mesclagem

Os conflitos de mesclagem acontecem quando 2 ou mais usuários do Git tentam mesclar alterações nas mesmas linhas de um arquivo em uma ramificação comum e o Git não pode escolher as alterações "certas" a serem aplicadas. Conflitos de mesclagem também podem ocorrer quando um usuário tenta extrair ou mesclar alterações de outra ramificação para uma ramificação com alterações não confirmadas.

Se uma operação como pull, rebase ou merge causar um conflito de mesclagem, a interface do usuário de pastas do Git mostrará uma lista de arquivos com conflitos e opções para resolver os conflitos.

Você tem duas opções principais:

• Use a interface do usuário das pastas Git para resolver o conflito.
• Anule a operação Git, descarte manualmente as alterações no arquivo conflitante e tente a operação Git novamente.

Ao resolver conflitos de mesclagem com a interface do usuário de pastas do Git, você deve escolher entre resolver manualmente os conflitos no editor ou manter todas as alterações recebidas ou atuais.

Mantenha todas as alterações atualizadas ou receba

Se você sabe que deseja manter apenas todas as alterações atuais ou recebidas, clique no kebab à direita do nome do arquivo no painel do bloco de anotações e selecione Manter todas as alterações atuais ou Fazer todas as alterações recebidas. Clique no botão com o mesmo rótulo para confirmar as alterações e resolver o conflito.

Gorjeta

Confuso sobre qual opção escolher? A cor de cada opção corresponde às respetivas alterações de código que ele manterá no arquivo.

Resolução manual de conflitos

A resolução manual de conflitos permite determinar quais das linhas conflitantes devem ser aceitas na mesclagem. Para conflitos de mesclagem, você resolve o conflito editando diretamente o conteúdo do arquivo com os conflitos.

Para resolver o conflito, selecione as linhas de código que deseja preservar e exclua todo o resto, incluindo os marcadores de conflito de mesclagem do Git. Quando terminar, selecione Marcar como resolvido.

Se você decidir que fez as escolhas erradas ao resolver conflitos de mesclagem, clique no botão Cancelar para abortar o processo e desfazer tudo. Quando todos os conflitos estiverem resolvidos, clique na opção Continuar mesclagem ou Continuar rebase para resolver o conflito e concluir a operação.

Git reset

Nas pastas Git do Databricks, você pode executar um Git reset na interface do usuário do Azure Databricks. A redefinição do Git nas pastas do Databricks Git é equivalente à git reset --hard combinação com git push --forceo .

A redefinição do Git substitui o conteúdo e o histórico da ramificação pelo estado mais recente de outra ramificação. Você pode usar isso quando as edições estão em conflito com a ramificação upstream, e você não se importa de perder essas edições quando você redefine para a ramificação upstream. Leia mais sobre o git reset –hard.

Redefinir para uma ramificação upstream (remota)

Com git reset neste cenário:

• Você redefine sua ramificação selecionada (por exemplo, feature_a) para uma ramificação diferente (por exemplo, main).
• Você também redefine a ramificação feature_a upstream (remota) para principal.

Importante

Ao redefinir, você perde todas as alterações não confirmadas e confirmadas na versão local e remota da ramificação.

Para redefinir uma ramificação para uma ramificação remota:

1. Na interface do usuário de pastas do Git no menu Ramificação , escolha a ramificação que deseja redefinir.

   

2. Selecione Redefinir no menu kebab.

   

3. Selecione a ramificação a ser redefinida.

   

Configurar o modo de check-out esparso

O check-out esparso é uma configuração do lado do cliente que permite clonar e trabalhar com apenas um subconjunto dos diretórios dos repositórios remotos no Databricks. Isso é especialmente útil se o tamanho do repositório estiver além dos limites suportados pelo Databricks.

Você pode usar o modo de Checkout Esparso ao adicionar (clonar) um novo repositório.

1. Na caixa de diálogo Adicionar pasta Git, abra Avançado.

2. Selecione Modo de check-out esparso.

   

3. Na caixa Padrões de cone, especifique os padrões de check-out de cone desejados. Separe vários padrões por quebras de linha.

No momento, você não pode desabilitar o check-out esparso para um repositório no Azure Databricks.

Como funcionam os padrões de cone

Para entender como o padrão de cone funciona no modo de check-out esparso, consulte o diagrama a seguir que representa a estrutura do repositório remoto.

Se você selecionar Modo de check-out esparso, mas não especificar um padrão de cone, o padrão de cone padrão será aplicado. Isso inclui apenas os arquivos na raiz e sem subdiretórios, resultando em uma estrutura de repositório da seguinte forma:

Definir o padrão de cone de check-out esparso como parent/child/grandchild resulta em todo o grandchild conteúdo do diretório sendo incluído recursivamente. Os arquivos imediatamente no diretório , /parent/child e raiz /parenttambém estão incluídos. Veja a estrutura de diretórios no diagrama a seguir:

Você pode adicionar vários padrões separados por quebras de linha.

Nota

Os comportamentos de exclusão (!) não são suportados na sintaxe do padrão de cone Git.

Modificar configurações de check-out esparsas

Depois que um repositório é criado, o padrão de cone de checkout esparso pode ser editado a partir de Padrões de cone avançados de configurações>.>

Tenha em atenção o seguinte comportamento:

• A remoção de uma pasta do padrão de cone a remove do Databricks se não houver alterações não confirmadas.

• Adicionar uma pasta através da edição do padrão de cone de checkout esparso adiciona-a ao Databricks sem exigir um pull adicional.

• Padrões de check-out esparsos não podem ser alterados para remover uma pasta quando há alterações não confirmadas nessa pasta.

  Por exemplo, um usuário edita um arquivo em uma pasta e não confirma alterações. Em seguida, ela tenta alterar o padrão de check-out esparso para não incluir essa pasta. Nesse caso, o padrão é aceito, mas a pasta real não é excluída. Ela precisa reverter o padrão para incluir essa pasta, confirmar alterações e, em seguida, reaplicar o novo padrão.

Nota

Não é possível desativar o check-out esparso para um repositório que foi criado com o modo de check-out esparso ativado.

Faça e envie alterações com checkout esparso

Você pode editar arquivos existentes e confirmá-los e enviá-los por push da pasta Git. Ao criar novas pastas de arquivos, inclua-as no padrão de cone especificado para esse repositório.

A inclusão de uma nova pasta fora do padrão de cone resulta em um erro durante a operação de confirmação e envio. Para corrigi-lo, edite o padrão de cone para incluir a nova pasta que você está tentando confirmar e enviar.

Padrões para um arquivo de configuração de repositório

O arquivo de configuração de saídas de confirmação usa padrões semelhantes aos padrões gitignore e faz o seguinte:

• Padrões positivos permitem a inclusão de saídas para notebooks correspondentes.
• Padrões negativos desativam a inclusão de saídas para blocos de anotações correspondentes.
• Os padrões são avaliados em ordem para todos os notebooks.
• Caminhos inválidos ou caminhos que não resolvem para .ipynb blocos de anotações são ignorados.

Padrão positivo: para incluir saídas de um caminho folder/innerfolder/notebook.ipynbde bloco de anotações, use os seguintes padrões:

**/*
folder/**
folder/innerfolder/note*

Padrão negativo: para excluir saídas de um bloco de anotações, verifique se nenhum dos padrões positivos corresponde ou adicione um padrão negativo em um local correto do arquivo de configuração. Os padrões negativos (excluir) começam com !:

!folder/innerfolder/*.ipynb
!folder/**/*.ipynb
!**/notebook.ipynb

Limitação de checkout esparsa

Atualmente, o checkout esparso não funciona para repositórios de DevOps do Azure maiores que 4 GB.

Adicione um repositório e conecte-se remotamente mais tarde

Para gerenciar e trabalhar com pastas Git programaticamente, use a API REST de pastas Git.