Como você está aplicando o comportamento do git, inclusive localmente (principalmente no Windows)?

Estou pensando em mudar essa loja .NET do svn para o git e identifiquei alguns problemas auxiliares que gostaria de ter uma solução antes de ativar o switch.

O que eu estou perguntando em particular nesta pergunta é a imposição de final de linha. Por padrão, o git for windows instala com o 'checkout crlf, commit lf', que não funcionará para um monte de fontes que (até onde eu saiba) sejam exclusivamente compostas de terminações crlf.

Eu não sei se confiava cegamente em qualquer desenvolvedor para configurar isso corretamente, mesmo com instruções dadas, por isso estou considerando um (ou ambos) dos itens a seguir, mas fiquei curioso para saber se alguém aqui havia seguido outra rota.

• Um gancho de pré-confirmação que verifica qualquer final de linha lf (ou talvez todos os finais de linha lf) e rejeita nesse caso.
• Um script de instalação distribuído para desenvolvedores que preenche a configuração global com o 'como está, como está'.

PS Enquanto escrevia isso, ocorreu-me que a conversão inicial de svn para git poderia se comprometer da maneira padrão e contanto que as pessoas continuassem com o padrão, o que também seria bastante uniforme. Tendo sido um desenvolvedor usando o git em uma loja do .NET que instalou o git com o não-padrão 'como está, como está', criei meus próprios problemas lá também (todos rolaram o padrão antes da minha chegada) . Então, eu ainda estou inclinado a algum tipo de mecanismo de imposição.

Para responder à pergunta de como impor algo localmente, você não pode, sem fazer muito trabalho pesado ao gerenciar e impor o estado de todas as estações de trabalho de desenvolvedores, e geralmente sou da opinião de que os desenvolvedores provavelmente devem ser administradores locais em seu desenvolvimento máquina porque, se não estiverem, gastarão seu tempo imaginando como obter esses privilégios de qualquer maneira.

E isso é provavelmente porque você não precisa se preocupar com o estado da configuração local ao usar o controle de versão distribuído. Você só deve se preocupar com o estado da sua configuração. Supondo que você esteja usando o git como um sistema centralizado de controle de versão, porque é o que basicamente todo mundo faz de qualquer maneira, porque é o mais fácil, então vamos assumir que a configuração "your" é a cópia do código salvo no servidor central.

Se for esse o caso, você não deve aceitar mesclagens que, como você mencionou, quebram as terminações de linha crlf / lf. Portanto, você aplica isso quando algum outro cliente tenta fazer alterações com a lógica do servidor que rejeita a solicitação de poluir seu repositório com suas escolhas estilísticas potencialmente prejudiciais.

Exigimos um processo de revisão usando solicitações Pull no github em nossos principais ramos de desenvolvimento ou mestre. Durante esse processo de revisão, marcaremos as solicitações pull como exigindo alterações se muitos arquivos tiverem diferenças de espaço em branco ou final de linha, e insistiremos para que sigam a formatação do ramo dev ou master para o qual estão solicitando pull.

Também existem algumas ferramentas legais, dependendo de quais idiomas você usa e quais ferramentas de IC você usa, quais podem, durante o processo de compilação ou a etapa de solicitação pull, formatar automaticamente o código com base nas regras que você configurou. Isso também ajuda a manter o código com aparência consistente e a minimizar os problemas de formatação ao confirmar o código.

Você pode usar a configuração por repositório para substituir a configuração do usuário por repositório. Quando feito no repositório considerado a fonte central, ele deve se propagar com clones e puxar para outros repositórios, incluindo locais, substituindo, assim, centralmente a configuração local.

Você pode aplicar isso ainda mais através de ganchos no seu repositório central para verificar se as terminações dos arquivos são o que deveriam ser e rejeitar a mesclagem / envio, caso não seja um kosher. No entanto, esses ganchos não serão clonados com o repositório, pelo menos não diretamente, mas isso não é necessário, pois as regras realmente precisam ser aplicadas no repositório central.

Usando modelos no seu git init, você pode garantir que seus repositórios sejam criados iguais a todos os arquivos gitignore, gitattributes etc, exatamente como você deseja.

Por último, não diretamente relacionado à sua pergunta, encontrei o maior ponto de atrito ao levar o svn saavy team para um fluxo de trabalho baseado em git, o que os acostumaria com o repo extra no meio. Eu descobri que essa folha de dicas visuais ajudou a explicar um pouco qual comando tinha qual efeito para qual parte.

Espero que isso tenha ajudado um pouco.