Qual o procedimento quando tem conflitos em Artefatos de builder, fazem o merge e alteram o hash manualmente?

Question

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?

Answer 1

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.

Comments

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