7
respostas

Lock no arquivo

Como posso realizar um lock de um arquivo para que outro desenvolvedor não alterar enquanto estiver realizando modificações ?

7 respostas

Olá Joylson,

No git não tem como fazer isto por padrão. Até porque o repositório é distribuído, fazendo com que várias cópias do arquivo existam.

Existe uma extensão que ajuda com isto, para o caso de arquivos que não são "mergeáveis" (binários ou muito grandes para fazer o merge...)

O nome da extensão é git LFS (https://github.com/git-lfs/git-lfs)

Se a sua vontade de fazer lock é só pra se preservar de ter que fazer um merge. Você pode dar uma olhada em como funciona o comando rebase. Ele permite mudar a forma de trabalhar com as alterações dos seus colegas de trabalho.

Além do mais se fosse para bloquear o arquivo, deixaria o processo mas lento para desenvolvimento! O pessoal só poderia usar o arquivo quando você concluísse!

Mas como eu faria para "proteger" um arquivo, por exemplo, de conexão com banco? Imagine o seguinte caso: na minha branch desenvolvimento o meu arquivo de banco aponta para o banco de desenvolvimento. Ja na branch master, o arquivo de banco aponta para produção. Minha intenção com esse lock é fazer com que todos os devs que fizerem um branch para uma nova funcionalidade a partir de desenvolvimento, não precisassem se preocupar com o apontamento para o banco, por que ele estaria bloqueado do versionamento e sempre apontando para o banco de desenvolvimento. Entende?

Nesse caso, é bom uma comunicação entre os devs, nada que não se resolva em um coffebreak tomando aquele cafezinho sarado ou em uma Daily Scrum!!

A ideia do cafezinho é massa, mas eu estava procurando uma solução mais anti falha humana. Sabe como é né?

Bom dia Vinícius,

Algumas idéias para você organizar de outra forma esta configuração do banco...

Dependendo da tecnologia que você estiver usando será interessante manter todas as configurações de banco num único arquivo (seja de desenvolvimento, teste e/ou homologação), ao invés de ter cada branch com uma configuração diferente. Por alguns motivos: - o que você já falou erro humano, caso alguém commite errado na branch master vai acabar dando trabalho e sujando com uma configuração de banco errada. - a configuração do seu banco de produção não está muito segura sendo guardada no seu controle de versão (na minha visão, e já explico o motivo)

Perceba que acima eu não disse pra colocar a configuração de produção junto com as outras, esta configuração (login + senha, por exemplo) pode (e deve) ser gerenciada de uma forma diferente.

Uma idéia é deixar na sua ferramenta de controle de build e deploy (integração contínua e afins), desta forma seus devs não precisam saber a configuração do banco de produção, o que ajuda não só a proteger o seu ambiente de prod como também deixa os devs mais seguros na hora de fazer alterações no código de desenvolvimento.

Diversas ferramentas suportam armazenar estas informações secretas como bamboo, gitlab CI, etc.

Uma outra forma de configurar isto é usar uma ferramenta de gestão de secrets, por exemplo a Vault da HashiCorp, só que neste caso você precisa que a empresa tenha uma certa maturidade para gerenciar todo o processo de build e deploy. Essa ferramenta pode armazenar dados num cofre para deixar completamente isoladas as senhas e informações críticas dos desenvolvedores e quem mais estiver precisando acessar o banco.

Concluindo, acredito que o melhor seria tirar senhas de produção do seu controle de versão... Já que qualquer um com acesso de leitura no repositório consegue fazer o que quiser sem rastreio nenhum.

Obrigado Luan, vou dar uma olhada nessas ferramentas que você passou.

Quer mergulhar em tecnologia e aprendizagem?

Receba a newsletter que o nosso CEO escreve pessoalmente, com insights do mercado de trabalho, ciência e desenvolvimento de software