Criar e gerir pastas Git

Esta página descreve como criar pastas Git no Azure Databricks e realizar operações Git comuns, tais como clonagem, criação de ramificações, confirmação (commit) e empurrar.

Este guia cobre as seguintes operações Git:

Clonar um repositório

Quando clonas um repositório remoto, o Databricks cria uma pasta Git no teu espaço de trabalho que contém o conteúdo do repositório e regista as alterações. Pode criar pastas Git usando a interface do Azure Databricks ou o terminal web.

Clone da interface do utilizador

1. Na barra lateral, selecione Workspace e 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 queres clonar, no formato https://example.com/organization/project.git.
   Fornecedor Git	O provedor Git para o repositório que você deseja clonar.
   Nome da pasta Git	O nome da pasta no teu espaço de trabalho que contém o conteúdo do repositório clonado.
   Modo de verificação esparsa	Se deve usar sparse checkout, que clona apenas um subconjunto dos diretórios do seu repositório usando um padrão de cone. Isto é útil se o seu repositório ultrapassar os limites de tamanho.

4. Clique em Criar pasta Git. O conteúdo do repositório remoto é clonado para o seu espaço de trabalho, e pode começar a trabalhar com operações Git suportadas. Quando o seu espaço de trabalho for elegível, a pasta Git é criada automaticamente com acesso à CLI do Git. Veja : Quando é que uma pasta Git tem acesso à CLI Git?.

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>
   

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. Veja Ligar o seu fornecedor Git ao Databricks.

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

Usar comandos Git CLI

Pastas Git com acesso Git CLI permitem executar comandos Git padrão em computação serverless, a partir de um portátil, do terminal web ou do Genie Code. É possível:

• Execute qualquer comando Git, incluindo git stash, git push --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.

Requisitos de computação da CLI do Git

O cálculo necessário depende de como usa uma pasta Git com CLI:

Para permitir computação serverless, veja Conectar à computação serverless.

Se o seu fornecedor Git requer conectividade de rede privada, veja Configurar conectividade de rede.

Quando é que uma pasta Git tem acesso à CLI do Git?

Quando cria uma pasta Git a partir da IU, o Azure Databricks ativa automaticamente o acesso à CLI do Git, se a sua área de trabalho for elegível. Se o seu espaço de trabalho não for elegível, o Azure Databricks cria uma pasta Git padrão em vez disso, e ainda pode realizar operações Git a partir da interface das pastas Git.

Uma pasta Git que crias a partir da interface recebe acesso à CLI Git quando todas as seguintes situações são verdadeiras:

• A pré-visualização da CLI do Git está ativada para o seu espaço de trabalho. Os administradores do espaço de trabalho controlam isto a partir da página de Pré-visualizações . Consulte Gerenciar visualizações do Azure Databricks.
• A computação sem servidor está disponível no seu espaço de trabalho. Consulte como se conectar à computação sem servidor.
• O Azure Databricks pode aceder ao seu fornecedor de Git a partir da computação sem servidor. O Azure Databricks verifica a conectividade antes de clonar o repositório. Se o seu fornecedor Git requer conectividade de rede privada, veja Configurar conectividade de rede.
• Durante a Pré-visualização Pública, os repositórios estão limitados a 10.000 ficheiros. Os repositórios que excedem este limite são clonados como pastas Git normais.

As pastas Git que clonas do terminal web têm sempre acesso à CLI do Git.

Criar uma pasta Git com acesso à CLI Git

Para criar uma pasta Git com acesso a CLI:

• Se utilizar a IU, o Azure Databricks cria automaticamente a pasta Git com acesso à CLI do Git quando o seu espaço de trabalho for elegível. Veja : Quando é que uma pasta Git tem acesso à CLI Git?. Se o seu espaço de trabalho não for elegível, o Azure Databricks cria uma pasta Git padrão em vez disso.
• Se usares o terminal web, qualquer repositório que clones tem acesso automático à CLI do Git.

Depois de criares uma pasta Git com acesso à CLI, executa qualquer comando Git padrão a partir do terminal web. Para abrir um terminal web, veja Lançar 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

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

• As listas de URLs de Git permitidas aplicam-se às operações Git que executa a partir da IU do Azure Databricks, mas não são impostas aos comandos Git que executa diretamente com a CLI do Git.
• Os repositórios Git acessíveis através da CLI do Git não são devolvidos pela API List Repos.

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

• As operações Git estão desativadas na interface do espaço de trabalho: a computação serverless não está ativada no seu espaço de trabalho. Ainda podes executar comandos Git a partir do terminal web. Para permitir computação serverless, veja Conectar à computação serverless.
• O Terminal pede-lhe para selecionar uma credencial: As operações Git CLI utilizam automaticamente as credenciais Git do seu espaço de trabalho armazenado. O Azure Databricks infere o fornecedor Git a partir da URL remota e usa a credencial padrão desse fornecedor. Se o Azure Databricks não conseguir identificar uma única credencial a usar, é solicitado que selecione uma. Para evitar o prompt, defina a DB_GIT_CREDENTIAL_NAME variável ambiente com o nome da credencial que pretende usar. O Azure Databricks lembra-se da credencial que usa para um repositório e reutiliza-a.
• 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. Veja Ligar o seu fornecedor Git ao Databricks.

Acesse a caixa de diálogo do Git

Acede ao diálogo Git a partir de um caderno ou do navegador de pastas Git do Azure Databricks.

• A partir de um caderno, clique no botão ao lado do nome do caderno que identifica o ramo Git atual.

  

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

Aparece um diálogo em ecrã inteiro onde podes realizar operações Git.

1. O seu ramo de trabalho atual. Você pode selecionar outras filiais aqui. Se outros utilizadores tiverem acesso a esta pasta Git, modificar a ramificação também altera a ramificação para eles se partilharem o mesmo espaço de trabalho. Consulte uma prática recomendada para evitar esse problema.
2. Crie uma nova ramificação.
3. Arquivos e subpastas adicionados ao seu ramo atual.
4. Mostrar o histórico do ramo atual.
5. Extrai conteúdo do repositório remoto do Git.
6. Adicione uma mensagem de commit e uma descrição expandida opcional para as suas alterações.
7. Compromete o teu trabalho no branch de trabalho e empurra o branch atualizado para o repositório Git remoto.

Clique no Menu Kebab para escolher entre operações adicionais de branch Git, como um hard reset, merge ou rebase.

Criar um novo ramo

Para criar uma nova filial:

1. Abre o diálogo do Git.
2. Clique em Criar ramificação.
3. Introduza um nome para o novo ramo e selecione o ramo base.
4. Clique em Criar.

Muda para outro ramo

Para selecionar um ramo diferente, use o menu dropdown de ramos na caixa de diálogo Git.

Alterações não comprometidas no branch atual são mantidas e aparecem como alterações não comprometidas no novo branch, se as alterações não comprometidas não entrarem em conflito com o código do novo branch. Descarta as alterações antes ou depois das trocas de branch se não tencionares transferir as alterações não comprometidas.

A versão local de um branch pode permanecer presente na pasta Git associada até 30 dias após eliminar o branch remoto. Para remover completamente uma ramificação local em uma pasta Git, exclua o repositório.

Comprometer e enviar alterações

Quando adicionas novos cadernos ou ficheiros, ou fazes alterações a cadernos ou ficheiros existentes, a interface da pasta Git destaca as alterações.

Adicione uma mensagem de commit obrigatória para as alterações e clique em Commit & Push para enviar as alterações para o repositório Git remoto.

Se não tiveres permissão para fazer commit no branch predefinido, cria um novo branch e usa a interface do teu fornecedor Git para criar um pull request e fundi-lo no branch predefinido.

Autor numa pasta do Git ao assumir uma função

Com o RBAC,assumes um papel para aceder a dados enquadrados nesse papel. Para criar código que lê esses dados, assumes o papel para que o acesso aos dados esteja em vigor, e depois comprometes as tuas alterações. Podes comprometer-te tanto como a tua própria identidade de utilizador quer como o papel. A escolha determina como o teu fornecedor de Git atribui os commits, em função do nível de configuração que o fluxo de trabalho exige. Ambos dependem da credencial Git da função.

Efetue a confirmação com a sua identidade de utilizador

Nesta abordagem, faz commits com as suas credenciais pessoais do Git, para que o seu fornecedor de Git lhe atribua os commits. Assumes a função apenas para efetuar alterações nos dados a que a função pode aceder e depois voltas à tua identidade de utilizador para confirmar as alterações. Como crias alterações ao assumires essa função, mas fazes commit com a tua identidade de utilizador, a pasta do Git tem de estar acessível a partir de ambas as identidades. Configura isto de duas formas, que diferem em quem é o dono da pasta e em que direção a partilhas.

Opção 1: Clonar na tua pasta pessoal e partilhá-la com a função

1. Com a tua identidade de utilizador (não assumas essa função), clona o repositório para uma pasta Git na tua pasta pessoal (/Workspace/Users/<your-username>/...). Veja Clonar um repositório. O clone usa a tua credencial pessoal do Git, e tu és o dono da pasta. A função não precisa de credencial própria Git para esta opção.
2. Concede à função acesso à pasta (Pode executar ou Pode editar, se a função precisar de modificar ficheiros) para que possas trabalhar nela ao assumires essa função.
3. Assume o papel e depois faz as tuas alterações na pasta. O acesso aos dados da função está ativo.
4. Muda de volta para a tua identidade de utilizador, depois faz commit e faz push. O commit utiliza os seus dados pessoais git_username e git_email.

Como partilhas a pasta da tua identidade de utilizador para a função, os controlos de partilha de ativos no workspace não afetam esta opção. Esses controlos restringem apenas uma função de partilhar recursos para o exterior.

Opção 2: Clonar na pasta pessoal da função e partilhá-la com a sua identidade de utilizador

1. Assuma a função e clone o repositório numa pasta Git na pasta pessoal dessa função. O clone utiliza a credencial do Git da função, que tem de ter pelo menos acesso de leitura.
2. Ao assumir essa função, conceda acesso à sua identidade de utilizador à pasta (Pode editar).
3. Faz as tuas alterações enquanto desempenhas o papel. O acesso aos dados da função está ativo.
4. Volta a usar a tua identidade de utilizador. Como concedeste acesso ao teu utilizador, podes aceder à pasta, por isso commit e push com a tua credencial pessoal. O commit utiliza os seus dados pessoais git_username e git_email.

Como a função partilha a pasta externamente com a sua identidade de utilizador, esta opção não funciona se a função estiver na lista de bloqueio dos controlos de partilha de ativos da área de trabalho. Use a opção 1 para essas funções.

Compromete-se como papel

Nesta abordagem, clonas, crias e comprometes, tudo enquanto atuas como o papel. Este é o fluxo de trabalho mais simples: não partilhas uma pasta nem mudas de identidade para fazer um commit. Exige que a credencial Git da função tenha acesso de escrita, porque a interface do espaço de trabalho faz commit e push numa única ação.

1. Assuma a função.
2. Clona o repositório para uma pasta Git. Porque está a assumir a função, a clonagem usa as credenciais do Git da função.
3. Faz as tuas alterações, depois compromete-te e avança. O commit utiliza git_username e git_email da função.

Pese estas implicações antes de escolher esta abordagem:

• A atribuição é feita ao nível da função. Os commits no teu provedor de Git mostram a identidade Git da função, não a do autor em nome individual. Os registos de auditoria do Azure Databricks registam tanto identity_metadata.run_as (a função) como identity_metadata.run_by (si) para confirmações efetuadas através da interface do espaço de trabalho. Isto não se aplica a commits Git brutos executados a partir da CLI Git num terminal web, que o Azure Databricks não atribui a um utilizador individual.
• A credencial do Git da função é partilhada e tem permissões de escrita. Todos os que assumem a função usam a mesma credencial para fazer push, pelo que um token exposto ou indevidamente utilizado pode fazer push, apagar ramos ou criar commits em nome da função. Por isso, o Azure Databricks recomenda uma credencial de Git de grupo só de leitura e a abordagem de efetuar o commit com a identidade do utilizador. Use credenciais com permissão de escrita apenas quando aceitar estes compromissos. Consulte Permissões de token. Restrinja o âmbito da credencial apenas aos repositórios de que a função necessita.

Puxar alterações

Para extrair alterações do repositório Git remoto, clique em Pull na caixa de diálogo de operações Git. Os notebooks e outros ficheiros atualizam-se automaticamente para a versão mais recente no seu repositório Git remoto. Se as alterações retiradas do repositório remoto entrarem em conflito com as tuas alterações locais no Azure Databricks, resolve os conflitos de fusão.

Colaborar em repositórios Git

As pastas Git do Azure 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 Share (Partilhar).
2. Clique em Copiar link para criar a pasta Git.
3. Envia a URL ao teu colaborador.
4. Quando o teu colaborador abre a URL, vê um diálogo pré-preenchido com a configuração da tua pasta Git.
5. Eles clicam em Criar pasta Git para clonar o repositório no seu próprio espaço de trabalho, na pasta de trabalho atual.

Mesclar branches

A função de fusão nas pastas Git do Azure Databricks usa git merge para combinar o histórico de commit de um ramo para outro. Para iniciantes no Git, o Databricks recomenda usar merge em vez de rebase porque não requer force push nem reescreve o histórico de commits.

Para fundir um ramo com outro, clique no e selecione Fundir.

• Se houver um conflito de fusão, resolva-o na interface das pastas do Git.
• Se não houver conflito, a fusão é enviada para o repositório Git remoto usando git push.

Resolver conflitos de mesclagem

Conflitos de fusão ocorrem quando o Git não consegue reconciliar automaticamente alterações às mesmas linhas de um ficheiro provenientes de diferentes fontes, como durante uma operação de pull, rebase ou merge.

Para resolver um conflito de fusão, utilize a interface de pastas Git que mostra ficheiros conflitantes e opções de resolução.

• Edita manualmente o ficheiro para escolher quais as alterações a manter.
• Selecione Manter todas as alterações atuais ou Aceitar todas as alterações recebidas para aceitar uma versão completamente.
• Abortar a operação e descartar alterações conflitantes para tentar novamente.

Resolver conflitos manualmente

A resolução manual de conflitos permite-lhe determinar quais as linhas conflitantes a aceitar. Edita diretamente o conteúdo do ficheiro 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 fizeste as escolhas erradas ao resolver conflitos de fusão, clica em Abortar para abortar o processo e desfazer tudo. Depois de todos os conflitos estarem resolvidos, clique em Continuar Fusão ou Continuar Rebase para resolver o conflito e completar a operação.

Rebasear um ramo

A função de rebase nas pastas Git do Azure Databricks usa git rebase para integrar alterações de um ramo para outro, reaplicando os seus commits por cima do ramo de destino, criando um histórico linear.

Para rebasear um ramo noutro ramo, clique no menu Kebab e selecione Rebase, depois selecione o ramo alvo.

• Após a rebase, as pastas Git são executadas git commit e git push --force atualizam o repositório remoto.
• O rebase reescreve o histórico de commits, o que pode causar problemas de versão para colaboradores que trabalham no mesmo repositório.

Reiniciar uma ramificação

Execute uma redefinição do Git através da interface de pastas do Git. Esta operação é equivalente a git reset --hard combinada 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. Podes usar isto quando as edições entram em conflito com o ramo a montante, e não te importas de perder essas edições quando reiniciares para o ramo a montante. Leia mais sobre git reset --hard.

Reiniciar para uma ramificação 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 Reiniciar no Menu Kebab.

   

3. Selecione a branch para reiniciar e clique em Executar Git Reset.

Configurar o modo de sparse checkout

Checkout esparso é uma configuração do lado do cliente que permite clonar e trabalhar apenas com um subconjunto dos diretórios do repositório remoto no Azure Databricks. Isto é especialmente útil se o tamanho do seu repositório exceder os limites suportados pelo Azure Databricks.

Ativa o modo de checkout esparso quando clonares um novo repositório. Não podes desativar o modo de checkout esparso depois de o ativares.

1. No diálogo Criar pasta Git , ativa o modo de checkout Sparse.

   

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

Como funcionam os padrões de cone

Para compreender como funcionam os padrões de cones no modo de checkout esparso, veja o diagrama seguinte que representa a estrutura do repositório remoto.

Se selecionares o modo Sparse Checkout, mas não especificares um padrão de cone, aplica-se o padrão predefinido do cone. Isto inclui apenas os ficheiros na raiz e nenhum subdiretório, resultando numa estrutura de repositório da seguinte forma:

Definir o padrão do cone de checkout esparso como parent/child/grandchild inclui recursivamente todo o diretório grandchild. Os arquivos imediatamente no diretório /parent, /parent/child e no diretório raiz também estão incluídos. Veja a estrutura de diretórios no diagrama a seguir:

Modificar configurações de check-out esparsas

Depois de criares um repositório, edita o padrão de cone de checkout esparso das Definições>Padrões Avançados>de Cones.

Tenha em atenção o seguinte comportamento:

• Remover uma pasta da estrutura em cone remove-a do Azure Databricks, desde que não haja alterações pendentes.

• Adicionar uma pasta ao editar o padrão de checkout esparso, no formato de cone, adiciona-a ao Azure Databricks sem necessidade de fazer um pull adicional.

• Padrões de checkout esparsos não podem ser modificados para remover uma pasta quando há alterações por confirmar nessa pasta.

  Por exemplo, se editares um ficheiro numa pasta e não fizeres commit das alterações, e depois tentares alterar o padrão de checkout esparso para excluir essa pasta, o padrão é aceite, mas a pasta não é apagada. Precisas de reverter o padrão para que inclua essa pasta, submeter as tuas alterações e depois reaplicar o novo padrão.

Faça alterações usando o checkout esparso

Edita ficheiros existentes, faz commit e envia-os a partir 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 corrigir isto, edita o padrão de cone para incluir a nova pasta que estás a tentar commitar e fazer push.

Limitações de verificação esparsa

• A verificação esparsa não funciona para repositórios Azure DevOps com mais de 4 GB.
• Não podes desativar o sparse checkout para um repositório criado com o sparse checkout ativado.

Gerir repositórios Git de forma programática

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

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. Clique em 'Confirmar' e mover para a Lixeira.

Próximos passos

• Configure a autenticação para ligar o Azure Databricks ao seu fornecedor Git. Veja Ligar o seu fornecedor Git ao Databricks.
• Aprenda sobre limites de tamanho e outras restrições para pastas Git. Veja Azure Databricks limites da pasta Git e referência.
• Configurar as definições ao nível do espaço de trabalho para integração com o Git. Veja Configurar integração Git para pastas Git.