Todos na nossa equipe usam o IntelliJ IDEA, e achamos útil colocar seus arquivos de projeto (.ipr e .iml) no controle de origem, para que possamos compartilhar configurações, configurações e inspeções de compilação. Além disso, podemos usar essas configurações de inspeção em nosso servidor de integração contínua com o TeamCity. (Temos o arquivo .iws da área de trabalho por usuário no arquivo .gitignore e não no controle de origem.)
No entanto, esses arquivos mudam de pequenas maneiras quando você faz praticamente qualquer coisa no IDEA. Há um problema no banco de dados de problemas do IDEA para ele ( IDEA-64312 ), então talvez alguém possa considerar isso um bug no IDEA, mas é com o qual precisaremos conviver no futuro próximo.
Até recentemente, estávamos usando o Subversion, mas recentemente mudamos para o Git. Cada um de nós se acostumou a ter uma lista de alterações nos arquivos do projeto que ignoramos e não efetuamos check-in, a menos que houvesse alterações nos arquivos do projeto que desejássemos compartilhar com outras pessoas. Mas com o Git, o poder real parece ser (pelo que estamos explorando) a ramificação contínua que ele incentiva, e alternar entre ramificações é uma dor, pois os arquivos do projeto sempre foram modificados. Geralmente, ele pode mesclar as alterações de alguma forma e tenta lidar com as alterações no arquivo do projeto que estão sendo aplicadas agora na nova ramificação. No entanto, se o novo ramo alterou os arquivos do projeto (como o ramo está trabalhando em um novo módulo que ainda não está nos outros ramos), o git apenas gera um erro que não faz ' não faz sentido mesclar os arquivos quando o ramo tem alterações e você tem alterações localmente, e eu posso entender o ponto. Na linha de comando, pode-se usar "-f" no comando "git checkout" para forçá-lo a jogar fora as alterações locais e usar as ramificações, mas (1) o comando Git Checkout GUI no IDEA (10.5.1) parece não ter isso como uma opção que podemos encontrar; portanto, precisamos mudar para a linha de comando regularmente e (2) não temos certeza de que queremos ter o hábito de usá-lo. sinalizar e dizer ao Git para descartar nossas alterações locais.
Então, aqui estão alguns pensamentos que temos sobre as opções que temos que lidar com isso:
- Tire os arquivos do projeto completamente do controle de origem. Coloque-os no .gitignore e distribua-os a cada pessoa e TeamCity por outros meios, talvez colocando-os no controle de origem em outro lugar ou sob outros nomes. Nossa equipe é pequena o suficiente para considerar essa opção, mas isso não parece ótimo.
- Continue vivendo com ele, tentando garantir quais arquivos temos em quais ramificações em um determinado momento. Como parte disso, podemos incentivar cada desenvolvedor a ter mais de uma cópia de cada projeto em seu sistema, para que cada um possa fazer check-out em uma ramificação diferente, com conjuntos de arquivos de projeto possivelmente diferentes.
- Tente ter apenas o projeto (.ipr) no controle de origem, com os arquivos do módulo (.iml) que não estão no controle de origem e no arquivo .gitignore. A principal coisa que parece mudar por conta própria no .ipr regularmente é a ordem das configurações de compilação compartilhadas, mas talvez possamos compartilhar as informações separadamente sobre como configurá-las. Não tenho muita certeza de como a IDEA lida com esse tipo de coisa, tendo apenas alguns de seus arquivos, especialmente em um novo checkout.
Eu acho que espero que exista alguma solução óbvia (ou não óbvia) que perdemos, talvez lidando com a enorme capacidade de personalização que o Git e o IDEA parecem ter. Mas parece que não poderíamos ser a única equipe com esse problema. As perguntas que são semelhantes no Stack Overflow incluem 3495191 , 1000512 e 3873872 , mas não sei como são exatamente o mesmo problema, e talvez alguém possa apresentar os prós e contras das várias abordagens descritas, abordagens listadas nas respostas a essas perguntas ou abordagens recomendadas.