Criar e gerenciar pastas do Git

Esta página descreve como criar pastas Git do Azure Databricks e executar operações comuns do Git, incluindo clonagem, ramificação, confirmação e envio por push.

Este guia aborda as seguintes operações do Git:

Clonar um repositório

Quando você clona um repositório remoto, o Databricks cria uma pasta Git em seu workspace que contém o conteúdo do repositório e rastreia as alterações. Você pode criar pastas git usando a interface do usuário do Azure Databricks ou o terminal Web.

Clonar da interface do usuário

1. Na barra lateral, selecione Workspace e navegue até a pasta na qual você deseja criar o clone do repositório Git.

2. Clique em 'Criar' >.

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.
   Provedor Git	O provedor Git para o repositório que você deseja clonar.
   Nome da pasta Git	O nome da pasta em seu workspace que contém o conteúdo do repositório clonado.
   Modo sparse checkout	Se deve usar sparse checkout, que clona apenas um subconjunto dos diretórios do seu repositório usando um padrão de clone. Isso será útil se o repositório exceder os limites de tamanho.

4. Clique em Criar pasta Git. O conteúdo do repositório remoto é clonado na sua área de trabalho, e você pode começar a trabalhar com operações Git suportadas. Quando seu espaço de trabalho é elegível, a pasta Git é criada automaticamente com acesso à CLI do Git. Veja Quando uma pasta do Git passa a ter acesso à CLI do Git?.

Clonar a partir do terminal web

Você também pode criar pastas Git com acesso à CLI diretamente do terminal Web:

1. Acesse o terminal da Web. Confira Executar comandos shell no terminal web do Azure Databricks.

2. Navegue até o diretório pai em /Workspace:

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

3. Clone seu repositório:

   git clone <remote-url>
   

   O git clone comando usa as credenciais do Git configuradas em seu workspace. Consulte Conectar seu provedor Git ao Databricks.

4. Atualize o navegador para ver a nova pasta no navegador de arquivos do workspace.

Usar comandos da CLI do Git

As pastas Git com acesso à CLI do Git permitem executar comandos Git padrão na computação sem servidor, em um notebook, no terminal da Web ou no Genie Code. É possível:

• Execute qualquer comando Git, incluindo git stash, git push --forcee git rebase -i.
• Integre linting e varredura de código com hooks de pre-commit.
• Trabalhe com repositórios que excedem a memória de 2 GB e os limites de disco de 4 GB das pastas Git padrão.
• Use submódulos Git e LFS (Armazenamento de Arquivos Grandes).
• Prepare múltiplos commits localmente antes de enviá-los para o repositório remoto.

Requisitos de computação da CLI do Git

A computação necessária depende de como você usa uma pasta Git habilitada para CLI:

Para habilitar a computação sem servidor, consulte Conectar-se à computação sem servidor.

Se o provedor Git exigir conectividade de rede privada, consulte Configurar conectividade de rede.

Quando uma pasta git obtém acesso à CLI do Git?

Ao criar uma pasta Git a partir da UI, o Azure Databricks habilita automaticamente o acesso via CLI do Git, caso seu workspace seja elegível. Se o seu workspace não for elegível, o Azure Databricks cria uma pasta Git padrão, e você ainda pode realizar operações Git a partir da interface de pastas Git.

Uma pasta git que você cria com base na interface do usuário obtém acesso à CLI do Git quando todos os seguintes são verdadeiros:

• A versão prévia da CLI do Git está habilitada para seu workspace. Os administradores do workspace controlam isso na página Visualizações . Consulte Gerenciar visualizações do Azure Databricks.
• A computação sem servidor está disponível em seu workspace. Consulte Conectar-se ao computador sem servidor.
• Azure Databricks pode acessar seu provedor Git por meio da computação sem servidor. Azure Databricks verifica a conectividade antes de clonar o repositório. Se o provedor Git exigir conectividade de rede privada, consulte Configurar conectividade de rede.
• Durante a Visualização Pública, os repositórios são limitados a 10.000 arquivos. Repositórios que excedem esse limite são clonados como pastas Git padrão.

As pastas git que você clona do terminal Web sempre têm acesso à CLI do Git.

Criar uma pasta Git com acesso à CLI do Git

Para criar uma pasta Git com acesso à CLI:

• Se você usar a UI, o Azure Databricks criará automaticamente a pasta Git com acesso à CLI do Git quando seu espaço de trabalho for elegível. Veja Quando uma pasta do Git passa a ter acesso à CLI do Git?. Se o workspace não for elegível, o Azure Databricks criará uma pasta Git padrão.
• Se você usar o terminal Web, qualquer repositório que você clonar terá acesso à CLI do Git automaticamente.

Depois de criar uma pasta Git com acesso à CLI, execute qualquer comando Git padrão no terminal Da Web. Para abrir um terminal Web, consulte Iniciar o 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

As pastas Git com acesso à CLI têm as seguintes limitações:

• As listas de permissões de URL do Git se aplicam às operações do Git executadas na interface do usuário do Azure Databricks, mas não são impostas para comandos git executados diretamente com a CLI do Git.
• Pastas Git com acesso à CLI do Git não são retornadas pela API List Repos.

Solucionar problemas de operações da CLI do Git

• As operações do Git estão desabilitadas na interface do usuário do workspace: a computação sem servidor não está habilitada em seu workspace. Você ainda pode executar comandos do Git no terminal da Web. Para habilitar a computação sem servidor, consulte Conectar-se à computação sem servidor.
• O Terminal solicita que você selecione uma credencial: as operações da CLI do Git usam automaticamente suas credenciais do Git armazenadas no espaço de trabalho. Azure Databricks infere o provedor Git da URL remota e usa a credencial padrão para esse provedor. Se Azure Databricks não conseguir identificar uma única credencial a ser usada, será solicitado que você selecione uma. Para evitar o prompt, defina a DB_GIT_CREDENTIAL_NAME variável de ambiente como o nome da credencial que você deseja usar. Azure Databricks lembra a credencial que você usa para um repositório e a reutiliza.
• As operações do Git falham com erros de permissão: Verifique se você tem permissão na pasta pai e se as credenciais do Git do espaço de trabalho são válidas. Consulte Conectar seu provedor Git ao Databricks.

Acessar a caixa de diálogo do Git

Acesse a caixa de diálogo Git de um notebook ou do navegador de pastas Git do Azure Databricks.

• Em um notebook, clique no botão ao lado do nome do notebook que identifica a branch do Git atual.

  

• No navegador de pastas Git do Azure Databricks, clique em Git ao lado do nome do repositório.

Uma caixa de diálogo de tela inteira é exibida onde você pode executar operações do Git.

1. Seu branch de trabalho atual. Você pode selecionar outras ramificações aqui. Se outros usuários tiverem acesso a esta pasta do Git, alterar a branch também altera a branch para eles, caso compartilhem o mesmo workspace. Veja uma prática recomendada para evitar esse problema.
2. Crie uma nova ramificação.
3. Arquivos de recursos e subpastas incluídos na sua branch atual.
4. Exiba o histórico da branch atual.
5. Fazer pull de conteúdo do repositório Git remoto.
6. Adicione uma mensagem de confirmação e uma descrição expandida opcional para suas alterações.
7. Envie seu trabalho para a branch de trabalho e envie a branch atualizada para o repositório Git remoto.

Clique no menu de três pontos para escolher entre operações adicionais de branch do Git, como hard reset, merge ou rebase.

Criar uma nova ramificação

Para criar um novo ramo:

1. Abra a caixa de diálogo Git.
2. Clique em Criar Branch.
3. Insira um nome para o novo branch e selecione o branch base.
4. Clique em Criar.

Mudar para outra branch

Para mudar para uma branch diferente, use o menu suspenso de branches na caixa de diálogo do Git:

Alterações não confirmadas no branch atual são transferidas e mostradas como alterações não confirmadas no novo branch, se as alterações não confirmadas não entrarem em conflito com o código no novo branch. Descarte as alterações antes ou depois de alternar de branch, caso não pretenda levar consigo as alterações não confirmadas.

A versão local de um branch pode permanecer presente na pasta Git associada por até 30 dias depois que você excluir o branch remoto. Para remover completamente um branch local em uma pasta Git, exclua o repositório.

Confirmar e enviar alterações

Quando você adiciona novos notebooks ou arquivos ou faz 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 & Enviar por push para enviar as alterações por push para o repositório Git remoto.

Se você não tiver permissão para se comprometer com o branch padrão, crie uma nova ramificação e use a interface do provedor Git para criar uma solicitação de pull e mesclá-la no branch padrão.

Realizar commits em uma pasta Git assumindo uma função específica

Com o RBAC, você assume um papel para acessar dados no escopo desse papel. Para escrever o código que lê esses dados, você assume a função para que o acesso aos dados dela entre em vigor e, em seguida, confirma as alterações. Você pode realizar o commit usando sua própria identidade de usuário ou a função (role). A escolha determina como seu provedor Git atribui os commits, em contrapartida ao nível de configuração que o fluxo de trabalho exige. Ambas dependem da credencial Git da função.

Confirmar com sua identidade de usuário

Nessa abordagem, você faz commits com suas credenciais pessoais do Git, de modo que seu provedor Git atribua os commits a você. Você assume a função apenas para realizar operações de gravação nos dados que ela permite acessar e, em seguida, retorna à sua identidade de usuário para efetivar as alterações (commit). Como você realiza a autoria assumindo uma determinada função, mas faz o commit com sua identidade de usuário, a pasta do Git deve estar acessível sob ambas as identidades. Configure isso de duas maneiras, que diferem em quem possui a pasta e em qual direção você a compartilha.

Opção 1: clone na sua pasta pessoal e compartilhe com a função

1. Usando sua identidade de usuário (sem assumir a função), clone o repositório em uma pasta Git no seu diretório pessoal (/Workspace/Users/<your-username>/...). Consulte Clonar um repositório. O clone usa sua credencial pessoal do Git e você é o proprietário da pasta. A função não precisa de sua própria credencial git para essa opção.
2. Conceda à função acesso à pasta (Pode Executar ou Pode Editar se a função precisar modificar arquivos) para que você possa trabalhar nela enquanto atua como a função.
3. Suponha a função e faça as alterações na pasta. O acesso a dados da função está em vigor.
4. Volte para sua identidade de usuário e, em seguida, faça commit e push. O commit utiliza seus git_username e git_email pessoais.

Como você compartilha a pasta da identidade do usuário para a função, os controles de compartilhamento de ativos do workspace não afetam essa opção. Esses controles restringem apenas uma função de compartilhar ativos externamente.

Opção 2: clone na pasta pessoal da função e compartilhe com sua identidade de usuário

1. Suponha a função e clone o repositório em uma pasta Git na pasta inicial da função. O clone usa a credencial Git da função, que deve ter pelo menos acesso de leitura.
2. Ao assumir a função, conceda à sua identidade de usuário acesso à pasta (Can Edit).
3. Faça suas alterações enquanto estiver na função. O acesso a dados da função está em vigor.
4. Volte para sua identidade de usuário. Como você concedeu acesso ao usuário, pode acessar a pasta, portanto, confirme e envie por push com sua credencial pessoal. O commit utiliza seus git_username e git_email pessoais.

Como a função compartilha a pasta externamente com a sua identidade de usuário, essa opção não funciona se a função estiver na lista de negação dos controles de compartilhamento de ativos do workspace. Use a opção 1 para essas funções.

Commit como a função

Nesta abordagem, você realiza o clone, a autoria e o commit, tudo isso assumindo a função em questão. Esse é o fluxo de trabalho mais simples: você não compartilha uma pasta ou alterna identidades para confirmar. É necessário que a credencial do Git da função tenha permissão de gravação, pois a interface do workspace realiza o commit e o push em uma única ação.

1. Assuma o papel.
2. Clone o repositório em uma pasta Git. Como você está atuando como a função, o clone usa a credencial Git da função.
3. Faça suas alterações e, em seguida, faça commit e faça push. O commit utiliza git_username e git_email da função.

Avalie estas implicações antes de escolher essa abordagem:

• A atribuição ocorre no nível da função. Os commits no seu provedor Git mostram a identidade Git da função, não a do autor individual. Os logs de auditoria do Azure Databricks registram tanto identity_metadata.run_as (a função) quanto identity_metadata.run_by (você) para commits realizados por meio da interface do usuário do workspace. Isso não se aplica a confirmações de Git brutas executadas da CLI do Git em um terminal Web, o que Azure Databricks não atribui a um usuário individual.
• A credencial Git da função é compartilhada e possui permissão de gravação. Todos que assumem a função utilizam a mesma credencial para realizar operações de push; portanto, um token vazado ou utilizado indevidamente pode ser usado para enviar alterações, excluir branches ou criar commits sob a identidade da função. Por isso, o Azure Databricks recomenda o uso de uma credencial Git de grupo somente leitura e a abordagem de fazer o commit com sua identidade de usuário. Use credenciais com permissão de gravação apenas quando aceitar essas contrapartidas. Consulte as permissões de token. Restrinja o escopo da credencial somente aos repositórios de que a função precisa.

Alterações de pull

Para fazer pull de alterações do repositório Git remoto, clique em Pull na caixa de diálogo de operações do Git. Notebooks 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 Azure Databricks, resolva os conflitos de mesclagem.

Colaborar em pastas Git

As pastas Git do Azure Databricks se comportam como clientes Git inseridos em seu workspace, permitindo que você colabore por meio do controle do código-fonte e controle de versão baseado em Git. Para colaboração em equipe eficaz:

• Cada membro da equipe possui sua própria pasta Git mapeada para o repositório Git remoto, onde trabalha em sua própria branch de desenvolvimento.
• Apenas um usuário executa operações git em cada pasta Git. Usuários múltiplos realizando operações Git na mesma pasta podem causar problemas de gerenciamento de ramificações, como um usuário alternando ramificações involuntariamente e afetando todos os usuários.

Para compartilhar sua configuração de pasta git com um colaborador:

1. Clique em Compartilhar.
2. Clique em Copiar link para criar a pasta git.
3. Envie a URL para o colaborador.
4. Quando o colaborador abre a URL, ele vê uma caixa de diálogo pré-preenchida com a configuração da pasta Git.
5. Eles clicam em Criar pasta Git para clonar o repositório em sua própria área de trabalho no diretório de trabalho atual.

Mesclar ramificações

A função de mesclagem nas pastas Git do Azure Databricks utiliza git merge para combinar o histórico de commits de uma branch em outra. Para iniciantes do Git, o Databricks recomenda usar a mesclagem em vez de rebasear porque não requer push forçado e não reescreve o histórico de confirmação.

Para mesclar uma ramificação em outra, clique no Menu de kebab e selecione Mesclagem.

• Se houver um conflito de mesclagem, resolva-o na interface de usuário das pastas do Git.
• Se não houver conflito, a mesclagem envia as alterações para o repositório Git remoto usando git push.

Resolver conflitos de mesclagem

Conflitos de mesclagem ocorrem quando o Git não consegue reconciliar automaticamente as alterações nas mesmas linhas de um arquivo de diferentes fontes, como durante uma operação de pull, rebase ou mesclagem.

Para resolver um conflito de mesclagem, use a interface do usuário para pastas do Git, que exibe arquivos conflitantes e opções de resolução.

• Edite manualmente o arquivo para escolher quais alterações manter.
• Selecione Manter todas as alterações atuais ou Fazer todas as alterações de entrada para aceitar uma versão inteiramente.
• Anule a operação e descarte alterações conflitantes para tentar novamente.

Resolver conflitos manualmente

A resolução manual de conflitos permite determinar quais linhas conflitantes aceitar. Edite o conteúdo do arquivo diretamente para resolver 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ê fez as escolhas erradas ao resolver conflitos de mesclagem, clique em Anular para anular o processo e desfazer tudo. Depois que todos os conflitos forem resolvidos, clique em Continuar Mesclagem ou Continuar Rebase para resolver o conflito e concluir a operação.

Fazer rebase de branch

A função de rebase nas pastas Git do Azure Databricks usa git rebase para integrar alterações de um branch em outro, reaplicando suas confirmações na parte superior do branch de destino, criando um histórico linear.

Para realizar o rebase de uma ramificação em outra, clique no e selecione Rebase, depois selecione a ramificação de destino.

• Após a rebase, os diretórios Git git commit e git push --force são executados para atualizar o repositório remoto.
• A rebase reescreve o histórico de confirmação, o que pode causar problemas de controle de versão para colaboradores que trabalham no mesmo repositório.

Redefinir branch

Realize uma redefinição do Git pela interface de pastas do Git. Essa operação é equivalente a git reset --hard combinado com git push --force.

O Git reset substitui o histórico e o conteúdo da ramificação pelo estado mais recente de outra ramificação. Você pode usar isso quando houver conflito entre suas alterações e a branch upstream, e não se importar em perder essas alterações ao fazer o reset para a branch upstream. Leia mais sobre git reset --hard.

Redefinir para um branch remoto

Neste cenário, com git reset:

• Você redefiniu a 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 do usuário das pastas Git, no menu Branch, escolha a ramificação que você deseja redefinir.

2. Selecione Reset no menu de três pontos .

   

3. Selecione o branch para redefinir e clique em Executar Redefinição do Git.

Configurar o modo sparse checkout

Sparse checkout é uma configuração no lado do cliente que permite clonar e trabalhar apenas com um subconjunto dos diretórios do repositório remoto no Azure Databricks. Isso é especialmente útil se o tamanho do repositório exceder os limites com suporte do Azure Databricks.

Habilite o modo de checkout esparso ao clonar um novo repositório. Você não pode desativar o modo sparse checkout depois de ativá-lo.

1. Na caixa de diálogo Criar pasta Git, habilite o modo sparse checkout.

   

2. Na caixa Padrões de cone, especifique os padrões de check-out de cone desejados. Separe múltiplos padrões por quebras de linha.

Como funcionam os padrões de cone

Para entender como os padrões de cone funcionam no modo sparse checkout, consulte o diagrama a seguir, que representa a estrutura do repositório remoto.

Se você selecionar modo sparse checkout, 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 maneira:

Definir o padrão de cone do sparse checkout como parent/child/grandchild inclui recursivamente todo o conteúdo do diretório grandchild. Os arquivos imediatamente em /parent, /parent/child e no diretório raiz também são incluídos. Consulte a estrutura do diretório no seguinte diagrama:

Modificar as configurações do check-out esparso

Após criar um repositório, edite o padrão de cone de sparse checkout em Configurações>Avançado>Padrões de cone.

Observe o seguinte comportamento:

• Remover uma pasta do padrão de cone a remove do Azure Databricks, caso não haja alterações não confirmadas.

• Adicionar uma pasta editando o padrão de cone de sparse checkout a inclui no Azure Databricks sem exigir um pull adicional.

• Os padrões de sparse checkout não podem ser alterados para remover uma pasta quando houver alterações não confirmadas nessa pasta.

  Por exemplo, se você editar um arquivo em uma pasta e não confirmar alterações, tente alterar o padrão de check-out esparso para excluir essa pasta, o padrão será aceito, mas a pasta não será excluída. Você precisa reverter o padrão para incluir essa pasta, confirmar suas alterações e, em seguida, reaplicar o novo padrão.

Fazer alterações usando o sparse checkout

Edite arquivos existentes e confirme e faça o push a partir do diretório Git. Ao criar novas pastas de arquivos, inclua-as no padrão de cone que você especificou para esse repositório.

Incluir uma nova pasta fora do padrão de cone resulta em um erro durante a operação de commit e push. Para corrigir isso, edite o padrão do cone para incluir a nova pasta que você está tentando fazer o commit e o push.

Limitações do sparse checkout

• O sparse checkout não funciona para repositórios do Azure DevOps maiores que 4 GB.
• Não é possível desativar o sparse checkout para um repositório que foi criado com o sparse checkout ativado.

Gerenciar pastas git programaticamente

Para gerenciar pastas Git usando a API, consulte a referência da API de Repos.

Excluir uma pasta do Git

Para remover uma pasta Git do workspace:

1. Clique com o botão direito do mouse na pasta Git e selecione Mover para Lixeira.
2. Clique em Confirmar e mover para a Lixeira.

Próximas etapas

• Configure a autenticação para conectar o Azure Databricks ao seu provedor Git. Consulte Conectar seu provedor Git ao Databricks.
• Saiba mais sobre limites de tamanho e outras restrições para pastas Git. Consulte limites de pasta e referências do Git no Azure Databricks.
• Defina as configurações no nível do workspace para a integração do Git. Consulte Configurar a integração do Git para pastas Git.