Executar operações Git em pastas Git Databricks

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

Podes criar pastas Git usando a interface do Databricks ou o terminal web.

Clone da interface do utilizador

1. Na barra lateral, selecione Workspace e depois navegue até à pasta onde quer criar o clone do repositório Git.

2. Clica em Criar>pasta Git.

   

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

   Campo	Description
   URL do repositório Git	A URL do repositório Git que você deseja clonar, no formato https://example.com/organization/project.git
   Fornecedor 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)
   Nome da pasta Git	O nome da pasta em seu espaço de trabalho que conterá o conteúdo do repositório clonado
   Checkout esparso	Se deve utilizar checkout esparso, onde apenas um subconjunto dos diretórios do seu repositório é clonado, especificado usando um padrão em cone. Isso é útil se o seu repositório for maior do que os limites suportados pelo Databricks.
   Usa Git CLI (Beta)	Permitir a execução de comandos Git padrão diretamente a partir de um terminal Databricks. Isto proporciona acesso a operações avançadas como ganchos de pré-commit, submódulos Git e Armazenamento de Ficheiros Grandes (LFS). Veja Usar comandos Git CLI (Beta).

4. 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.

Clonar a partir do terminal web

Também pode criar pastas Git com acesso à CLI diretamente a partir do terminal web:

1. Aceda ao terminal web. Consulte Executar comandos de shell no terminal Web do Azure Databricks.

2. Navegue até ao diretório principal em /Workspace:

   cd /Workspace/Users/<your-email>/<project>
   

   Nota

   Não podes criar pastas Git com acesso à CLI Git dentro /Repos ou dentro das pastas Git existentes.

3. Clone o seu repositório:

   git clone <remote-url>
   

   O git clone comando utiliza as credenciais Git configuradas no seu espaço de trabalho. Consulte Configurar credenciais do Git & conectar um repositório remoto ao Azure Databricks.

4. Atualize o seu navegador para ver a nova pasta no navegador de ficheiros do espaço de trabalho.

Usar comandos Git CLI (Beta)

Pastas Git com acesso Git CLI permitem executar comandos Git padrão diretamente a partir de um terminal Databricks. É possível:

• Execute qualquer comando Git, incluindo git stash, git pull --force, e git rebase -i.
• Integra linting e análise de código com hooks de pré-commit.
• Trabalhe com repositórios que excedam os limites de 2 GB de memória e 4 GB de disco das pastas Git padrão.
• Use submódulos Git e Armazenamento de Ficheiros Grandes (LFS).
• Fasear múltiplos commits localmente antes de enviar para o repositório remoto.

Para usar o acesso Git CLI, o seu espaço de trabalho deve ter computação serverless ativada com ambiente versão 4 ou superior.

Criar uma pasta Git com acesso à CLI Git

Para criar uma pasta Git com acesso a CLI:

• Ao usar o terminal web, qualquer repositório que clones tem acesso automático ao Git CLI.
• Ao usar a UI, deve ativar a pré-visualização de Use Git CLI ao criar a pasta Git.

Depois de criar uma pasta Git com acesso à CLI, execute qualquer comando Git padrão a partir do terminal web:

cd /Workspace/Users/<your-email>/<project>/my-repo

# Interactive rebase
git rebase -i main

# Stash uncommitted changes
git stash

# Work with submodules
git submodule update --init --recursive

Limitações da CLI do Git

Pastas Git com acesso a CLI apresentam as seguintes limitações:

• Espaços de trabalho com listas de permissões de URLs remotas ativadas não conseguem utilizar as funcionalidades da Interface de Linha de Comandos do Git.
• Os comandos Git CLI ignoram a definição de administrador que bloqueia fazer commit dos outputs do notebook.
• A API dos repositórios não é suportada para pastas Git com acesso à linha de controlo (CLI).
• Não podes ativar o acesso à CLI do Git para pastas Git existentes.

Resolução de problemas nas operações da CLI Git

• O terminal pede credenciais em todas as operações: A funcionalidade Git CLI não está ativada no seu espaço de trabalho. Contacta o administrador do teu espaço de trabalho para verificar se a pré-visualização está ativada.
• Não é possível ativar o acesso à CLI: Espaços de trabalho com listas de URL remotas não podem usar funcionalidades da CLI do Git. Contacte o administrador do seu espaço de trabalho para rever a configuração da rede do seu espaço de trabalho.
• As operações Git falham com erros de permissões: Verifique se possui a permissão necessária na pasta principal e se as credenciais Git do seu espaço de trabalho são válidas. Consulte Configurar credenciais do Git & conectar um repositório remoto ao Azure Databricks.

Prática recomendada: Colaborando em pastas Git

As pastas Git do Databricks comportam-se como clientes Git embutidos no seu espaço de trabalho, permitindo-lhe colaborar através de controlo de versões e versionamento baseados em Git. Para uma colaboração eficaz em equipa:

• Cada membro da equipa tem a sua própria pasta Git mapeada para o repositório Git remoto, onde trabalha no seu próprio ramo de desenvolvimento.
• Apenas um utilizador realiza operações Git em cada pasta Git. Vários utilizadores a realizar operações Git na mesma pasta podem causar problemas de gestão de branches, como um utilizador mudar inadvertidamente de branch, afetando todos.

Para partilhar a configuração da sua pasta Git com um colaborador:

1. Clique em Copiar o link para criar a pasta Git no banner no topo do seu espaço de trabalho Databricks.
2. Envia a URL ao teu colaborador.
3. Quando o seu colaborador abre a URL, vê uma caixa de diálogo Criar pasta Git pré-preenchida com a configuração da sua pasta Git.
4. Eles clicam em Criar pasta Git para clonar o repositório no seu próprio espaço de trabalho, na pasta de trabalho atual.

Para copiar uma pasta Git de outro utilizador:

1. Abra a pasta Git do outro utilizador no espaço de trabalho partilhado.
2. Clique Criar pasta Git na barra no topo. O diálogo Criar pasta Git abre com a configuração do repositório Git pré-preenchida.
3. Clica em Criar pasta Git para clonar o repositório no teu próprio espaço de trabalho.

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 no canto superior direito para escolher entre operações adicionais de ramificação do Git, como um reset, uma mesclagem ou um 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:

As alterações não confirmadas na ramificação atual serão transferidas e mostradas como alterações não confirmadas na nova ramificação, se as alterações não confirmadas não entrarem em conflito com o código na nova ramificação. Elimine as alterações antes ou depois das mudanças de ramificação se não pretender transferir as alterações não confirmadas.

A versão local de uma ramificação pode permanecer presente na pasta Git associada por até 30 dias após a ramificação remota ser excluída. Para remover completamente uma ramificação local em uma pasta Git, exclua 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.

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.

Mesclar ramificações

Acesse a operação Git Merge selecionando-a no ícone do 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 fusão, resolva-o na interface das pastas do Git.
• Se não houver conflito, a fusão é feita por push para o repositório Git remoto usando git push.

Rebase uma sucursal noutro ramo

Acesse a operação Git Rebase selecionando-a no ícone do no canto superior direito do 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.

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 de ramificação do 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.

Para atualizar o repositório Git remoto, são executadas as operações git commit e git push --force nas pastas Databricks Git.

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 apenas deseja manter 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.

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 a git reset --hard combinado com git push --force.

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 upstream (remota) feature_a para principal.

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

1. Na interface de pastas Git no menu da 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 checkout esparso é uma configuração do lado do cliente que permite clonar e trabalhar apenas com um subconjunto de diretórios dos repositórios remotos em 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 o modo de checkout 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.

Neste momento, você não pode desativar o checkout esparso de 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 e raiz /parent/childtambé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.

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 >.>

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.

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.

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.

Apagar uma pasta Git

Para remover uma pasta Git do seu espaço de trabalho:

1. Clique com o botão direito na pasta Git e selecione Mover para o lixo.
2. Escreve o nome da pasta Git para confirmar.
3. Clique em Confirmar e mova para a lixeira.