Observação
O acesso a essa página exige autorização. Você pode tentar entrar ou alterar diretórios.
O acesso a essa página exige autorização. Você pode tentar alterar os diretórios.
O artigo descreve como executar operações comuns do Git em seu workspace do Databricks usando pastas Git, incluindo clonagem, ramificação, confirmação e envio por push.
Clonar um repositório conectado a um repositório Git remoto
Você pode criar repositórios Git usando a interface de usuário do Databricks ou o terminal de web.
Observação
- Você deve ter
CAN MANAGEpermissão na pasta pai onde deseja criar o diretório Git. - Seu workspace deve ter as credenciais do Git configuradas. Consulte Configurar credenciais do Git & conectar um repositório remoto ao Azure Databricks.
Clonar da interface do usuário
Na barra lateral, selecione Workspace e navegue até a pasta na qual você deseja criar o clone do repositório Git.
Clique em 'Criar' >.
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.gitProvedor 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 workspace que conterá o conteúdo do repositório clonado Check-out esparso Se é necessário usar o check-out esparso, no qual apenas um subconjunto dos diretórios do repositório é clonado, especificado usando um padrão de cone. Isso será útil se o repositório for maior do que os limites compatíveis com o Databricks. Utilizar a ferramenta de linha de comando Git (Beta) Habilite a execução de comandos Git padrão diretamente de um terminal do Databricks. Isso fornece acesso a operações avançadas, como ganchos de pré-confirmação, submódulos Git e LFS (Armazenamento de Arquivos Grandes). Consulte Usar comandos da CLI do Git (Beta). Clique em Criar pasta Git. O conteúdo do repositório remoto é clonado para o repositório do Databricks e você pode começar a trabalhar com eles usando operações Git com suporte por meio de seu workspace.
Clonar do terminal da Web
Você também pode criar pastas Git com acesso à CLI diretamente do terminal Web:
Acesse o terminal da Web. Confira Executar comandos shell no terminal web do Azure Databricks.
Navegue até o diretório pai em
/Workspace:cd /Workspace/Users/<your-email>/<project>Observação
Você não pode criar pastas Git com acesso à CLI do Git dentro
/Reposou em pastas Git existentes.Clone seu repositório:
git clone <remote-url>O
git clonecomando usa as credenciais do Git configuradas em seu workspace. Consulte Configurar credenciais do Git & conectar um repositório remoto ao Azure Databricks.Atualize o navegador para ver a nova pasta no navegador de arquivos do workspace.
Usar comandos da CLI do Git (Beta)
Importante
Esse recurso está em Beta. Os administradores do workspace podem controlar o acesso a esse recurso na página Visualizações . Consulte Gerenciar visualizações do Azure Databricks.
As pastas git com acesso à CLI do Git permitem executar comandos Git padrão diretamente de um terminal do Databricks. É possível:
- Execute qualquer comando Git, incluindo
git stash,git pull --forceegit rebase -i. - Integrar linting e verificação de código com ganchos de pré-confirmação.
- 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).
- Preparar várias confirmações localmente antes de enviar por push para o repositório remoto.
Para usar o acesso à CLI do Git, seu workspace deve ter a computação sem servidor habilitada com o ambiente versão 4 ou superior.
Criar uma pasta Git com acesso à CLI do Git
Para criar uma pasta Git com acesso à CLI:
- Ao usar o terminal Web, qualquer repositório que você clonar tem acesso à CLI do Git automaticamente.
- Ao usar a interface do usuário, você deve habilitar a versão prévia da CLI do Git ao criar a pasta Git.
Depois de criar uma pasta Git com acesso à CLI, execute qualquer comando Git padrão no terminal Da 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:
- Workspaces com listas de permissão de URL remotas ativadas não podem utilizar funcionalidades do Git CLI.
- Os comandos da CLI do Git ignoram a configuração de administrador que bloqueia a confirmação de saídas do notebook.
- Não há suporte para a API de Repos para diretórios Git com acesso à CLI.
- Você não pode habilitar o acesso à CLI do Git para pastas Git existentes.
Solução de problemas de operações da CLI do Git
- O terminal solicita credenciais em todas as operações: o recurso da CLI do Git não está habilitado em seu workspace. Entre em contato com o administrador do workspace para verificar se a visualização está habilitada.
- Não é possível habilitar o acesso à CLI: workspaces com listas de permissões de URL remotas não podem usar recursos da CLI do Git. Entre em contato com o administrador do workspace para examinar a configuração de rede do workspace.
- 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 Configurar credenciais do Git & conectar um repositório remoto ao Azure Databricks.
Prática recomendada: Colaborando em pastas Git
As pastas Git do 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 tem seu próprio diretório Git mapeado para o repositório Git remoto, onde cada um trabalha em seu branch de desenvolvimento próprio.
- 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:
- Clique em Copiar link para criar a pasta Git na faixa na parte superior do workspace do Databricks.
- Envie a URL para o colaborador.
- Quando o colaborador abre a URL, ele vê uma caixa de diálogo Criar pasta Git pré-preenchida com a configuração da pasta Git.
- Eles clicam em Criar pasta Git para clonar o repositório em sua própria área de trabalho no diretório de trabalho atual.
Para copiar uma pasta git de outro usuário:
- Abra a pasta Git do outro usuário no workspace compartilhado.
- Clique em Criar pasta Git na faixa na parte superior. A caixa de diálogo Criar pasta Git é aberta com a configuração do repositório Git pré-preenchida.
- Clique em Criar pasta git para clonar o repositório em seu próprio workspace.
Acessar a caixa de diálogo do Git
Você pode acessar a caixa de diálogo do Git de um notebook ou do navegador de pastas Git do Databricks.
Em um notebook, clique no botão ao lado do nome do notebook que identifica o Git branch atual.
No navegador de pastas Git do Databricks, 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 inteira na qual poderá executar operações do Git.
- Seu branch de trabalho atual. Você pode selecionar outros brunchs aqui. Se outros usuários tiverem acesso a essa pasta Git, alterar o branch também alterará o branch para eles se eles compartilharem o mesmo workspace. Consulte uma melhor prática para evitar esse problema.
- O botão para criar um novo branch.
- A lista de ativos de arquivo e subpastas verificadas no branch atual.
- Um botão que leva você ao seu provedor Git e mostra o histórico atual do branch.
- O botão para extrair conteúdo do repositório Git remoto.
- Caixa de texto em que você adiciona uma mensagem de confirmação e uma descrição expandida opcional para suas alterações.
- O botão para confirmar seu trabalho no branch de trabalho e efetuar push do branch atualizado para o repositório Git remoto.
Clique no no canto superior direito para escolher entre outras operações de branch do Git, como um reset duro, uma mesclagem ou um rebase.
Esta é a sua casa para executar operações do Git na pasta Git do workspace. Você está limitado às operações do Git apresentadas na interface do usuário.
Criar uma nova ramificação
Você pode criar uma nova ramificação com base em uma ramificação existente na caixa de diálogo do Git:
Alternar para um branch diferente
Você pode alternar (fazer checkout) para um branch diferente usando a lista suspensa do branch na caixa de diálogo do Git:
As alterações não confirmadas no branch atual serão transferidas e exibidas 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 da troca de branch se você não tiver a intenção de carregar 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
Alternar branches pode excluir recursos do espaço de trabalho quando o novo branch não contempla esses recursos. Ao voltar para o branch atual, os ativos excluídos serão recriados com novos identificadores e URLs. Essa alteração não pode ser revertida.
Se você compartilhou ou anotou ativos de uma pasta Git, verifique se o ativo existe no novo branch antes de alternar.
Faça commit das alterações e efetue push delas para o repositório Git remoto
Quando você adicionou novos notebooks ou arquivos ou fez alterações em notebooks ou arquivos existentes, a interface de usuário da pasta do Git realça as alterações.
Adicione uma mensagem de confirmação necessária para as alterações e clique em Fazer commit e Push para efetuar push dessas alterações para o repositório remoto do Git.
Se você não tiver permissão para fazer commits no branch padrão (como a branch main), crie uma nova branch e use a interface do seu provedor Git para criar uma solicitação de pull para mesclá-la no branch padrão.
Observação
- As saídas do notebook não são incluídas nos commits por padrão quando os notebooks são salvos nos formatos de arquivo de origem (
.py,.scala,.sql,.r). Para obter informações sobre como confirmar saídas de notebook usando o formato IPYNB, confira Confirmações de artefato de saída do notebook IPYNB de controle
Alterações do pull do repositório do Git remoto
Para efetuar pull de alterações do repositório Git remoto, clique em Efetuar Pull na caixa de diálogo operações do Git. Os notebooks e outros arquivos são atualizados automaticamente para a versão mais recente em seu repositório Git. Se as alterações efetuadas no repositório remoto entrarem em conflito com as alterações locais no Databricks, será necessário resolver os conflitos mesclados.
Importante
As operações do Git que e pull em alterações upstream limpam o estado do notebook. Para obter mais informações, consulte Alterações de entrada limpam o estado do notebook.
Mesclar ramificações
Acesse a operação de Mesclagem do Git selecionando-a no no canto superior direito da caixa de diálogo de operações do Git.
A função mesclar nas pastas Git do Databricks mescla uma ramificação em outra usando git merge. Uma operação de mesclagem é uma forma de combinar o histórico de confirmações de uma ramificação em outra ramificação; a única diferença é a estratégia usada para alcançar esse objetivo. Para iniciantes no Git, recomendamos o uso de mesclagem (em vez de troca de base) porque não requer efetuar push forçado para uma ramificação e, portanto, não reescreve o histórico de confirmações.
- Se houver um conflito de mesclagem, resolva-o na interface de usuário das pastas do Git.
- Se não houver conflito, a mesclagem será enviada por push para o repositório Git remoto usando
git push.
Rebase um branch em outro branch
Acesse a operação Git Rebase selecionando-a no no canto superior direito da caixa de diálogo de operações Git.
A troca de base altera o histórico de confirmações de uma ramificação. Como git merge, git rebase integra mudanças de uma ramificação para outra. A troca de base faz o seguinte:
- Salva as confirmações na sua ramificação atual em uma área temporária.
- Redefine a ramificação atual para a ramificação escolhida.
- Reaplica cada confirmação individual salva anteriormente na ramificação atual, resultando em um histórico linear que combina as alterações das duas ramificações.
Aviso
O uso de troca de base pode causar problemas de controle de versão para colaboradores trabalhando no mesmo repositório.
Um fluxo de trabalho comum é trocar a base de uma ramificação de recurso na ramificação principal.
Para trocar a base de uma ramificação em outra ramificação:
No menu Ramificação na interface do usuário de pastas Git, selecione a ramificação que você deseja trocar a base.
Selecione Trocar base no menu de kebab.
Selecione o branch cuja base você deseja trocar.
A operação de troca de base integra as alterações da ramificação que você escolher aqui na ramificação atual.
As pastas Git do Databricks executam git commit e git push --force para atualizar o repositório Git remoto.
Resolver conflitos de mesclagem
Os conflitos de mesclagem acontecem quando dois 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 consegue escolher as alterações "certas" a serem aplicadas. Os conflitos de mesclagem também podem ocorrer quando um usuário tenta efetuar pull ou mesclar alterações de outra ramificação em uma ramificação com alterações não confirmadas.
Se uma operação como pull, trocar base ou mesclar causar um conflito de mesclagem, a interface de usuário das pastas Git mostrará uma lista de arquivos com conflitos e opções para resolver os conflitos.
Você tem duas opções principais:
- Use a interface de usuário das pastas Git para resolver o conflito.
- Interrompa a operação do Git, descarte manualmente as alterações no arquivo conflitante e tente a operação do Git novamente.
Ao resolver conflitos de mesclagem com a interface do usuário das pastas Git, você deve escolher entre resolver manualmente os conflitos no editor ou manter todas as alterações de entrada ou atuais.
Manter Todas as Atuais ou Aceitar as Alterações de Entrada
Se souber que apenas deseja manter todas as alterações atuais ou de entrada, clique no botão à direita do nome do arquivo no painel do seu notebook e selecione Manter todas as alterações atuais ou Fazer todas as alterações de entrada. Clique no botão com o mesmo rótulo para confirmar as alterações e resolver o conflito.
Dica
Está em dúvida sobre qual opção escolher? A cor de cada opção corresponde às respectivas alterações de código que ela manterá no arquivo.
Resolvendo manualmente os conflitos
A resolução manual de conflitos permite determinar quais das linhas conflitantes devem ser aceitas na mesclagem. Para conflitos de mesclagem, resolva 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 os conflitos de mesclagem, clique no botão Anular para anular o processo e desfazer tudo. Uma vez resolvidos todos os conflitos, clique na opção Continuar Mesclagem ou Continuar Troca de Base 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 Git do Databricks é 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 usá-lo quando as edições estão em conflito com o branch upstream e não se importa em perder essas edições ao redefinir para o branch upstream.
Leia mais sobre git reset –hard.
Redefinir para uma ramificação upstream (remota)
Com git reset neste cenário:
- 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_apara principal.
Importante
Ao redefinir, você perde todas as alterações não confirmadas e confirmadas na versão local e remota da ramificação.
Para redefinir uma ramificação para uma ramificação remota:
Na interface do usuário das pastas Git, no menu Branch, escolha a ramificação que você deseja redefinir.
Selecione Redefinir no menu kebab.
Selecione o branch a ser redefinido.
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 dos diretórios dos repositórios remotos no Databricks. Isso é especialmente útil se o tamanho do repositório estiver além dos limites com suporte do Databricks.
Você pode usar o modo de Check-out esparso ao adicionar (clonar) um novo repositório.
Na caixa de diálogo Adicionar pasta Git, abra Avançado.
Selecione Modo de check-out esparso.
Na caixa Padrões de cone, especifique os padrões de check-out de cone desejados. Separe diferentes padrões com quebras de linha.
Neste momento, você não pode desabilitar 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 o Modo de check-out esparso, mas não especificar um padrão de cone, o padrão de cone será aplicado. Isso inclui apenas os arquivos na raiz e nenhum subdiretório, resultando em uma estrutura de repositório como a seguinte:
Definir o padrão de cone do check-out esparso como parent/child/grandchild faz com que todo o conteúdo do diretório grandchild seja incluído recursivamente. 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:
Você pode adicionar vários padrões separados por quebras de linha.
Observação
Não há suporte para comportamentos de exclusão (!) na sintaxe de padrão de cone do Git.
Modificar as configurações do check-out esparso
Após um repositório ser criado, o padrão de cone do check-out esparso pode ser editado 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 por meio da edição do padrão de cone de check-out esparso a adiciona ao Databricks sem exigir um pull adicional.
Os padrões de check-out esparso não podem ser alterados para remover uma pasta quando há alterações não confirmadas nessa pasta.
Por exemplo, uma usuária edita um arquivo em uma pasta e não confirma as 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 as alterações e, em seguida, reaplicar o novo padrão.
Observação
Não é possível desativar o "check-out" esparso para um repositório que foi criado com o modo de "check-out" esparso ativado.
Fazer e efetuar push das alterações com check-out esparso
Você pode editar arquivos existentes e confirmá-los e efetuar push deles na interface da pasta 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 corrigi-lo, edite o padrão de cone para incluir a nova pasta que você está tentando confirmar e efetuar push.
Padrões para um arquivo de configuração de repositório
O arquivo de configuração das saídas do commit usa padrões semelhantes aos padrões do gitignore e faz o seguinte:
- Padrões positivos permitem a inclusão de saídas para notebooks correspondentes.
- Padrões negativos desabilitam a inclusão de saídas para notebooks correspondentes.
- Os padrões são avaliados para todos os notebooks.
- Caminhos inválidos ou caminhos que não são resolvidos para notebooks
.ipynbsão ignorados.
Padrão positivo: para incluir saídas de um caminho de notebook folder/innerfolder/notebook.ipynb, use os seguintes padrões:
**/*
folder/**
folder/innerfolder/note*
Padrão negativo: para excluir saídas de um notebook, verifique se nenhum dos padrões positivos corresponde ou adicione um padrão negativo em um local correto do arquivo de configuração. Padrões negativos (exclusão) começam com !:
!folder/innerfolder/*.ipynb
!folder/**/*.ipynb
!**/notebook.ipynb
Limitação de check-out esparso
Atualmente, o check-out esparso não funciona para repositórios do Azure DevOps maiores que 4 GB.
Adicionar um repositório e conectar-se remotamente mais tarde
Para gerenciar e trabalhar com pastas Git programaticamente, use a API REST de pastas Git.
Excluir uma pasta do Git
Para remover uma pasta Git do workspace:
- Clique com o botão direito do mouse na pasta Git e selecione Mover para o lixo.
- Digite o nome da pasta Git para confirmar.
- Clique em Confirmar e mover para o lixo.