+3 votos
31 visitas
Peguei uma situação entre dois desenvolvedores cada um incluiu um campo na mesma tabela, então no momento do merge tinha 3 hash o antigo e dois hash que foram gerados da nova tabela.

Como era bem simples alteração aceitei o de um e refiz alteração do outro, mas pensnado em campos mais complexos isso fica inviável.

O merge dá pra fazer tranquilamente, minha dúvida como estão gerando o hash novamente?
por (19 pontos) | 31 visitas

1 Resposta

+1 voto
Olá.  Hoje o hash funciona como um flag, indicando que houve alteração, a validação dele é parcial, desta forma, basta que seja um hash diferente do atual para que o Builder indentifique a alteração.
por (11 pontos)
Você coloca qualquer valor no hash no momento do merge?
Você deve utilizar um dos novos gerados.
Isso que não entendi, se eu manter um dos gerados alguém vai ficar sem receber atualização... se eu manter o hash do desenvolvedor que criou o campo A, jogo as alterações do desenvolvedor que criou o campo B... o desenvolvedor que mantive o hash não irá receber as atualizações do campo B porque não teve alteração... entendo que deveria ter gerado um 3º hash nesse caso.
em um arquivo de tabela existe um HASH para a tabela e um HASH para cada campo.
Se o HASH da tabela for igual, ele não verifica mais nada e sai. se for diferente, ele vai percorrer os campos.
cada HASH diferente de campo que encontrar, vai percorrer os fields para encontrar as diferenças.
então, se o HASH da tabela for diferente, ele vai fazer todos os campos que houver diferença.
consegui ser claro?
isso entendi, mas é exatamente esse ponto... se eu gerar um novo hash (tabela) o builder vai entender que teve alteração... ai os hash dos campos eu mantenho o mesmos.. então o desenvolvedor que tem o campo A o builder não vai fazer nada, mas vai ver que teve alteração no Hash do campo vai atualizar. Posso não estar sendo claro no meu problema.
Também vejo que existe um problema na questão do HASH, uma possível solução seria com um tipo de script que seja executado no GitLab (no server) para forçar a alteração do HASH toda vez que um artefato de builder seja commitado.

Também já tivemos problemas com desenvolvedores que não pegam nem o hash A, nem o hash B (deixam o antigo), o que causa a não liberação da alteração. Outro problema foi com desenvolvedores que fizeram alteração diretamente no arquivo (com o VSCode) e esqueceram de alterar o hash.

Todas estas situações se resolveriam se o GitLab forçasse a alteração do hash num hook de "pré-commit".
Melhores May 2020
  1. henrique.muller

    18 Pontos

  2. joao.melo

    14 Pontos

  3. joseglauber

    11 Pontos

  4. SlimShady

    7 Pontos

  5. willian.metalsystem

    6 Pontos

  6. lucas.melo

    3 Pontos

  7. fluipress.luciano

    2 Pontos

  8. pajucara.wallacef

    2 Pontos

  9. jean.filho

    2 Pontos

  10. maicon.pereira

    2 Pontos

200 pontos
Melhores 2020 May 25 - 31
    433 perguntas
    476 respostas
    346 comentários
    466 usuários