execução Git operações em pastas Git Databricks
Esta página descreve como executar operações comuns Git em seu workspace Databricks usando pastas 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
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.
- Você deve ter permissão
CAN MANAGEna 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
-
Na barra lateral, selecione "espaço de trabalho" e navegue até a pasta onde deseja criar o clone repo Git .
-
Clique em Criar > Pasta Git .
-
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 |
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. |
Usar a CLI do Git (Beta) | Habilita a execução de comandos Git padrão diretamente de um terminal Databricks . Isso proporciona acesso a operações avançadas como hooks de pré-commit, submódulos Git e Large File Storage (LFS). Consulte Usar o comando Git CLI (Beta). |
- Clique em Criar pasta Git . O conteúdo do repositório remoto é clonado para o seu workspace e você pode começar a trabalhar com as operações Git compatíveis.
Clonar a partir do terminal web
Você também pode criar pastas Git com acesso CLI diretamente do terminal web:
-
Acesse o terminal web. Consulte o comando shell de execução no terminal web Databricks.
-
Navegue até o diretório pai em
/Workspace:Bashcd /Workspace/Users/<your-email>/<project>
Você não pode criar pastas Git com acesso Git CLI em /Repos ou em pastas Git existentes.
-
Clone seu repositório:
Bashgit clone <remote-url>O comando
git cloneusa as credenciais Git configuradas em seu workspace. Consulte Conectar seu provedor Git ao Databricks. -
Atualize seu navegador para visualizar a nova pasta no explorador de arquivos workspace .
Use o comando Git CLI (Beta)
Beta
Este recurso está em versão Beta. Os administradores do espaço de trabalho podem controlar o acesso a este recurso na página de Pré-visualizações . Veja as prévias do Gerenciador Databricks.
Pastas Git com acesso CLI Git permitem que você execute comandos Git padrão diretamente de um terminal Databricks . Você pode:
- executar qualquer comando Git incluindo
git stash,git pull --forceegit 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.
Para usar o acesso CLI Git , seu workspace deve ter computeserverless habilitada com a versão de ambiente 4 ou superior.
Crie uma pasta Git com acesso CLI Git
Para criar uma pasta Git com acesso CLI :
- Se você usar o terminal web, qualquer repositório que você clonar terá acesso ao Git CLI automaticamente.
- Se você usa a interface gráfica, habilite a opção "Usar a CLI do Git" ao criar a pasta do Git.
Após 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 via linha de comando (CLI) apresentam as seguintes limitações:
- Um espaço de trabalho com listas de permissões de URLs remotas ativadas não pode usar o recurso CLI Git .
- O comando Git CLI ignora a configuração administrativa que bloqueia a saída dos Notebooks de commit.
- A API Repos não é compatível com pastas Git com acesso via linha de comando (CLI).
- Não é possível habilitar o acesso à CLI do Git para pastas Git existentes.
Solucionar problemas de operações da CLI do Git
- O terminal solicita credenciais em todas as operações : O recurso Git CLI não está habilitado em seu workspace. Entre em contato com o administrador do seu workspace para verificar se a pré-visualização está ativada.
- Não é possível habilitar o acesso CLI : o espaço de trabalho com listas de permissões de URL remotas não pode usar o recurso Git CLI . Contate o administrador do seu workspace para revisar a configuração de rede do seu workspace.
- As operaçõesGit falham com erros de permissão : Verifique se você tem permissão
CAN MANAGEna 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.

- 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.
- Crie uma nova ramificação.
- Arquivo ativo e subpastas incluídos no seu branch atual.
- Mostrar a história da filial atual.
- Extrair conteúdo do repositório Git remoto.
- Adicione uma mensagem de commit e uma descrição expandida opcional para suas alterações.
- 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:
- Abra a caixa de diálogo do Git.
- Clique em Criar filial .
- Insira um nome para a nova ramificação e selecione a ramificação base.
- 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.
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 .
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.
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.
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:
- Clique em Compartilhar .
- Clique em Copiar link para criar a pasta Git .
- Envie o URL para seu colaborador.
- Quando seu colaborador abrir o URL, ele verá uma caixa de diálogo preenchida previamente com a configuração da sua pasta Git.
- 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 commitegit push --forcepara 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_apara a principal.
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:
-
Na interface do usuário das pastas Git, no menu Branch (Filial ), escolha a filial que o senhor deseja redefinir.
-
Selecione Reset na caixa de seleção.
Cardápio de kebabs.

-
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.
-
Na caixa de diálogo Criar pasta Git , ative o modo de checkout esparso .

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

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:
- Clique com o botão direito do mouse na pasta Git e selecione Mover para a Lixeira .
- 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 pastas Git do Databricks.