Melhores práticas para IntelliJ IDEA 9 control + Maven + Versão

Question

O projeto está usando Maven para que os arquivos POM são as principais fontes de informações do projeto. Existem algumas configurações úteis nos arquivos do projeto que seria bom para manter.

IDEA OTOH parece criar muitas mudanças redundantes na estrutura arquivo de projeto que polui a história SVN e às vezes cria conflitos.

Devo manter o diretório .idea e os arquivos .iml * sob controle de versão? na íntegra? em parte?

Update: Portanto, a melhor prática eu descobri trabalhando para mim e minha equipe está tão longe:

1. Verifique em todos os arquivos idéia, .iml * e .idea diretórios. Eles contêm informações valiosas e que é um desperdício de tempo para recriá-lo cada vez que você atualizar.
2. Criar ramo privado para cada desenvolvedor
3. cd em .idea diretório
4. svn switch para o seu homólogo private branch
5. Não verificar em arquivos de idéia sobre as submissões normais - eles poluem história. Vê-los em em commits especiais.

Desta forma, você manter o conteúdo do .idea diretório no controle de versão, mas mantê-lo fora do caminho de commits regulares. Qualquer desenvolvedor pode ter acesso a de qualquer outra pessoa diretórios idéia.

Update 2: Uma vez que esta questão foi escrito, eu mudei minha prática para não check-in todos os arquivos IntelliJ para o controle de versão, como recomendado por muitos respondedores. Esta é a minha prática atual tanto para Maven e Gradle. As ferramentas têm desenvolvido a tal ponto que as informações críticas sempre pode ser reproduzida a partir do .POM original ou arquivos .gradle. Quando a mudança de arquivos, as faixas IDE muda de forma confiável para que você não perder seus arquivos IDE que muitas vezes isso não há necessidade de verificar-los.

Update 3: 7 anos após esta pergunta parece ser ainda relevante. As mesmas boas práticas se aplicam a Gradle bem (provavelmente SBT, também.): Não verifica arquivos IDE em, recriá-las como necessário do POM básico, .gradle ou arquivos SBT

Answer 1

Resposta curta: não colocar esses arquivos no repositório de controle de origem, como você pode "gerar" eles (e isso é ainda mais verdadeiro se você não precisa deles, se eles são irritantes, se eles podem quebrar outros ambiente ).

Eu, pessoalmente usar os seguintes valores para svn:ignore:

target 
*~ 
*.log 
.classpath 
.project 
*.ipr 
*.iws 
*.iml 
.settings 

Answer 2

Uma das grandes coisas sobre Maven é que existe o apoio ferramenta para transformar uma POM em um projeto nativa em Eclipse, Idea e Netbeans. Se você tem um pom, você pode criar um projeto nativo muito rapidamente.

Por essa razão, eu não check-in .idea ou arquivos * .iml sob controle de origem mais do que eu iria verificar em topos RMI ou arquivos de classe.

Answer 3

Eu acho que você deve colocar .idea diretório no controle de versão. A maior parte da configuração contida deve haver versão rastreado, por exemplo, configurações do compilador.

O único arquivo que não pertence ao controle de versão é .idea / workspace.xml, porque só contém configuração específica para o seu ambiente local.

IntelliJ Idea realmente coloca workspace.xml na lista por padrão ignorar, por isso, se você usa Idea para o check-in, você deve estar tudo pronto sem mudar nada.

Answer 4

Eu vejo que a resposta padrão é "não check-in o arquivo de projeto, apenas o .pom". Mas coisas como os arquivos .ipr contêm grande quantidade de configurações úteis que não pode ser derivada a partir do arquivo .pom. E se os usuários companheiro IntelliJ quero compartilhar essas definições? Eu sei que .ipr arquivos são projetados para serem de versão (ver este rosca, por exemplo). Eu gostaria de ter uma resposta real, mas eu ainda não encontrei uma boa prática sobre esta matéria.

Answer 5

A minha opinião é que devemos manter todos os arquivos IDE específicos fora do controle de versão. A ideia é que devemos manter, tanto quanto possível a informação em IDE forma independente como arquivos pom Maven e assim por diante. Todas as configurações críticas do projeto pode ser mantido lá. E ter todas as principais configurações do projeto mantidos em arquivo pom não vejo qualquer razão séria para o check-in não só configuração do projeto IDEA, mas qualquer outra configuração IDE específica. Além disso, .idea configuração do projeto estilo pasta realmente polui registros changeset. E ainda quer manter as configurações do projeto IDEA no controle de versão, pelo menos podemos armazená-los em formato de arquivo .ipr única.

Answer 6

Estou atrasado para esta festa, mas esta questão exata foi me assola. E eu estava inspirado com o que eu acredito poderia funcionar, pelo menos com o nosso sistema de controle de origem.

Os arquivos IntelliJ não tem que ser armazenado "em conjunto" com o pom.xml autoritário e a fonte. A história de controle de versão não é "poluído" se as alterações relacionadas aos não-source são registrados para um lugar diferente na árvore de origem.

Então eu vou tentar mover os arquivos IntelliJ para um lugar paralelo no sistema de controle de versão, use um mapeamento de arquivo / diretório simples para reunificar arquivos de origem e de projeto na máquina do desenvolvedor, e a monitorizar as alterações no sistema de controle de versão que são puramente para arquivos que afetam a compilação.