execução Git operações em Databricks Git pastas (Repos)

Os artigos descrevem como realizar operações Git comuns em seu Databricks workspace usando pastas 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 em que deseja criar o clone do repositório Git.

2. Clique na seta para baixo à direita de Add (Adicionar ) no canto superior direito do site workspace e selecione a pastaGit 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 do repositório clonado
   • Se você usará ou não o checkout esparso, no qual somente um subconjunto dos diretórios do seu repositório é clonado, especificado usando um padrão de cone. Isso é útil se o seu repositório for maior do que os limites suportados pelo Databricks.

   

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

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

Databricks Git As pastas se comportam efetivamente como clientes Git incorporados no seu workspace para que os usuários possam colaborar usando o controle de origem e o controle de versão baseados no Git. Para tornar a colaboração em equipe mais eficaz, use uma pasta Git separada da Databricks mapeada para um repositório Git remoto 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 sua área de transferência local, que você pode enviar para 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.

important

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 repositório Git usando o CLI por meio do terminal da Web de um cluster, os arquivos não serão exibidos na UI do Databricks.

Acessar a caixa de diálogo Git

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

• 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 do repositório. O senhor também pode clicar com o botão direito do mouse no nome do repositório 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 de trabalho atual. Você 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 a mesma workspace. Veja as melhores práticas recomendadas para evitar esse problema.
2. O botão para criar uma nova ramificação.
3. A lista de arquivos ativos e subpastas verificados em seu ramo atual.
4. Um botão que leva o senhor ao seu provedor Git e mostra o histórico da filial 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 remoto Git.

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

Esta é a sua casa para executar Git operações na pasta workspace Git . O senhor está limitado às operações do Git apresentadas na interface do usuário.

Crie uma nova filial

O senhor pode criar um novo ramo com base em um ramo existente na caixa de diálogo Git:

Mudar para uma filial diferente

O senhor pode mudar para (checkout) um ramo diferente usando o ramo dropdown na caixa de diálogo Git:

important

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 repositório remoto, 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.

Fazer commit e push das alterações no 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 commit necessária para as alterações e clique em commit & Push para enviar essas alterações para o repositório remoto Git.

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

nota

• 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

Pull de 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 remoto Git. Se as alterações extraídas do repositório remoto entrarem em conflito com as alterações locais em Databricks, o senhor precisará resolver os conflitos demerge.

important

Git As operações que puxam as alterações upstream limpam o estado do Notebook. Para obter mais informações, consulte As alterações recebidas limpam o estado do Notebook.

mesclar ramificações

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

A função merge em Databricks Git pastas 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 os iniciantes em Git, recomendamos o uso de merge (em vez de rebase), pois não é necessário forçar o push para uma ramificação e, portanto, não reescreve a história de commit.

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

Rebase um galho em outro galho

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

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

1. Salva o commit em seu branch atual em uma área temporária.
2. Redefine o ramo atual para o ramo escolhido.
3. Reaplica cada commit individual salvo anteriormente na ramificação atual, resultando em um histórico linear que combina alterações de ambas as ramificações.

atenção

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

Um fluxo de trabalho comum é fazer o rebase de 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 a ramificação na qual você deseja se basear.

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

Databricks Git execução das pastas git commit e git push --force para atualizar o repositório remoto Git.

Resolver merge conflitos

Os conflitos de mesclagem ocorrem quando dois ou mais Git usuários merge do tentam fazer alterações nas mesmas linhas de um arquivo em um ramo comum e o Git não consegue escolher as alterações "certas" a serem aplicadas. Conflitos de mesclagem também podem ocorrer quando um usuário tenta fazer pull ou merge alterações de outro ramo para um ramo com alterações não confirmadas.

Se uma operação como pull, rebase ou merge causar um conflito merge, a interface do usuário de pastas Git mostrará uma lista de arquivos com conflitos e opções para resolvê-los.

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 novamente as operações do Git.

Ao resolver conflitos de merge com a interface de usuário de pastas 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 as alterações recebidas

Se o senhor sabe que deseja manter apenas todas as alterações atuais ou recebidas, clique no botão à direita do nome do arquivo no painel 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

Confuso 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 conflitos manualmente

A resolução manual de conflitos permite que o senhor determine qual das linhas conflitantes deve ser aceita no site merge. Para conflitos no site merge, o senhor 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, inclusive os marcadores de conflito Git merge . Quando terminar, selecione Marcar como resolvido .

Se o senhor decidir que fez as escolhas erradas ao resolver os conflitos do merge, clique no botão Abort para abortar o processo e desfazer tudo. Quando todos os conflitos forem resolvidos, clique na opção Continue merge ou Continue Rebase para resolver o conflito e concluir as operações.

Git reset

Nas pastas Git do Databricks, o senhor pode executar um Git reset na interface do usuário do Databricks. Git Reiniciar em Databricks Git pastas é equivalente a git reset --hard combinado com git push --force.

Git Reset substitui o conteúdo e o histórico da ramificação pelo estado mais recente de outra ramificação. Isso pode ser usado quando as edições estão em conflito com o ramo upstream e o senhor não se importa em perder essas edições ao redefinir para o ramo upstream. Leia mais sobre git reset –hard.

Reset para uma ramificação upstream (remota)

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.

important

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 no menu kebab.

   

3. Selecione a filial a ser redefinida.

   

Configurar o modo de pagamento esparso

O checkout esparso é uma configuração do lado do cliente que permite que o senhor clone e trabalhe 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 pagamento esparso.

   

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

No momento, não é possível desativar o checkout esparso de um repositório na Databricks.

Como funcionam os padrões de cone

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

Se o senhor selecionar o modo de checkout Sparse , mas não especificar um padrão de cone, o padrão de cone default será aplicado. Isso inclui somente os arquivos na raiz e nenhum subdiretório, resultando em uma estrutura de repositório da seguinte forma:

Definir o padrão esparso do cone de checkout 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 estã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.

nota

Os comportamentos de exclusão (!) não são compatíveis com a sintaxe de padrão de cone do Git.

Modificar configurações esparsas de checkout

Depois que um repositório é criado, o padrão esparso de cone de checkout 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.

• A adição de uma pasta por meio da edição do padrão de cone de checkout esparso a adiciona ao Databricks sem exigir um pull adicional.

• Os padrões de checkout esparsos não podem ser alterados para remover uma pasta quando há alterações não confirmadas nessa pasta.

  Por exemplo, um usuário edita um arquivo em uma pasta e não faz commit alterações. Em seguida, ela tenta alterar o padrão de pagamento 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, commit as alterações e, em seguida, reaplicar o novo padrão.

nota

Você não pode desativar o checkout esparso para um repositório que foi criado com o modo Sparse Checkout ativado.

Faça e promova alterações com finalização de compra esparsa

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-as no padrão de cone que você especificou para esse repositório.

A inclusão de uma nova pasta fora do padrão do cone resulta em um erro durante as operações commit e push. Para corrigi-lo, edite o padrão de cone para incluir a nova pasta que o senhor está tentando commit e envie.

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:

• Os padrões positivos permitem a inclusão de saídas para o Notebook de correspondência.
• Os padrões negativos desativam a inclusão de saídas para o Notebook correspondente.
• Os padrões são avaliados em ordem para todos os Notebooks.
• Os caminhos inválidos ou os caminhos que não estão sendo resolvidos para o .ipynb Notebook são ignorados.

Padrão positivo: Para incluir saídas de um caminho do 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. Os padrões negativos (exclude) começam com !:

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

Limitação esparsa de checkout

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.