Студия Android - должен ли весь каталог .idea находиться в git игнорировать?

Ответ 1

Вы можете взглянуть на эту страницу:

IntelliJ doc о файлах конфигурации проекта

В "Справочном формате" интересна конкретная строка:

Каталог .idea содержит набор файлов конфигурации (.xml). Каждый файл содержит только часть данных конфигурации, относящихся к определенной функциональной области, которая отражается в имени файла, например, compiler.xml, encodings.xml, modules.xml.

Почти все файлы содержат информационное ядро ​​для самого проекта, такие как имена и местоположения его компонентов, параметры компилятора и т.д. Таким образом, эти файлы могут (и должны) храниться под контролем версий.

Тем не менее, я правильно HATE, чтобы сделать проект IDE-зависимым (в настоящее время я работаю над проектом, созданным с помощью NetBeans, и ему больно использовать его с Eclipse, который становится стандартом моей компании).

Итак, чтобы ответить на ваш вопрос:

• Если вы используете не использовать что-то вроде Maven или Gradle для управления зависимостями и сборки: сохранить каталог под контролем версий. Таким образом, правильная настройка проекта и зависимостей будет доступна для всех. В коллеге всем разработчикам придется устанавливать свою среду точно так же, как вы ее определяете в конфигурационных файлах.
• Если вы используете что-то вроде Maven или Gradle: правильно настройте эти инструменты и не держите каталог под контролем версий. Собственно, вся информация, содержащаяся внутри конфигурационных файлов, должна храниться в файлах Maven/ Gradle. Затем пусть ваши разработчики настроят свою среду IDE в зависимости от среды. Таким образом, использование Eclipse, IntelliJ, Linux, Windows... больше не будет проблемой.

Ответ 2

ОК, поэтому после ответов "Да" и "Нет" я добавляю ответ "Да и нет":)

Проблема заключается в том, что .idea используется как для конфигурации сборки проекта (объявления зависимостей), так и для параметров проекта (проверки и т.д.).

Вы определенно не хотите использовать свою среду IDE для своей конфигурации сборки, но вы можете поделиться этими настройками между командой. Поэтому вам нужно игнорировать только часть содержимого .idea (например, папку libraries и файл modules.xml), но держать другие в управлении версиями (например, copyright, dictionaries и inspectionProfiles папки и файлы в .idea, например dynamic.xml, codeStyleSettings.xml и т.д.).

Ответ 3

Концепция сохранения конфигурации проекта в VC действительна. Я сделал это с моей командой, потому что все наши разработчики использовали PHPStorm для наших проектов, и поэтому имеет смысл сохранить общую конфигурацию... в концепции. Мы хотели использовать те же словарные файлы, одинаковые стандартные правила кодирования и те же конфигурации плагинов.

Причина, по которой я квалифицирую это понятие "по понятию", заключается в том, что были проблемы с папкой .idea JetBrains, которая привела к тому, что мы не могли ее использовать. Вероятно, это были проблемы, которых можно было избежать или зафиксировать, но нам было непонятно, как это сделать правильно, и мы считаем, что это ошибка JetBrains, потому что у разработчиков нет времени или желания искать решения о том, как сделать наша среда IDE работает правильно.

Таким образом, были решены следующие проблемы:

• Связывание с папками проектов не работает правильно. Когда я настраиваю свои проекты, я связываю их в своем домашнем каталоге. Мы обнаружили, что проект был настроен так, чтобы использовать точную символическую ссылку, а не просто рассматривать ее как конкретную директорию. Это означает, что если другой разработчик держит свой проект в другом месте или просто не использует символические ссылки, весь каталог будет отсутствовать в навигаторе проекта, потому что он буквально ищет символическую ссылку. Что еще хуже, я никогда не смог найти это значение пути в конфигурации. Нам не удалось найти точный конфиг в файлах, составляющих нашу папку .idea.
• Файлы определения разделяются на пользователей по умолчанию. Это означает, что если я хочу добавить слово в словарь, он будет указан как определение для меня, jgreathouse, но у других пользователей будет свой собственный раздел определения. Флагированные слова будут отображаться как орфографическая ошибка для других пользователей. Это нежелательно. Причина, по которой я добавляю его в файл определения, связана с тем, что IDE ошибочна. Я хочу, чтобы эти определения были интуитивно разделены с другими пользователями.
• Коллеги перезаписывали конфигурации, потому что их IDE перезаписывает конфигурации с их конфигурацией, находящейся в настоящее время в памяти. Я имею в виду, что разработчик будет работать и объединить свой репозиторий из источника, который будет содержать изменение конфигурации проекта, вместо изменения настроек IDE или даже дать им выбор, он автоматически перезапишет конфигурацию .idea с помощью текущую конфигурацию их IDE в памяти. По-моему, это делает конфигурацию .idea непригодной для использования в качестве общей конфигурации. Чтобы обойти это, разработчику буквально пришлось бы закрыть этот экземпляр своей IDE, вытащить репо и повторно открыть их IDE. Нет смысла сохранять общую конфигурацию, если среда IDE мгновенно перезаписывает ее с конфигурацией, находящейся в настоящее время в памяти. Это похоже на отсутствие общей конфигурации вообще.

Я делал эти типы общих IDE-конфигураций в VC раньше с Visual Studio и Netbeans, и это всегда было хорошо; но с .idea он чувствует себя просто непригодным для использования, что разочаровывает. Я желаю, чтобы JetBrains поднялся над ним и улучшил работу пользователя.

Ответ 4

Я всегда добавляю этот каталог в gitignore. Все файлы, содержащиеся в нем, генерируются каждый раз при восстановлении проекта. Эти файлы не играют важной роли в проекте, но вы можете иметь ошибки или проблемы во время сборки в будущем.