Criar e gerenciar pastas Git

Esta página descreve como criar pastas Git no Databricks e executar operações comuns do Git, incluindo clonagem, criação de branches, commit e push.

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

Configuração e instalação	Fluxo de trabalho diário	operações avançadas
Clonar um repo Usar a Git CLI Acesse a caixa de diálogo do Git	Criar uma nova ramificação Mudar para um ramo diferente Confirme e envie as alterações. Alterações de puxar Colaborar em pastas Git	mesclar ramos Resolver conflitos merge Rebasear um branch Reset um ramo Configurar checkout esparso Excluir uma pasta Git

Configuração e instalação	Fluxo de trabalho diário	operações avançadas
Clonar um repo Usar a Git CLI Acesse a caixa de diálogo do Git	Criar uma nova ramificação Mudar para um ramo diferente Confirme e envie as alterações. Alterações de puxar Colaborar em pastas Git	mesclar ramos Resolver conflitos merge Rebasear um branch Reset um ramo Configurar checkout esparso Excluir uma pasta Git

Clonar um repo

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

nota

• Você deve ter permissão CAN MANAGE na pasta pai onde deseja criar a pasta Git.
• Seu workspace deve ter as credenciais Git configuradas. Consulte Conectar seu provedor Git ao Databricks.

Clonar a partir da interface do usuário

1. Na barra lateral, selecione "espaço de trabalho" e navegue até a pasta onde deseja criar o clone repo Git .

2. Clique em Criar > Pasta Git .

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

campo	Descrição
URL do repository do Git	A URL do repositório Git que você deseja clonar, no formato https://example.com/organization/project.git.
Provedor do Git	O provedor Git do repositório que você deseja clonar.
Nome da pasta Git	O nome da pasta no seu workspace que contém o conteúdo do repo clonado.
Modo de finalização de compra simplificado	Se deve usar o checkout esparso, que clona apenas um subconjunto dos diretórios do seu repositório usando um padrão em cone. Isso é útil se o seu repositório exceder os limites de tamanho.

campo	Descrição
URL do repository do Git	A URL do repositório Git que você deseja clonar, no formato https://example.com/organization/project.git.
Provedor do Git	O provedor Git do repositório que você deseja clonar.
Nome da pasta Git	O nome da pasta no seu workspace que contém o conteúdo do repo clonado.
Modo de finalização de compra simplificado	Se deve usar o checkout esparso, que clona apenas um subconjunto dos diretórios do seu repositório usando um padrão em cone. Isso é útil se o seu repositório exceder os limites de tamanho.

4. Clique em Criar pasta Git . O conteúdo do remote repository é clonado para seu Workspace, e você pode começar a trabalhar com as operações do Git compatíveis. Quando seu workspace for elegível, a pasta Git será criada com acesso à CLI do Git automaticamente. Consulte Quando uma pasta Git obtém 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 web. Consulte o comando shell de execução no terminal web Databricks.

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

   Bash

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

3. Clone seu repositório:

   Bash

   git clone <remote-url>

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

4. Atualize seu navegador para visualizar a nova pasta no explorador de arquivos workspace .

Usar comandos da Git CLI

info

Visualização

Este recurso está em Pré-visualização Pública. Administradores do workspace podem controlar o acesso ao **suporte à Git CLI para pastas Git** na página **Prévias**. Consulte Gerenciar prévias do Databricks.

Pastas Git com acesso à Git CLI permitem executar comandos Git padrão no compute serverless, a partir de um notebook, do terminal web ou do Genie Code. Você pode:

• executar qualquer comando Git incluindo git stash, git push --force e git rebase -i.
• Integre a verificação de código (linting) e a 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 padrão do Git.
• Utilize submódulos Git e o sistema de arquivos de grande porte (LFS).
• Faça vários commits locais antes de enviar para o repositório remoto.

Requisitos compute CLI Git

O compute necessário depende de como você utiliza uma pasta Git com suporte a linha de comando CLI :

Operação	requisito de cálculo
Crie uma pasta Git com acesso CLI a partir da interface gráfica.	Compute serverless
execução de operações Git a partir da UI das pastas Git (pull, push, commit)	Compute serverless
Execute comandos da CLI do Git de um Notebook, do terminal web ou do Genie Code	compute serverless (versão do ambiente 5 ou acima) ou compute clássico (Databricks Runtime 17.0 ou acima)

Operação	requisito de cálculo
Crie uma pasta Git com acesso CLI a partir da interface gráfica.	Compute serverless
execução de operações Git a partir da UI das pastas Git (pull, push, commit)	Compute serverless
Execute comandos da CLI do Git de um Notebook, do terminal web ou do Genie Code	compute serverless (versão do ambiente 5 ou acima) ou compute clássico (Databricks Runtime 17.0 ou acima)

Para habilitar compute serverless , consulte Conectar-se à compute serverless.

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

nota

Você também pode executar comandos da CLI do Git de uma IDE ou terminal conectado ao compute do Databricks por meio de um túnel SSH. Isso atende ao requisito de compute para comandos da CLI do Git no terminal.

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

Ao criar uma pasta Git pela IU, o Databricks habilita automaticamente o acesso à Git CLI se o seu workspace for elegível. Se seu Workspace não for elegível, o Databricks cria uma pasta Git padrão em vez disso, e você ainda pode executar operações Git na interface do usuário das pastas Git.

Uma pasta Git criada na IU obtém acesso à Git CLI quando todas as condições a seguir são verdadeiras:

• A prévia da Git CLI está habilitada para o seu workspace. Os administradores do Workspace controlam isso na página **Pré-visualizações**. Consulte Gerenciar prévias do Databricks.
• O compute serverless está disponível no seu workspace. Consulte Conectar-se ao compute serverless.
• O Databricks pode acessar seu provedor Git a partir do compute serverless. O Databricks verifica a conectividade antes de clonar o repository. Se o seu provedor Git exigir conectividade de rede privada, consulte Configurar conectividade de rede.
• Durante a Pré-visualização Pública, os repositórios são limitados a 10.000 arquivos. repository que excederem esse limite são clonados como pastas Git padrão, em vez disso.

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

Crie uma pasta Git com acesso CLI Git

Para criar uma pasta Git com acesso CLI :

• Se você usar a interface do usuário, o Databricks criará a pasta Git com acesso à CLI do Git automaticamente quando seu workspace for elegível. Consulte Quando uma pasta Git obtém acesso à CLI do Git?. Se seu workspace não for elegível, o Databricks criará uma pasta Git padrão em vez disso.
• Se você usar o terminal web, qualquer repositório que você clonar terá acesso ao Git CLI automaticamente.

Após criar uma pasta Git com acesso CLI , execute qualquer comando Git padrão a partir do terminal web. Para abrir um terminal web, consulte Iniciar o terminal web.

Bash

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 via linha de comando (CLI) apresentam as seguintes limitações:

• Listas de permissão de URL do Git aplicam-se às operações do Git que você executa na interface do usuário do Databricks, mas não são impostas para comandos do Git que você executa 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çõesGit estão desativadas na interface do usuário workspace : compute sem servidor não está habilitado no seu workspace. Você ainda pode executar o comando Git no terminal web. Para habilitar compute serverless , consulte Conectar-se à compute serverless.
• O terminal solicita que você selecione uma credencial : As operações da CLI do Git usam suas credenciais do Git de workspace armazenadas automaticamente. O Databricks infere o provedor Git da URL remota e usa a credencial default para esse provedor. Se o Databricks não conseguir identificar uma única credencial para usar, você será solicitado a selecionar uma. Para evitar a solicitação, defina a variável de ambiente DB_GIT_CREDENTIAL_NAME como o nome da credencial que você deseja usar. O Databricks lembra a credencial que você usa para um repository e a reutiliza.
• As operaçõesGit falham com erros de permissão : Verifique se você tem permissão CAN MANAGE na pasta pai e se suas credenciais Git workspace são válidas. Consulte Conectar seu provedor Git ao Databricks.

Acessar a caixa de diálogo Git

Acesse a caixa de diálogo Git a partir de um Notebook ou do navegador de pastas Git Databricks .

• Em um Notebook, clique no botão ao lado do nome do Notebook que identifica a ramificação Git atual.

  

• No navegador de pastas Git Databricks , clique em Git ao lado do nome repo .

Uma caixa de diálogo em tela cheia será exibida, onde você poderá realizar operações do Git.

1. Seu ramo de trabalho atual. Você pode selecionar outras filiais aqui. Se outros usuários tiverem acesso a esta pasta Git , a alteração do branch também será alterada para eles, caso compartilhem o mesmo workspace. Consulte as melhores práticas recomendadas para evitar esse problema.
2. Crie uma nova ramificação.
3. Arquivo ativo e subpastas incluídos no seu branch atual.
4. Mostrar a história da filial atual.
5. Extrair conteúdo do repositório Git remoto.
6. Adicione uma mensagem de commit e uma descrição expandida opcional para suas alterações.
7. Confirme suas alterações no branch de trabalho e envie o branch atualizado para o repositório Git remoto.

Clique no Menu kebab para escolher operações adicionais de ramificação Git , como um reset completo, merge ou rebase.

Crie uma nova filial

Para criar uma nova ramificação:

1. Abra a caixa de diálogo do Git.
2. Clique em Criar filial .
3. Insira um nome para a nova ramificação e selecione a ramificação base.
4. Clique em Criar .

Mudar para um ramo diferente

Para acessar uma ramificação diferente, use o dropdown de ramificações na caixa de diálogo Git :

As alterações não confirmadas no branch atual são transferidas e exibidas como alterações não confirmadas no novo branch, desde que não entrem em conflito com o código do novo branch. Descarte as alterações feitas antes ou depois da troca de branch se você não pretende manter as alterações não confirmadas.

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

importante

A troca de branches pode excluir os ativos workspace caso o novo branch não os contenha. Ao retornar para a branch atual, a ativa excluída é recriada com novos IDs e URLs. Essa alteração não pode ser revertida.

Se você compartilhou ou adicionou o arquivo ativo aos favoritos a partir de uma pasta Git , verifique se o arquivo ativo existe na nova branch antes de alternar.

Confirme e envie as alterações.

Ao adicionar um novo Notebook ou arquivo, ou ao fazer alterações em um Notebook ou arquivo existente, a interface do usuário da pasta Git destaca as alterações.

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

Se você não tiver permissão para commit no branch default , crie um novo branch e use a interface do seu provedor Git para criar um pull request e merge -lo ao branch default .

nota

As saídas Notebook não são incluídas no commit por default quando os Notebooks são salvos em formatos de arquivo de origem (.py, .scala, .sql, .r). Para obter informações sobre commits de saídas de Notebook usando o formato ipynb , consulte Controlar commit de artefatos de saída de Notebook ipynb.

Autor em uma pasta Git ao atuar como uma função

info

Visualização

Esta seção se aplica ao role-based access control (RBAC), que está em Pré-visualização Pública.

Com RBAC, assume-se uma função para acessar dados delimitados a essa função. Para criar código que lê esses dados, assume-se a função para que o acesso aos dados esteja ativo e, em seguida, faça o commit das alterações. É possível fazer o commit tanto como sua própria identidade de usuário quanto como a função. A escolha determina como seu provedor Git atribui os commits, em oposição à quantidade de configuração que o fluxo de trabalho exige. Ambos dependem da credencial Git da função.

Abordagem	Commits atribuídos a	Compensação
Faça commit com sua identidade de usuário	Você, individualmente.	Mais configuração: você compartilha a pasta Git para que ela esteja acessível em ambas as identidades, e volta para sua identidade de usuário para fazer o commit. Funciona com uma credencial de função somente leitura.
Commit como a função	A função.	Mais simples: você permanece atuando como a função e não compartilha uma pasta. Os commits carregam a identidade Git da função, e a credencial Git da função deve ter acesso de gravação e é compartilhada por todos que assumem a função.

Abordagem	Commits atribuídos a	Compensação
Faça commit com sua identidade de usuário	Você, individualmente.	Mais configuração: você compartilha a pasta Git para que ela esteja acessível em ambas as identidades, e volta para sua identidade de usuário para fazer o commit. Funciona com uma credencial de função somente leitura.
Commit como a função	A função.	Mais simples: você permanece atuando como a função e não compartilha uma pasta. Os commits carregam a identidade Git da função, e a credencial Git da função deve ter acesso de gravação e é compartilhada por todos que assumem a função.

Fazer commit com sua identidade de usuário

Nesta abordagem, o commit é feito com sua credencial pessoal do Git, então seu provedor Git atribui os commits a você. Você assume a função apenas para criar conteúdo com base nos dados que a função pode acessar e, em seguida, volta para sua identidade de usuário para fazer o commit. Como você cria conteúdo enquanto atua como a função, mas faz o commit como sua identidade de usuário, a pasta Git deve ser acessível sob ambas as identidades. Configure isso de uma de duas maneiras, que diferem em quem é o proprietário da pasta e em qual direção ela é compartilhada.

Opção 1: Clonar na sua pasta home e compartilhá-lo com a função

1. Como sua identidade de usuário (não assuma a função), clone o repository em uma pasta Git na sua pasta home (/Workspace/Users/<your-username>/...). Consulte Clonar um repo. O clone usa suas credenciais Git pessoais, e você é proprietário da pasta. A função não precisa de sua própria credencial Git para esta opção.
2. Conceda à função acesso à pasta ( Pode Execução ou Pode Editar se a função precisar modificar arquivos) para que você possa trabalhar nela enquanto atua como a função.
3. Assuma a função e, em seguida, faça suas 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 usa seu git_username e git_email pessoais.

Como você compartilha a pasta de sua identidade de usuário com a função, os controles de compartilhamento de ativos do workspace não afetam esta opção. Esses controles restringem apenas uma função de compartilhamento de ativo externamente.

Opção 2: Clonar na pasta home da função e compartilhá-la com sua identidade de usuário.

1. Assuma a função e clone o repository em uma pasta Git na pasta home da função. O clone usa a credencial Git da função, que deve ter pelo menos acesso de leitura.
2. Ao atuar como a função, conceda acesso à pasta para sua identidade de usuário (**PodeEditar**).
3. Faça suas alterações enquanto atua como a função. O acesso a dados da função está em vigor.
4. Voltar à sua identidade de usuário. Como você concedeu acesso ao seu usuário, você pode acessar a pasta, então faça commit e push com sua credencial pessoal. O commit usa suas informações pessoais: git_username e git_email.

Como a função compartilha a pasta com a 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 função

Nesta abordagem, é possível clonar, criar e fazer o commit, tudo isso enquanto se atua como a função. Este é o fluxo de trabalho mais simples: não é necessário compartilhar uma pasta nem trocar de identidades para fazer o commit. Requer que as credenciais Git da função tenham acesso de gravação, porque a interface do usuário do Workspace faz o commit e o push em uma única ação.

1. Assuma a função.
2. Clonar o repository em uma pasta Git. Visto que se está agindo como a função, o clone utiliza a credencial Git da função.
3. Faça suas alterações e, em seguida, commit e envie. O commit usa o git_username e o git_email da função.

Pondere essas implicações antes de escolher esta abordagem:

• A atribuição está no nível da função. Commits no seu provedor Git mostram a identidade Git da função, não o autor individual. Os logs de auditoria do Databricks registram tanto identity_metadata.run_as (a função) quanto identity_metadata.run_by (você) para commits feitos por meio da UI do Workspace. Isso não se aplica a commits Git brutos executados a partir do CLI Git em um terminal da web, que o Databricks não atribui a um usuário individual.
• A credencial Git da função é compartilhada e habilitada para gravação. Todos que assumem a função usam a mesma credencial para enviar, de modo que um token vazado ou mal utilizado pode enviar, excluir branches ou criar commits sob a identidade da função. Por isso, o Databricks recomenda uma credencial Git de grupo somente leitura e a abordagem de fazer commit com sua identidade de usuário. Use credenciais habilitadas para gravação somente quando aceitar estas compensações. Consulte Permissões de token. Delimite a credencial apenas aos repositórios que a função precisa.

Alterações de puxar

Para obter as alterações do repositório Git remoto, clique em "Pull" na caixa de diálogo de operações do Git. O notebook e outros arquivos são atualizados automaticamente para a versão mais recente em seu repositório Git remoto. Se as alterações obtidas do repo remoto entrarem em conflito com as suas alterações locais no Databricks, resolva os conflitosmerge.

importante

As operações Git que extraem alterações do repositório remoto limpam o estado do Notebook. Consulte a seção "Alterações recebidas limpam o estado do Notebook".

Colaborar em pastas Git

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

• Cada membro da equipe tem sua própria pasta Git mapeada para o repositório Git remoto, onde trabalha em seu próprio branch de desenvolvimento.
• Apenas um usuário realiza operações Git em cada pasta Git. Vários usuários executando operações Git na mesma pasta podem causar problemas de gerenciamento de branches, como um usuário, sem querer, trocar de branch para todos os outros.

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

1. Clique em Compartilhar .
2. Clique em Copiar link para criar a pasta Git .
3. Envie o URL para seu colaborador.
4. Quando seu colaborador abrir o URL, ele verá uma caixa de diálogo preenchida previamente com a configuração da sua pasta Git.
5. Eles clicam em Criar pasta Git para clonar o repositório em seu próprio workspace dentro da pasta de trabalho atual.

mesclar ramificações

A função merge nas pastas Git Databricks usa git merge para combinar o histórico commit de um branch em outro. Para iniciantes Git , Databricks recomenda usar merge em vez do rebase, pois ele não exige o envio forçado de alterações (force push) e não sobrescreve o histórico commit .

Para merge uma ramificação em outra, clique em Menu de kebabs e selecione mesclar .

• Se houver um conflito no site merge, resolva-o na interface do usuário de pastas Git.
• Se não houver conflito, a merge envia para o repo Git remoto usando git push.

Resolver merge conflitos

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

Para resolver um conflito merge , use a interface de pastas Git , que exibe os arquivos em conflito e as opções de resolução.

• Edite o arquivo manualmente para escolher quais alterações manter.
• Selecione " Manter todas as alterações atuais" ou "Aceitar todas as alterações recebidas" para aceitar uma versão por completo.
• Aborte as operações e descarte as alterações conflitantes para tentar novamente.

Resolver conflitos manualmente

A resolução manual de conflitos permite que você determine 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, inclusive os marcadores de conflito Git merge . Quando terminar, selecione Marcar como resolvido .

Se você fez escolhas incorretas ao resolver conflitos merge , clique em Abortar para interromper o processo e desfazer tudo. Após todos os conflitos serem resolvidos, clique em Continuar mesclagem ou Continuar rebase para resolver o conflito e concluir as operações.

Rebasear um branch

A função rebase nas pastas Git Databricks usa git rebase para integrar as alterações de um branch em outro, reaplicando seu commit em cima do branch de destino, criando um histórico linear.

Para rebasear uma ramificação em outra ramificação, clique em No menu Kebab, selecione Rebase e, em seguida, selecione a branch de destino.

• Após o rebase, execução das pastas Git git commit e git push --force para atualizar o repo remoto.
• O rebase reescreve o histórico commit , o que pode causar problemas de versionamento para colaboradores que trabalham no mesmo repo.

Reset um ramo

Execute um Git Reset a partir da interface de gerenciamento de pastas Git . Esta operação é equivalente a git reset --hard combinado com git push --force.

Git Reset substitui o conteúdo e o histórico do branch pelo estado mais recente de outro branch. Você pode usar isso quando as edições entrarem em conflito com a branch upstream e você não se importar em perder essas edições ao reverter para a branch upstream. Leia mais sobre git reset --hard.

Reset para um ramo remoto

Com git reset neste cenário:

• O senhor redefine o ramo selecionado (por exemplo, feature_a) para um ramo diferente (por exemplo, main).
• O senhor também redefiniu a ramificação upstream (remota) feature_a para a principal.

importante

Ao redefinir, o senhor perde todas as alterações não confirmadas e confirmadas na versão local e remota do ramo.

Para redefinir uma filial para uma filial remota:

1. Na interface do usuário das pastas Git, no menu Branch (Filial ), escolha a filial que o senhor deseja redefinir.

2. Selecione Reset na caixa de seleção. Cardápio de kebabs.

   

3. Selecione a ramificação que deseja redefinir e clique em executar Git Reset .

Configurar o modo de pagamento esparso

O 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 Databricks. Isso é especialmente útil se o tamanho do seu repositório exceder os limites suportados pelo Databricks.

Ative o modo de checkout esparso ao clonar um novo repo. Não é possível desativar o modo de finalização de compra simplificada depois de ativá-lo.

1. Na caixa de diálogo Criar pasta Git , ative o modo de checkout esparso .

   

2. Na caixa Padrões de cone , especifique os padrões de checkout de cone que você deseja. Separe vários padrões por quebras de linha.

Como funcionam os padrões de cone

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

Se você selecionar o modo de checkout esparso , mas não especificar um padrão de cone, o padrão de cone default será aplicado. Isso inclui apenas os arquivos na raiz e nenhum subdiretório, resultando em uma estrutura repo como a seguinte:

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

nota

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

Modificar configurações esparsas de checkout

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

Observe 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 editando o padrão de cone de checkout esparso a adiciona ao Databricks sem a necessidade de um pull adicional.

• Os padrões de checkout esparsos 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 commit as alterações, e depois tentar alterar o padrão de checkout 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, commit as alterações e, em seguida, reaplicar o novo padrão.

Faça alterações com um checkout simplificado.

Edite os arquivos existentes e faça o commit e o push das alterações a partir da pasta Git. Ao criar novas pastas de arquivos, inclua-as no padrão de cone que você especificou para esse repo.

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

Limitações de checkout escassas

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

Gerenciar pastas Git programaticamente

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

Excluir uma pasta Git

Para remover uma pasta Git do seu workspace:

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

Próximos passos

• Configure a autenticação para conectar o Databricks ao seu provedor Git. Consulte Conectar seu provedor Git ao Databricks.
• Saiba mais sobre os limites de tamanho e outras restrições para pastas Git. Consulte os limites e a referência da pasta Git do Databricks.
• Configure as definições de nível workspacepara integração Git . Consulte Configurar a integração do Git para pastas do Git.