Android studio - чи повинен весь каталог .idea не враховувати git?


137

Я бачив багато прикладів .gitignoreфайлів для AndroidStudio , деякі .ideaз них є, а деякі ні.

Чи є вагомі причини не додати весь .idea dir до .gitignore?

Якщо це не слід повністю ігнорувати, чи є специфічні файли всередині .idea (наприклад, .iml), які повинні бути в .gitignore?


Я ігнорую, .ideaза винятком деяких файлів під .idea/runConfigurations/.
Даніель

Відповіді:


104

Ви можете подивитися на цій сторінці:

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

У "Форматі на основі каталогів" цікавий конкретний рядок:

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

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

Однак я ненавиджу НЕОБРАЗУВАННЯ, щоб зробити проект IDE-залежним (я зараз працюю над проектом, зробленим з NetBeans, і боляче використовувати його з Eclipse, який стає стандартом моєї компанії).

Отже, щоб відповісти на ваше запитання:

  1. Якщо ви не використовуєте щось подібне Maven або Gradle для управління залежностями та побудови: тримайте каталог під контролем версій . Таким чином, правильна конфігурація проекту та залежності будуть доступні для всіх. У відповідності з усіма розробниками доведеться встановлювати своє оточення точно так само, як ви визначаєте його у конфігураційних файлах.
  2. Якщо ви використовуєте щось на зразок Maven або Gradle: правильно налаштуйте ці інструменти і не тримайте каталог під контролем версій . Насправді вся інформація, що міститься у файлах config, повинна зберігатися у файлах Maven / Gradle. Тоді дозвольте своїм розробникам налаштувати свій IDE залежно від середовища. Таким чином, використання Eclipse, IntelliJ, Linux, Windows ... вже не буде проблемою.

9
Зверніть увагу на наступний параграф: "Виняток - файл workpace.xml. Він зберігає ваші особисті налаштування ... Тому навряд чи ви хочете поділитися цим файлом зі своїми колегами."
Дальбергія

40

Гаразд, після деяких відповідей "Так" і "Ні" я додаю відповідь "Так і ні" :)

Проблема полягає в тому, що .ideaвикористовується як для конфігурації збірки проектів (декларація залежностей), так і налаштувань проекту (перевірки тощо).

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


Як конкретно адресуватимуться файли iml?
дорс

1
файли iml обов'язково слід ігнорувати.
JBaruch

1
Я все ще думаю, що конфігурації не повинні зберігатися у файлах, що залежать від IDE, і тому Maven / Gradle так краще робити це.
мітроп

@mithrop річ у тому, що ви не можете оголосити такий тип конфігурації у файлі Maven / Gradle. Це власний формат ідеї, і він не має портативних альтернатив в Maven / Gradle.
JBaruch

О так, ти маєш рацію. У будь-якому випадку, якщо ви не зможете помістити його у файли maven / gradle, у вас виникне проблема при наступному імпорті проекту в інший IDE (з якою я ненавиджу працювати). Але я повністю згоден з вами (якщо прочитаєте мою відповідь, ви побачите, що я насправді є): ви включаєте файли чи не залежно від ваших потреб :)
mithrop

7

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

Причина, чому я кваліфікую це "в концепції", полягає в тому, що з папкою .idea JetBrains'idea виникли проблеми, які призвели до того, що ми не могли ним користуватися. Це, ймовірно, були проблеми, яких можна було б уникнути або виправити, але нам було незрозуміло, як це зробити правильно, і ми вважаємо, що це вина JetBrains, тому що як розробники у нас немає ні часу, ні бажання шукати рішення, як зробити наші IDE працюють правильно.

Однак, питання були такі:

  • Символьні папки проектів не працюють належним чином. Коли я створюю свої проекти, я посилаю їх на свій домашній каталог. Ми виявили, що проект був створений з метою використання точного символьного посилання, а не просто обробляти його як конкретний каталог. Це означає, що якщо інший розробник зберігає свій проект в іншому місці або просто не використовує посилання, весь каталог буде відсутній у навігаторі проекту, оскільки він буквально шукає симпосилання. Найгірше те, що я ніколи не зміг знайти це значення в конфігурації. Не вдалося знайти точну конфігурацію у файлах, що складають нашу папку .idea.
  • Файли визначення розділяються на користувачів за замовчуванням. Це означає, що якщо я хочу додати слово до свого словника, воно буде вказане як визначення для мене, jgreathouse, але для інших користувачів буде свій розділ визначення. Позначені слова все одно відображатимуться як орфографічна помилка для інших користувачів. Це не бажано. Причина, яку я додаю до файлу мого визначення, полягає в тому, що IDE неправильний. Я хочу, щоб ці визначення інтуїтивно ділилися з іншими користувачами.
  • Колеги продовжували перезаписувати конфігурації, оскільки їх IDE буде замінювати конфігурації з їх конфігурацією, що знаходиться в Пам'яті. Що я маю на увазі, це те, що розробник працював і об'єднав би їх сховище з початкового походження, яке містило б зміну конфігурації проекту, замість того, щоб змінити їх конфігурації IDE або навіть дати їм вибір, він автоматично замінить конфігурацію .idea поточна конфігурація в пам'яті їх IDE. На мій погляд, це робить конфігурацію .idea непридатною як спільна конфігурація. Щоб вирішити це, розробнику буквально довелося б закрити цей екземпляр своєї IDE, витягнути репо і повторно відкрити IDE. Немає сенсу зберігати спільну конфігурацію, якщо IDE миттєво перезаписує її з конфігурацією, яка наразі знаходиться в пам'яті. Це '

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


> замість їх IDE, що змінюють конфігурації або навіть дають їм вибір, вони автоматично переписують конфігурацію .idea з поточною конфігурацією в пам'яті їх IDE. Ого, це справді прикро. Добре знати!
Грег Ціна
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.