Android studio - o diretório .idea inteiro deve estar no git ignorado?

Vi muitos exemplos de .gitignorearquivos para o AndroidStudio , alguns .ideadeles contidos e outros não.

Existe um bom motivo para não adicionar o diretório .idea inteiro ao .gitignore?

Se não deve ser completamente ignorado, existem arquivos específicos dentro de .idea (como .iml) que devem estar em .gitignore?

Você pode dar uma olhada nesta página:

Documento IntelliJ sobre arquivos de configuração do projeto

No "formato baseado em diretório", uma linha específica é interessante:

O diretório .idea contém um conjunto de arquivos de configuração (.xml). Cada ficheiro contém apenas uma parte de dados de configuração que pertencem a uma determinada área funcional que se reflecte no nome de um arquivo, por exemplo, compiler.xml, encodings.xml, modules.xml.

Quase todos os arquivos contêm informações essenciais para o projeto em si, como nomes e locais de seus módulos componentes, configurações do compilador, etc. Portanto, esses arquivos podem (e devem) ser mantidos sob controle de versão.

No entanto, eu odeio apropriadamente tornar o projeto dependente de IDE (atualmente estou trabalhando em um projeto feito com o NetBeans e dói usá-lo com o Eclipse, que se torna o padrão da minha empresa).

Então, para responder sua pergunta:

1. Se você não usar algo como Maven ou Gradle para gerenciar dependências e criar: mantenha o diretório sob controle de versão . Dessa forma, a configuração correta do projeto e as dependências estarão disponíveis para todos. Por outro lado, todos os desenvolvedores terão que definir seu ambiente exatamente da mesma maneira que você o define nos arquivos de configuração.
2. Se você usar algo como Maven ou Gradle: configure corretamente essas ferramentas e não mantenha o diretório sob controle de versão . Na verdade, todas as informações contidas nos arquivos de configuração devem ser armazenadas nos arquivos Maven / Gradle. Em seguida, permita que seus desenvolvedores configurem seu IDE, dependendo do ambiente. Dessa forma, usar Eclipse, IntelliJ, Linux, Windows ... não será mais um problema.

OK, então, depois de algumas respostas "Sim" e "Não", estou adicionando uma resposta "Sim e não" :)

O problema é que .ideaé usado para a configuração de criação do projeto (declaração de dependências) e as configurações do projeto (inspeções etc.).

Definitivamente, você não deseja usar o IDE para a configuração de compilação, mas pode compartilhar as configurações entre a equipe. É por isso que você precisa ignorar apenas uma parte do .ideaconteúdo (como a librariespasta eo modules.xmlarquivo), mas manter os outros no controle de versão (por exemplo, a copyright, dictionariese inspectionProfilespastas e arquivos sob .ideacomo dynamic.xml, codeStyleSettings.xml, etc.).

O conceito de manter a configuração do projeto no VC é válido. Fiz isso com minha equipe porque todos os nossos desenvolvedores usaram o PHPStorm para nossos projetos e, por isso, fazia sentido manter uma configuração comum ... em conceito. Queríamos usar os mesmos arquivos de dicionário, as mesmas regras padrão de codificação e as mesmas configurações de plug-in.

A razão pela qual qualifico isso como "in concept" é porque houve problemas com a pasta .idea do JetBrains que nos levaram a não poder usá-lo. Provavelmente esses eram problemas que poderiam ter sido evitados ou corrigidos, mas não estava claro para nós como fazê-lo corretamente, e achamos que isso é uma falha do JetBrains porque, como desenvolvedores, não temos tempo nem desejamos procurar soluções sobre como fazer isso. nosso IDE funciona corretamente.

Dito isto, os problemas foram os seguintes:

• A ligação simbólica de pastas do projeto não funciona corretamente. Quando configuro meus projetos, os vinculo ao diretório inicial. O que descobrimos foi que o projeto foi configurado para usar o link simbólico exato em vez de apenas tratá-lo como um diretório concreto. Isso significa que se outro desenvolvedor mantiver seu projeto em um local diferente ou simplesmente não usar links simbólicos, o diretório inteiro estará ausente no navegador do projeto, porque ele está literalmente procurando o link simbólico. O pior é que nunca consegui encontrar esse valor de caminho na configuração. Não foi possível encontrar a configuração exata nos arquivos que constituem nossa pasta .idea.
• Os arquivos de definição são particionados para os usuários por padrão. Isso significa que, se eu quiser adicionar uma palavra ao meu dicionário, ela será listada como uma definição para mim, jgreathouse, mas outros usuários terão sua própria seção de definição. As palavras sinalizadas ainda aparecerão como um erro de ortografia para outros usuários. Isso não é desejável. A razão pela qual eu o adicionei ao meu arquivo de definição é porque o IDE está errado. Quero que essas definições sejam compartilhadas intuitivamente com outros usuários.
• Os colegas continuavam sobrescrevendo as configurações, porque o IDE substituía as configurações com a configuração atualmente na Memória. O que eu quero dizer é que, um desenvolvedor estaria trabalhando e mesclaria seu repositório da origem, o que conteria uma alteração na configuração do projeto, em vez da alteração da configuração do IDE, ou até mesmo a possibilidade de escolha, substituiria automaticamente a configuração .idea por a configuração atual na memória de seu IDE. Na minha opinião, isso torna a configuração .idea inutilizável como uma configuração compartilhada. Para contornar isso, o desenvolvedor precisaria literalmente desligar a instância do IDE, puxar o repositório e reabrir o IDE. Não faz sentido manter uma configuração compartilhada se o IDE substitui-o instantaneamente com a configuração atualmente na memória. Isto'

Já fiz esses tipos de configurações IDE compartilhadas no VC antes com o Visual Studio e o Netbeans e sempre foi bom; mas com .idea parece simplesmente inutilizável, o que é decepcionante. Desejo que o JetBrains fique por dentro e faça com que seja uma melhor experiência do usuário.