Usar o controlo de versões e a implementação

Esta página pressupõe que o seu projeto já foi configurado para controlo de versões. Se vir um botão Configurar Git em vez das opções descritas nesta página, primeiro tem de configurar o Git para o seu projeto.

O Looker usa o Git para registar alterações e gerir versões de ficheiros. Cada projeto do LookML corresponde a um repositório Git e cada ramificação de programador está correlacionada com uma ramificação Git.

O Looker pode ser configurado para funcionar com muitos fornecedores de Git, como o GitHub, o GitLab e o Bitbucket. Consulte a página de documentação Configurar e testar uma ligação Git para obter informações sobre a configuração do Git para o seu projeto do Looker.

Trabalhar com ramos Git

Uma das principais vantagens do Git é que um programador do Looker pode trabalhar num ramo, uma versão isolada de um repositório de ficheiros. Pode desenvolver e testar sem afetar outros utilizadores. Enquanto programador no Looker, está a usar um ramo do Git sempre que está no modo de programação.

Outra funcionalidade importante do Git é a facilidade de colaboração com outros programadores. Pode criar um ramo e (se quiser) fazer alterações. Em seguida, outros programadores podem mudar para esse ramo para rever ou fazer alterações ao ramo. Se outro programador tiver confirmado alterações no ramo, o Looker apresenta o botão Extrair alterações remotas. Deve obter essas alterações confirmadas para a ramificação antes de fazer alterações adicionais.

Também pode eliminar uma ramificação que não seja a ramificação principal, a sua ramificação atual ou a ramificação pessoal de um programador.

Ramos pessoais

Para aumentar o desempenho, quando abre um projeto do LookML no modo de desenvolvimento pela primeira vez, o IDE do Looker apresenta a versão do modo de produção do projeto, juntamente com o botão Criar cópia do programador. Depois de clicar no botão Criar cópia do programador para o projeto, o IDE do Looker cria a sua ramificação Git pessoal e carrega o projeto do LookML no modo de desenvolvimento.

O seu ramo pessoal começa com dev- e inclui o seu nome.

A sua ramificação pessoal é específica para si e não pode ser eliminada. O seu ramo pessoal é só de leitura para todos os outros programadores. Se estiver a colaborar com outros programadores num projeto, pode criar uma nova ramificação para que outras pessoas possam mudar para essa ramificação e também contribuir com alterações.

Criar um novo ramo do Git

Se estiver a trabalhar numa correção simples e não estiver a colaborar com outros programadores, a sua ramificação pessoal é normalmente um bom local para trabalhar. Pode usar a sua ramificação pessoal para fazer atualizações rápidas e, em seguida, confirmar as alterações e enviá-las para produção.

No entanto, também pode criar novos ramos do Git, além do seu ramo pessoal. Um novo ramo do Git faz sentido nestas situações:

  • Está a trabalhar com outros programadores. Uma vez que a sua ramificação pessoal é apenas de leitura para outros programadores, se quiser colaborar com outras pessoas, deve criar uma nova ramificação do Git para que outros programadores possam escrever na ramificação. Quando estiver a colaborar com outras pessoas, certifique-se de que extrai as alterações sempre que retomar o trabalho. Desta forma, tem as atualizações mais recentes de todos os programadores antes de continuar o trabalho.
  • Está a trabalhar em vários conjuntos de funcionalidades em simultâneo. Por vezes, pode estar a meio de um projeto importante, mas querer resolver um problema menor ou fazer uma correção rápida. Neste caso, pode confirmar as alterações no ramo em que se encontra e, em seguida, criar ou mudar para outro ramo para trabalhar num conjunto separado de funcionalidades. Pode fazer a correção na nova ramificação e, em seguida, implementar as alterações dessa ramificação na produção, antes de retomar o trabalho na ramificação original.

Antes de criar uma nova ramificação:

  • Se tiver um conflito de união no ramo atual, tem de resolver o conflito antes de poder criar um novo ramo.
  • Se tiver alterações não consolidadas no ramo atual, tem de consolidar as alterações no ramo atual antes de criar um novo ramo.
  • Se quiser criar uma ramificação a partir de uma ramificação de desenvolvimento existente (e não da ramificação de produção), comece por obter a versão mais recente da ramificação de desenvolvimento mudando para essa ramificação de desenvolvimento e, em seguida, extraia as alterações remotas para sincronizar a versão local dessa ramificação.

Para criar um novo ramo do Git:

  1. Verifique se tem o modo de desenvolvimento ativado.
  2. Navegue para os ficheiros do projeto no menu Desenvolver.

  3. Selecione o ícone Git no menu de ícones do lado esquerdo para abrir o painel Ações do Git.

  4. Selecione o menu pendente Ver ramificações.

  5. Selecione Novo ramo.

  6. Na janela Novo ramo, introduza um nome para o ramo. Tenha em atenção que existem limitações para os nomes de ramificações do Git. Para ver os requisitos de nomenclatura, consulte as Regras para atribuir um nome a uma ramificação do Git nesta página.

  7. Selecione o menu pendente Criar a partir de e selecione uma ramificação existente para usar como ponto de partida para a nova ramificação.

  8. Selecione Criar para criar a ramificação.

Em alternativa, pode criar ramos do Git no separador Gestão de ramos das definições do projeto.

Regras para atribuir um nome a um ramo do Git

O Looker usa os requisitos da convenção de nomenclatura de ramificações especificados pelo Git.

Os nomes dos ramos do Git não podem:

  • Conter um caráter de espaço
  • Incluem um ponto duplo: ..
  • Contém uma barra invertida: \
  • Contém a sequência: @{
  • Contém um ponto de interrogação: ?
  • Contém um parêntese reto de abertura: [
  • Contêm um caráter de controlo ASCII: ~, \^ ou :
  • Começar com um ponto: .
  • Comece com o prefixo: dev- (reservado para as ramificações pessoais dos programadores do Looker)
  • Termine com uma barra: /
  • Terminar com a extensão: .lock

Além disso, o nome da ramificação só pode conter um asterisco (*) se o asterisco representar um componente de caminho completo (por exemplo, foo/* ou bar/*/baz). Nesse caso, é interpretado como um caráter universal e não como parte do nome real da ramificação.

Mudar para outro ramo do Git

Se tiver um conflito de união no ramo atual, tem de resolver o conflito antes de poder mudar para um ramo diferente.

Além disso, se tiver alterações não confirmadas na ramificação atual, não pode mudar para uma ramificação existente até confirmar as alterações na ramificação atual.

Para mudar para um ramo do Git diferente, siga estes passos:

  1. No projeto, navegue para o painel Ações do Git selecionando o ícone Git no menu de ícones do lado esquerdo.
  2. No painel Ações do Git, selecione o menu pendente do ramo do Git à direita do nome do ramo do Git atual.
  3. Selecione o ramo para o qual quer mudar selecionando-o no menu ou escrevendo o nome do ramo na caixa de pesquisa. A pesquisa do nome do ramo não é sensível a maiúsculas e minúsculas. Por exemplo, pode pesquisar "DEV" e ver todas as ramificações com nomes que incluem "dev", "DEV", "Dev" e assim sucessivamente.

Gerir ramos do Git

O separador Gestão de ramificações das definições do projeto mostra uma tabela de todas as ramificações do Git para o projeto do Looker. Para abrir o separador Gestão de ramificações, navegue primeiro para as definições do projeto selecionando o ícone Definições no menu de ícones do lado esquerdo. Em seguida, selecione o separador Gestão de filiais.

No separador Gestão de filiais, pode:

  1. Selecione o botão Novo ramo para criar um novo ramo. Consulte a secção Criar um novo ramo do Git nesta página para mais informações.
  2. Pesquise nomes de ramos na barra de pesquisa.
  3. Atualize a tabela selecionando o botão Atualizar.
  4. Ordene a tabela selecionando um nome de coluna.

A tabela inclui as seguintes informações:

  • Nome: nome da ramificação do Git. Os ramos pessoais dos programadores do Looker começam com dev- e incluem o nome próprio e o apelido do programador.
  • Estado: a diferença entre a versão local da ramificação e a versão remota da ramificação. Por exemplo, um estado de 3 commits behind significa que a sua versão local do ramo está três commits atrás da versão remota do ramo. Uma vez que o Looker usa sempre a versão remota da ramificação principal, o separador Gestão de ramificações não mostra o estado da versão local da ramificação principal. Pode sempre considerar que a ramificação principal está atualizada.
  • Última atualização: o tempo decorrido desde que um programador do Looker fez uma confirmação no ramo.
  • Ações: um botão para eliminar a ramificação ou o motivo pelo qual a ramificação não é elegível para eliminação.

Eliminar ramos Git

No separador Gestão de ramificações, pode eliminar ramificações que tenham um botão Eliminar na tabela. Não pode eliminar os seguintes ramos:

  • O ramo principal
  • O seu ramo atual
  • O ramo pessoal de um programador do Looker

Na tabela, estas ramificações não têm um botão Eliminar. Em alternativa, a coluna Ação da tabela mostra o motivo pelo qual não é possível eliminar a ramificação.

Não é possível restaurar uma ramificação depois de eliminada. Quando elimina uma ramificação, o Looker remove a versão local e a versão remota da ramificação.

No entanto, se a ramificação tiver sido criada por outro programador do Looker ou se outros programadores tiverem feito o check-out da ramificação, esses programadores continuam a ter a respetiva versão local da ramificação. Se um programador do Looker confirmar alterações na respetiva versão local do ramo e as enviar para produção, volta a ver uma versão remota do ramo. Isto pode ser útil se quiser restaurar a ramificação. Caso contrário, quando elimina uma ramificação, todos os outros programadores do Looker devem eliminar a mesma ramificação para garantir que não pode ser acidentalmente reposta por alguém que a envie para o repositório remoto.

Para eliminar uma ou mais ramificações do Git do seu projeto, navegue primeiro para as definições do projeto selecionando o ícone Definições no menu de ícones do lado esquerdo. Em seguida, selecione o separador Gestão de filiais. No separador Gestão de filiais, pode eliminar filiais de duas formas:

  1. Elimine várias ramificações selecionando primeiro as caixas de verificação das ramificações e, em seguida, selecionando Eliminar ramificações selecionadas.
  2. Para eliminar uma única ramificação, selecione Eliminar junto ao nome da ramificação.

Executar comandos Git no Looker

O Looker tem uma interface integrada que se integra com o seu serviço Git. O Looker apresenta o botão Git no canto superior direito do IDE do LookML.

O botão Git mostra opções diferentes consoante o ponto em que se encontra no processo de fazer alterações e implementar na produção. Em geral, a opção apresentada no botão é a melhor orientação para a sua próxima ação.

Se a ramificação do programador estiver sincronizada com a ramificação de produção, o botão do Git apresenta a mensagem Atualizado e não é selecionável.

Depois de configurar o projeto para o Git, pode selecionar o botão Ações do Git para abrir o painel Ações do Git.

Os comandos disponíveis no painel Ações do Git dependem do ponto em que se encontra no processo de fazer alterações e implementar na produção.

Colocar as alterações em produção

Com a integração do Git do Looker predefinida, o Looker pede aos programadores que sigam o seguinte fluxo de trabalho do Git:

Isto significa que, com a integração do Git predefinida, todos os programadores unem as respetivas alterações num ramo denominado master, e a confirmação mais recente no ramo master é o que é usado para o ambiente de produção do Looker.

Para implementações avançadas do Git, pode personalizar este fluxo de trabalho:

  • Pode fazer com que os programadores enviem pedidos de obtenção para a ramificação de produção do Git, em vez de permitir que os programadores unam as respetivas alterações através do IDE do Looker. Consulte a página de documentação Configurar definições de controlo de versões do projeto para ver detalhes.
  • Pode usar o campo Nome do ramo de produção do Git para especificar que ramo do seu repositório Git o Looker deve usar como ramo de destino no qual os ramos dos seus programadores do Looker são unidos. Consulte a página de documentação Configurar definições de controlo de versões do projeto para ver detalhes.
  • Pode usar o modo de implementação avançado para especificar um SHA de commit ou um nome de etiqueta diferente para implementar no seu ambiente de produção do Looker, em vez de usar o commit mais recente no ramo de produção. (Se quiser implementar uma confirmação de um ramo diferente, pode usar o webhook do modo de implementação avançado ou o ponto final da API.) Consulte a página de documentação do modo de implementação avançado para ver detalhes.

Se vir um botão Configurar Git em vez das opções descritas nesta secção, primeiro tem de configurar o Git para o seu projeto.

Visualizar alterações não consolidadas

O IDE do LookML tem vários indicadores que são apresentados quando está no modo de desenvolvimento e tem alterações não comprometidas, conforme descrito na secção Marcar adições, alterações e eliminações da página de documentação Vista geral do IDE do Looker.

Pode obter um resumo das diferenças de todos os ficheiros selecionando a opção Ver alterações não comprometidas no painel Ações do Git.

Na janela Alterações não comprometidas no projeto, o Looker apresenta um resumo de todas as alterações guardadas e não comprometidas em todos os ficheiros do projeto. Para cada alteração, o Looker mostra o seguinte:

  • O nome do ficheiro substituído e o nome do ficheiro adicionado.
    • O nome do ficheiro substituído (indicado com ---) e o nome do ficheiro adicionado (indicado com +++). Em muitos casos, isto pode mostrar diferentes versões do mesmo ficheiro, com revisões identificadas por --- a/ e +++ b/.
    • Os ficheiros eliminados são apresentados como substitutos de um ficheiro nulo (+++ /dev/null).
    • Os ficheiros adicionados são apresentados como substitutos de um ficheiro nulo (--- /dev/null).
  • O número da linha onde a alteração começa.

    Por exemplo, -101,4 +101,4 indica que, na linha 101 do ficheiro, foram removidas 4 linhas e adicionadas 4 linhas. Um ficheiro eliminado com 20 linhas apresentaria -1,20 +0,0 para indicar que, na primeira linha do ficheiro, foram removidas 20 linhas e substituídas por zero linhas.
  • O texto que foi atualizado:
    • As linhas eliminadas são apresentadas a vermelho.
    • As linhas adicionadas são apresentadas a verde.

Para apresentar um resumo das diferenças de um único ficheiro, selecione a opção Ver alterações no menu do ficheiro.

A confirmar alterações

Depois de fazer e guardar alterações ao seu projeto LookML, o IDE pode exigir que valide o seu LookML. Neste cenário, o botão do Git apresenta o texto Validar LookML.

Se isto é necessário, depende da definição do seu projeto para a qualidade do código. Para mais informações sobre o validador de conteúdo, consulte a página de documentação Validar o seu LookML.

Se outro programador tiver feito alterações à ramificação de produção desde a última vez que atualizou a sua ramificação local, o Looker exige que extraia essas atualizações da ramificação de produção. Neste cenário, o botão Git apresenta o texto Extrair da produção.

Se o seu projeto estiver ativado para o modo de implementação avançado, o botão do Git apresenta o texto Extrair do ramo principal.

Depois de guardar as alterações (e corrigir quaisquer avisos ou erros do LookML, se necessário) e extrair da produção (se necessário), o botão do Git apresenta o texto Confirmar alterações e enviar.

Se quiser, pode primeiro rever as alterações não confirmadas antes de as confirmar.

Quando tiver tudo a postos para confirmar as alterações, use o botão do Git para confirmar estas alterações no ramo atual. O Looker apresenta a caixa de diálogo Commit, que lista os ficheiros que foram adicionados, alterados ou eliminados.

Introduza uma mensagem que descreva brevemente as suas alterações e desmarque as caixas de verificação junto a todos os ficheiros que não quer incluir na sincronização. Em seguida, selecione Confirmar para confirmar as alterações.

A verificar se existem PDTs não compiladas

Se fez alterações a quaisquer PDTs no seu projeto, é ideal que todos os PDTs sejam criados quando implementar na produção, para que as tabelas possam ser usadas imediatamente como as versões de produção. Para verificar o estado das PDTs no projeto, selecione o ícone Estado do projeto para abrir o painel Estado do projeto e, de seguida, selecione o botão Validar estado das PDTs.

Consulte a página de documentação Tabelas derivadas no Looker para obter mais informações sobre como verificar PDTs não criadas no seu projeto do LookML e trabalhar com tabelas derivadas no modo de desenvolvimento.

Executar testes de dados

O seu projeto pode incluir um ou mais parâmetros test que definem testes de dados para validar a lógica do seu modelo LookML. Consulte a página de documentação do parâmetro test para ver informações sobre a configuração de testes de dados no seu projeto.

Se o seu projeto contiver testes de dados e estiver no modo de desenvolvimento, pode iniciar os testes de dados do projeto de várias formas:

  1. Se as definições do projeto estiverem configuradas para exigir a aprovação em testes de dados antes de implementar os ficheiros para produção, o IDE apresenta o botão Executar testes depois de confirmar as alterações ao projeto para executar todos os testes do projeto, independentemente do ficheiro que define o teste. Tem de passar nos testes de dados antes de poder implementar as alterações na produção.
  2. Selecione o botão Executar testes de dados no painel Estado do projeto. O Looker executa todos os testes de dados no seu projeto, independentemente do ficheiro que define o teste.
  3. Selecione a opção Executar testes LookML no menu do ficheiro. O Looker executa apenas os testes definidos no ficheiro atual.

Depois de executar os testes de dados, o painel Estado do projeto apresenta o progresso e os resultados.

  • Um teste de dados é aprovado quando a afirmação do teste é verdadeira para todas as linhas na consulta do teste. Consulte a página de documentação do parâmetro test para ver detalhes sobre a configuração de afirmações e consultas de teste.
  • Se um teste de dados falhar, o painel Estado do projeto fornece informações sobre o motivo da falha do teste, se o teste encontrou erros na lógica do seu modelo ou se foi o próprio teste que foi inválido.
  • Nos resultados do teste de dados, pode selecionar o nome de um teste de dados para aceder diretamente ao LookML do teste de dados ou pode selecionar o botão Consultar explorar para abrir uma exploração com a consulta definida no teste de dados.

Implementação na produção

Depois de consolidar as alterações na ramificação, o IDE do Looker pede-lhe que as combine com a ramificação principal. O tipo de comando que vê no IDE depende da configuração do seu projeto:

  • Se o seu projeto estiver configurado para o modo de implementação avançado, o IDE pede-lhe que combine as suas alterações no ramo principal. Depois de confirmar a união, um programador do Looker com a autorização deploy pode implementar a confirmação na produção através do gestor de implementação do IDE do Looker ou através de um webhook ou um ponto final da API.
  • Se o seu projeto estiver configurado para integração do Git através de pedidos de envio, é-lhe pedido que abra um pedido de envio através da interface do seu fornecedor do Git.
  • Caso contrário, com a integração do Git do Looker predefinida, se tiver autorização deploy, o IDE do Looker pede-lhe que sincronize as suas alterações com o ramo de produção e implemente as alterações na versão de produção da sua instância do Looker.

Modo de implementação avançado

Com a integração do Git do Looker predefinida, os programadores do Looker consolidam as respetivas alterações no ramo de desenvolvimento e, em seguida, unem o ramo de desenvolvimento ao ramo de produção. Em seguida, quando implementa no ambiente do Looker, o Looker usa a confirmação mais recente no ramo de produção. (Consulte a secção Como aplicar as alterações à produção nesta página para ver o fluxo de trabalho Git predefinido e outras opções para implementações Git avançadas.)

Nos casos em que não quer que o ambiente de produção use sempre a confirmação mais recente, um programador com autorização deploy pode usar o modo de implementação avançado para especificar a confirmação exata a usar no seu ambiente do Looker. Isto é útil em fluxos de trabalho de programadores com vários ambientes, em que cada ambiente aponta para uma versão diferente de uma base de código. Também dá a um ou vários programadores ou administradores um maior controlo sobre as alterações implementadas na produção.

Quando o modo de implementação avançado está ativado, o IDE do Looker não pede aos programadores que implementem as respetivas alterações na produção. Em alternativa, o IDE pede aos programadores que unam as respetivas alterações ao ramo de produção. A partir daí, as alterações só podem ser implementadas das seguintes formas:

  • Usar o gestor de implementação no IDE do Looker
  • Acionar um webhook
  • Usar um ponto final da API

Consulte a página de documentação do modo de implementação avançado para ver detalhes.

Verificar o impacto das alterações

Depois de disponibilizar as alterações à organização, pode usar a validação de conteúdo para se certificar de que não invalidou nenhum painel de controlo nem Looks guardados. Se tiver, tem a oportunidade de os corrigir.

Gerir problemas típicos

Enquanto trabalha no seu modelo, pode ter de:

  • Abandone as alterações

    Ocasionalmente, pode querer abandonar as alterações de modelagem de dados. Se ainda não tiverem sido guardadas, basta atualizar a página ou sair da mesma e, em seguida, aceitar o pedido de aviso. Se tiver guardado as alterações, pode reverter as alterações não comprometidas, conforme descrito na secção Reverter alterações não comprometidas.

  • Resolva conflitos de união com o trabalho de outros programadores

    Se tiver mais do que um programador a trabalhar no seu modelo de dados, o Git processa normalmente a situação. No entanto, ocasionalmente, o Git precisa de uma pessoa para resolver conflitos de união.

Algumas alterações, como a alteração do nome de um campo, podem afetar os painéis de controlo e os Looks existentes. Conforme mencionado anteriormente, depois de disponibilizar as alterações à organização, pode usar a validação de conteúdo para verificar o conteúdo e corrigir eventuais problemas.

Reverter alterações não consolidadas

Quando trabalha na sua ramificação de desenvolvimento pessoal, pode reverter as alterações não comprometidas que guardou se não quiser implementá-las. Pode reverter todas as alterações não confirmadas de todos os ficheiros no projeto ou apenas as alterações num único ficheiro.

Para reverter alterações não consolidadas para todos os ficheiros:

  1. Selecione a opção Reverter para… no painel Ações do Git.
  2. Selecione uma opção de reversão:
    • Para reverter apenas as alterações não consolidadas, selecione Reverter alterações não consolidadas. Também pode selecionar o link Ver alterações para ver as alterações que seriam revertidas.
    • Para reverter todas as alterações, incluindo as não consolidadas e as consolidadas, selecione Reverter para produção
  3. Para concluir o processo de reversão, selecione Confirmar.

Para reverter quaisquer adições ou eliminações no conteúdo de um único ficheiro, selecione a opção Reverter alterações no menu desse ficheiro:

Quando muda o nome de um ficheiro, está essencialmente a eliminar o ficheiro original e a criar um novo ficheiro com um novo nome. Como isto envolve mais do que um ficheiro, não pode usar a opção Reverter ficheiro para anular a mudança do nome de um ficheiro. Se quiser anular a mudança do nome de um ficheiro, use a opção Reverter para… no painel Ações do Git.

Além disso, se tiver eliminado um ficheiro, este deixa de ser apresentado no explorador de ficheiros do IDE. Se quiser reverter a eliminação de um ficheiro, use a opção Reverter para… no painel Ações do Git.

Resolver conflitos de união

Normalmente, o Git pode unir automaticamente as novas alterações com a versão de produção dos seus ficheiros LookML. Ocorre um conflito de união quando o Git encontra alterações em conflito e não consegue identificar que alterações devem ser mantidas, normalmente quando outro programador fez alterações desde a última vez que fez pull e fez alterações na mesma área. Se tiver um conflito de união no seu código, o Looker apresenta um aviso de Conflitos de união depois de confirmar as alterações e extrair da produção.

Quando o Looker mostra o aviso de conflito de união, recomendamos que resolva o conflito de união antes de fazer mais alterações. O envio de um conflito de união para a produção causa erros de análise que podem impedir a exploração dos seus dados. Se for um utilizador avançado do Git e quiser continuar a enviar alterações, selecione o botão Não resolver.

No próprio ficheiro LookML, as linhas com conflitos são marcadas da seguinte forma:

<<<<<<< HEAD
Your code
&#61;&#61;&#61;&#61;&#61;&#61;&#61;
Production code
>>>>>>> branch 'master'

O Looker mostra os seguintes marcadores de união para indicar os conflitos de união:

  • <<<<<<< HEAD marca o início das linhas em conflito.
  • >>>>>>> branch 'master' marca o fim das linhas em conflito.
  • ======= separa cada versão do código para que as possa comparar.

No exemplo anterior, your code representa as alterações que confirmou e production code representa o código no qual o Git não conseguiu unir automaticamente as suas alterações.

Para resolver um conflito de união:

  1. Encontre os ficheiros com conflitos de união. O Looker marca estes ficheiros a vermelho. Em alternativa, também pode pesquisar no seu projeto marcadores de união, como <<<< ou HEAD, para encontrar todos os conflitos no seu projeto. Também pode encontrar os ficheiros afetados selecionando o link files no aviso de união apresentado no painel Git Actions.
  2. No ficheiro, aceda às linhas com conflitos de união, elimine a versão do texto que NÃO quer manter e elimine também todos os marcadores de conflitos de união.
  3. Guarde o ficheiro e repita os passos anteriores para quaisquer outros ficheiros marcados com conflitos de união.

  4. Depois de resolver todos os conflitos de união e eliminar todos os marcadores de união do seu projeto, confirme as alterações e implemente-as na produção.

Agora que resolveu o conflito de união e enviou a sua resolução para produção, outros programadores podem extrair a partir da produção e continuar a trabalhar como habitualmente.

Recolha de lixo do Git

A recolha de lixo do Git limpa os ficheiros desnecessários e comprime as revisões de ficheiros para otimizar o seu repositório Git. A recolha de lixo do Git (git gc) é executada automaticamente quando a sua instância do Looker é atualizada ou reiniciada. Para evitar a execução do git gc com demasiada frequência, o Looker aguarda 30 dias desde a última git gc e, em seguida, executa o git gc no reinício seguinte.

Em casos raros, pode tentar enviar alterações para remoto ou enviar ramificação para remoto enquanto o git gc está em execução. Se o Looker apresentar um erro, aguarde um ou dois minutos e, em seguida, tente novamente enviar as alterações.