Execução de operações Git em pastas Git da Databricks (Repos)

O artigo descreve como executar operações comuns do Git no Databricks workspace usando pastas do Git, incluindo clonagem, ramificação, confirmação e envio.

Clonar um repositório conectado a um repositório Git remoto

1. Na barra lateral, selecione workspace e, em seguida, navegue até a pasta onde deseja criar o clone do Git repo.

2. Clique na seta para baixo à direita de Add (Adicionar ) no canto superior direito do site workspace e selecione a pasta Git no site dropdown.

   

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

   • A URL do repositório Git que o senhor deseja clonar, no formato https://example.com/organization/project.git

   • O provedor Git do repositório que o senhor deseja clonar. As opções incluem GitHub, GitHub Enterprise, GitLab e Azure DevOps (Azure Repos)

   • O nome da pasta em seu site workspace que conterá o conteúdo da pasta clonada. repo

   • Se o senhor usará ou não o checkout esparso, no qual apenas os subdiretórios especificados usando um padrão de cone são clonados

   

Nesse estágio, o senhor tem a opção de clonar apenas um subconjunto dos diretórios do repositório usando o checkout esparso. Isso é útil se o seu repositório for maior do que os limites suportados pelo Databricks.

1. Clique em Create Git folder (Criar pasta Git). O conteúdo do repositório remoto é clonado no Databricks repo, e o senhor pode começar a trabalhar com ele usando operações Git compatíveis por meio do seu workspace.

Melhores práticas: Colaboração em pastas Git

As pastas Git da Databricks se comportam efetivamente como clientes Git incorporados em seu site workspace para que os usuários possam colaborar usando o controle de origem e o controle de versão baseados em Git. Para tornar a colaboração da equipe mais eficaz, use uma pasta Git separada da Databricks mapeada para um Git remoto repo para cada usuário que trabalha em seu próprio ramo de desenvolvimento . Embora vários usuários possam contribuir com conteúdo para uma pasta do Git, apenas um usuário designado deve executar operações do Git, como pull, push, commit e troca de ramificação. Se vários usuários realizarem operações do Git em uma pasta Git, o gerenciamento de ramificações pode se tornar difícil e propenso a erros, como quando um usuário troca uma ramificação e, sem querer, troca-a para todos os outros usuários dessa pasta.

Para compartilhar uma pasta Git com um colaborador, cliq ue em Copy link to create Git folder (Copiar link para criar a pasta ) no banner na parte superior de seu site Databricks workspace. Essa ação copia um URL para a área de transferência local, que pode ser enviado a outro usuário. Quando o usuário destinatário carregar esse URL em um navegador, ele será levado para workspace, onde poderá criar sua própria pasta Git clonada do mesmo repositório remoto Git. Eles verão uma caixa de diálogo modal Create Git folder (Criar pasta Git ) na interface do usuário, preenchida previamente com os valores obtidos de sua própria pasta Git. Ao cli car no botão azul Create Git folder (Criar pasta ) no modal, o repositório Git é clonado no workspace sob a pasta de trabalho atual, onde o usuário pode trabalhar diretamente com ele.

Ao acessar a pasta Git de outra pessoa em um workspace compar tilhado, clique em Create Git folder (Criar pasta ) no banner na parte superior. Essa ação abre a caixa de diálogo Criar pasta Git para o senhor, preenchida previamente com a configuração do repositório Git que a suporta.

Importante

Atualmente, não é possível usar a CLI do Git para executar operações do Git em uma pasta do Git. Se o senhor clonar um Git repo usando a CLI por meio do terminal da Web de um cluster, os arquivos não serão exibidos na interface do usuário do Databricks.

Acesse a caixa de diálogo do Git

O senhor pode acessar a caixa de diálogo Git em Notebook ou no navegador de pastas Git da Databricks.

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

  

• No navegador de pastas do Databricks Git, clique no botão à direita do nome repo. O senhor também pode clicar com o botão direito do mouse no nome repo e selecionar Git... no menu.

  

O senhor verá uma caixa de diálogo em tela cheia na qual poderá realizar operações do Git.

1. Sua filial atual de trabalho. O senhor pode selecionar outras filiais aqui. Se outros usuários tiverem acesso a essa pasta Git, a alteração da ramificação também alterará a ramificação para eles se compartilharem o mesmo workspace. Veja uma prática recomendada para evitar esse problema.

2. O botão para criar uma nova filial.

3. A lista de arquivos ativos e subpastas verificados em seu ramo atual.

4. Um botão que o leva ao seu provedor Git e mostra o histórico do branch atual.

5. O botão para extrair conteúdo do repositório Git remoto.

6. Caixa de texto onde o senhor adiciona uma mensagem commit e uma descrição expandida opcional para suas alterações.

7. O botão para commit seu trabalho no ramo de trabalho e enviar o ramo atualizado para o repositório Git remoto.

Clique no kebab no canto superior direito para escolher entre operações adicionais de ramificação do Git, como um hard Reset, um merge ou um rebase.

Esse é o local onde o senhor executa as operações do Git na pasta workspace Git. O senhor está limitado às operações do Git apresentadas na interface do usuário.

Criar uma nova filial

Você pode criar uma nova ramificação com base em uma ramificação existente na caixa de diálogo do Git:

Mudar para um ramo diferente

Você pode mudar para (checkout) um branch diferente usando o dropdown de branch na caixa de diálogo do Git:

Importante

Depois que o senhor faz o checkout de um branch em uma pasta Git, há sempre uma chance de que o branch seja excluído no repositório Git remoto por outra pessoa. Se uma ramificação for excluída no site remoto repo, a versão local poderá permanecer presente na pasta Git associada por até 7 dias. As ramificações locais no Databricks não podem ser excluídas, portanto, se o senhor precisar removê-las, também deverá excluir e reclonar o repositório.

Confirme e envie alterações para o repositório Git remoto

Quando o senhor adiciona um novo Notebook ou arquivos, ou faz alterações em um Notebook ou arquivos existentes, a interface do usuário da pasta Git destaca as alterações.

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

Se você não tiver permissão para fazer commit na ramificação default (como a ramificação main), crie uma nova ramificação e use a interface do seu provedor Git para criar uma solicitação pull (PR) para merge -la na ramificação default .

Observação

• Notebook não são incluídos no commit por default quando o Notebook é salvo em formatos de arquivo de origem (.py, .scala, .sql, .r). Para obter informações sobre as saídas do Commit Notebook usando o formato ipynb, consulte Control ipynb Notebook output artifact commit

Puxe as alterações do repositório Git remoto

Para extrair 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 extraídas do site repo remoto entrarem em conflito com as alterações locais no Databricks, o senhor precisará resolver os conflitos de mesclagem.

Importante

As operações Git que extraem alterações upstream limpam o estado Notebook . Para obter mais informações, consulte Alterações recebidas para limpar o estado Notebook .

Mesclar ramificações

Acesse a seção Git merge selecionando-a no menu kebab no canto superior direito da caixa de diálogo de operações do Git.

A função merge nas pastas Git da Databricks mescla um ramo em outro usando git merge. A merge operações é uma maneira de combinar a commit história de um ramo em outro ramo; a única diferença é a estratégia que ela usa para conseguir isso. Para iniciantes no Git, recomendamos o uso do merge (em vez do rebase) porque ele não exige o push forçado para uma ramificação e, portanto, não reescreve a história do commit.

• Se houver um conflito no site merge, resolva-o na interface do usuário das pastas do Git.

• Se não houver conflito, a merge será enviada para o repo Git remoto usando git push.

Rebase um galho em outro galho

Acesse o Git Rebase operações selecionando-o no menu kebab no canto superior direito da caixa de diálogo Git operations.

O rebase altera a história commit de um branch. Como git merge, git rebase integra alterações de uma ramificação para outra. Rebase faz o seguinte:

1. Salva os commits em sua ramificação atual em uma área temporária.

2. Reset o ramo atual para o ramo escolhido.

3. Reaplica cada commit individual salvo anteriormente no branch atual, resultando em uma história linear que combina as alterações de ambos os branches.

Aviso

O uso de rebase pode causar problemas de versão para colaboradores que trabalham no mesmo repositório.

Um fluxo de trabalho comum é rebasear uma ramificação de recurso na ramificação principal.

Para rebasear uma ramificação em outra ramificação:

1. No menu Branch (Ramificação ) da interface do usuário de pastas do Git, selecione a ramificação que deseja fazer o rebase.

2. Selecione Rebase no menu kebab.

   

3. Selecione o branch no qual deseja fazer o rebase.

   As operações de rebase integram as alterações da ramificação que você escolher aqui na ramificação atual.

Pastas Git da Databricks execução git commit e git push --force para atualizar o Git remoto repo.

Resolver conflitos de mesclagem

conflitos merge acontecem quando 2 ou mais usuários do Git tentam merge 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. conflitos merge também podem ocorrer quando um usuário tenta extrair ou merge alterações de outra ramificação em uma ramificação com alterações não confirmadas.

Se uma operação como pull, rebase ou merge causar um conflito de merge, a UI de pastas do Git mostrará uma lista de arquivos com conflitos e opções para resolver os conflitos.

Você tem duas opções principais:

• Use a UI de pastas do Git para resolver o conflito.

• Aborte as operações do Git, descarte manualmente as alterações nos arquivos em conflito e tente as operações do Git novamente.

Ao resolver conflitos de merge com a UI de pastas do Git, o senhor deve escolher entre resolver manualmente os conflitos no editor ou manter todas as alterações recebidas ou atuais.

Mantenha tudo atualizado ou faça alterações recebidas

Se você sabe que deseja apenas manter todas as alterações atuais ou recebidas, clique no kebab à direita do nome do arquivo no painel do Notebook e selecione Manter todas as alterações atuais ou Aceitar todas as alterações recebidas. Clique no botão com o mesmo rótulo para commit as alterações e resolver o conflito.

Dica

Ficou confuso sobre qual opção escolher? A cor de cada opção corresponde às respectivas alterações de código que serão mantidas no arquivo.

Resolvendo Conflitos Manualmente

A resolução manual de conflitos permite determinar quais das linhas conflitantes devem ser aceitas na merge. Para conflitos merge , você resolve 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 merge do Git. Quando terminar, selecione Marcar como resolvido.

Se você decidir que fez escolhas erradas ao resolver conflitos merge , clique no botão Abortar para abortar o processo e desfazer tudo. Depois que todos os conflitos forem resolvidos, clique na opção Continuar merge ou Continuar rebase para resolver o conflito e concluir as operações.

Gite reset

Nas pastas Git do Databricks, o senhor pode executar um Git reset na UI do Databricks. Git Reset nas pastas Git da Databricks é equivalente a git reset --hard combinado com git push --force.

O Git Reset substitui o conteúdo do branch e a história pelo estado mais recente de outro branch. Você pode usar isso quando as edições estiverem em conflito com a ramificação upstream e não se importar em perder essas edições ao Reset para a ramificação upstream. Leia mais sobre git `Reset –hard`.

Reset para uma ramificação upstream (remota)

Com git reset neste cenário:

• Você Reset sua ramificação selecionada (por exemplo, feature_a) para uma ramificação diferente (por exemplo, main).

• Você também Reset a ramificação upstream (remota) feature_a para principal.

Importante

Ao Reset, você perde todas as alterações não confirmadas e confirmadas nas versões local e remota da ramificação.

Para Reset uma ramificação para uma ramificação remota:

1. Na interface do usuário das pastas do Git, no menu Branch, escolha o branch que o senhor deseja Reset.

   

2. Selecione Reset no menu kebab.

   

3. Selecione a ramificação para Reset.

   

Configurar o modo de checkout esparso

A verificação esparsa é 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 seu repositório estiver além dos limites suportados pelo Databricks.

Você pode usar o modo Sparse Checkout ao adicionar (clonar) um novo repositório.

1. Na caixa de diálogo Add Git folder (Adicionar pasta Git ), abra Advanced (Avançado).

2. Selecione o modo de checkout esparso.

   

3. Na caixa Padrões de cone , especifique os padrões de finalização de cone que deseja. Separe vários padrões por quebras de linha.

No momento, você não pode desabilitar o checkout esparso para um repositório no Databricks.

Como funcionam os padrões de cone

Para entender como o padrão de cone funciona no modo de verificação esparsa, consulte o diagrama a seguir que representa a estrutura do repositório remoto.

Se você selecionar o modo de verificação esparsa, 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 de repositório da seguinte forma:

Definir o padrão de cone de verificação esparsa como parent/child/grandchild resulta na inclusão recursiva de todo o conteúdo do diretório grandchild . Os arquivos imediatamente nos diretórios /parent, /parent/child e raiz também são incluídos. Veja a estrutura de diretórios no diagrama a seguir:

Você pode adicionar vários padrões separados por quebras de linha.

Observação

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

Modificar configurações de checkout esparsas

Depois que um repositório é criado, o padrão de cone de verificação esparsa 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 checkout esparso adiciona-o ao Databricks sem exigir um puxão adicional.

• Padrões de check-out esparsos não podem ser alterados para remover uma pasta quando houver alterações não confirmadas nessa pasta.

  Por exemplo, um usuário edita um arquivo em uma pasta e não commit as alterações. Ela então tenta alterar o padrão de checkout esparso para não incluir esta 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, commit as alterações e reaplicar o novo padrão.

Observação

Você não pode desativar o check-out esparso para um repositório que foi criado com o modo Check-out esparso ativado.

Faça e envie alterações com checkout esparso

O senhor pode editar os arquivos existentes e fazer o commit e o push deles a partir da pasta Git. Ao criar novas pastas de arquivos, inclua-os no padrão de cone que o senhor especificou para esse repo.

Incluir uma nova pasta fora do padrão cone resulta em 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.

Padrões para um arquivo de configuração de repositório

O arquivo de configuração de saídas de commit usa padrões semelhantes aos padrões gitignore e faz o seguinte:

• Padrões positivos permitem inclusão de saídas para Notebook correspondente.

• Padrões negativos desabilitam a inclusão de saídas para Notebook correspondente.

• Os padrões são avaliados em ordem para todos Notebook.

• Caminhos inválidos ou caminhos que não resolvem para .ipynb Notebook são ignorados.

Padrão positivo: para incluir saídas de um caminho 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 (excluídos) começam com !:

!folder/innerfolder/*.ipynb
!folder/**/*.ipynb
!**/notebook.ipynb

Limitação de checkout esparso

Atualmente, o checkout esparso não funciona para repositórios do Azure DevOps com mais de 4 GB de tamanho.

Adicione um repositório e conecte-se remotamente mais tarde

Para gerenciar e trabalhar com as pastas do Git de forma programática, use a API REST das pastas do Git.