O problema: quando vários usuários tiverem acesso ao mesmo diretório de trabalho, poderão ocorrer problemas de permissão nos metadados, se houvergit operações são realizadas.

AVISO LEGALAntes de você me criticar - eu percebo que compartilhar um diretório de trabalho é contrário ao que o Git defende, e eu não estou falando sobre fazer nada além de operações somente leitura neste diretório compartilhado - nós fazemos todo o nosso trabalho em nossos próprios repositórios locais.

Estou aberto a sugestões quanto a outra maneira de fazer o que estamos tentando fazer, pois nossa abordagem certamente não é a melhor prática, mas não tenho certeza dessa conversa que seria útil para os outros ouvirem. Então, por enquanto, deixe-me fornecer alguns detalhes sobre por que estamos fazendo isso:

Temos vários mestres de construção em nossa equipe. Nós implantamos em servidores Linux, e fazemos nossas compilações lá, com scripts de construção que são extraídos diretamente do Git. Nós não podemos usar o CI (como o Jenkins / cruisecontrol) neste momento, por isso temos um repositório que nós fazemos checkout e fazemos nossas compilações de QA.

Existem algumas operações do git que executamos como parte do script. Isso inclui algumas marcações de commits (o material é marcado como QA-current, QA-previous, etc ...). Então eu acho que não somos realmente somente leitura. Devido à natureza do script de construção, nós o executamossudocomo um usuário comum (vamos chamar esse usuário DevAdmin). Eu percebo que isso pode ser uma má prática, e talvez seja a fonte da dor, já que nos força a usar um checkout de recompra compartilhado.

Isso tudo ficaria bem, se estivéssemos sempre sudo quando estivéssemos nesse diretório de trabalho. A questão é que, ocasionalmente, um de nós fará umagit pull ou algo semelhante por acidente, sem ser sudo'ed como DevAdmin. Então a maioria dos arquivos em.git são de propriedade de DevAdmin (que executou o clone inicial), mas sempre que fazemos isso, acabamos com dir em.git/objects que contêm arquivos pertencentes a um usuário específico. E estes são criados como unwritable de grupo. Eu também noteiORIG_HEAD com propriedade errada, por exemplo. Então, quando tentamos fazer algo como DevAdmin, temos problemas.

Existe alguma coisa que podemos fazer para corrigir esse problema? Agora, temos que reconhecer que isso aconteceu e, em seguida, obter um administrador do servidor parachown .git de volta ao DevAdmin. Ou faça o usuário deletar os meta-arquivos em questão, ou pelo menoschmod -los para grupo gravável. Tudo isso parece muito ruim.

Eu considerei algumas opções que não envolvem mudanças drásticas nos nossos processos de construção e manutenção:

Se removêssemos o acesso de gravação em grupo.git e restrito a DevAdmin, isso impediria que isso acontecesse novamente? Esta parece ser a opção mais simples.

Ou existe uma maneira de fazer tudo em.git gravável em grupo, mesmo quando é recém-criado? Isso parece pedir por problemas.

Há algo mais óbvio que estou perdendo? Eu percebo que a melhor coisa provavelmente seria mudar nosso processo para que os usuários pudessem trabalhar em seus próprios repositórios, mas em um ambiente de negócios, os repositórios podem ficar muito grandes (os frascos ainda não estão separados, muitos arquivos binários, etc.) ...), e não podemos ter repositórios multi-GB para a conta de todos. Além disso, nossos administradores de sistema teriam muito trabalho pela frente, alterando seus processos para permitir isso.

Quaisquer pensamentos são apreciados.