Як боротися з файлами проектів IntelliJ IDEA під контролем джерела Git, що постійно змінюється?


151

Усі в нашій команді використовують IntelliJ IDEA, і нам здається корисним розмістити файли проектів (.ipr та .iml) у керуванні джерелами, щоб ми могли ділитися конфігураціями, налаштуваннями та інспекціями побудови. Крім того, ми можемо використовувати ці параметри перевірки на нашому сервері безперервної інтеграції з TeamCity. (У нас є .iws файл робочого простору для користувача у файлі .gitignore, а не в контролі джерела.)

Однак ці файли змінюються мало, коли ви робите майже будь-що в IDEA. Існує проблема в базі даних випусків IDEA для нього ( IDEA-64312 ), тому, можливо, можна вважати цю помилку в IDEA, але це те, з ким нам потрібно жити в осяжному майбутньому.

До недавнього часу ми використовували Subversion, але нещодавно ми перейшли на Git. Кожен із нас просто звик до списку змін файлів проектів, які ми ігнорували та не перевіряли, якщо не було змін у файлі проекту, якими ми хотіли поділитися з іншими. Але в Git реальна потужність, здається, є (з того, що ми досліджуємо) безперервним розгалуженням, яке він заохочує, і перемиканням між гілками - це біль, коли файли проекту завжди змінювалися. Часто він може просто якось об'єднатись із змінами та намагається боротися зі змінами файлів проекту, які зараз застосовуються до нової гілки. Однак якщо нова гілка змінила файли проекту (наприклад, гілка працює над новим модулем, який ще не знаходиться в інших гілках), git просто видає помилку, яку вона не робить ' t не має сенсу об’єднуватись у файлах, коли обидві гілки мають зміни, і ви змінюєте локально, і я можу скоріше зрозуміти її суть. З командного рядка можна використовувати команду "-f" у команді "git checkout", щоб змусити її викидати локальні зміни та використовувати замість гілки, але (1) команда Git Checkout GUI в IDEA (10.5.1) Схоже, це не є варіантом, який ми можемо знайти, тому нам потрібно буде регулярно переходити до командного рядка, і (2) Ми не впевнені, що хочемо використовувати це прапор і говорить Git викинути наші місцеві зміни.

Отже, ось кілька думок, які ми маємо щодо варіантів, з якими ми маємо боротися з цим:

  1. Файли проекту повністю вийміть з контролю джерела. Помістіть їх у .gitignore та поширіть їх кожній особі та TeamCity за допомогою інших засобів, можливо, поставивши їх у джерело управління десь в іншому місці чи під іншими іменами. Наша команда досить мала, цей варіант є достатньо можливим для розгляду, але він не здається чудовим.
  2. Продовжуйте жити з цим, намагаючись бути впевненим, керувати, які файли у нас є, на яких гілках у даний момент часу. В рамках цього, ми можемо закликати кожного розробника мати більше однієї копії кожного проекту у своїй системі, щоб кожен міг перевірити їх в іншому відділенні, можливо, з різними наборами файлів проекту.
  3. Спробуйте мати лише проект (.ipr) у керуванні джерелами, а файли модуля (.iml) не у контролі джерела, а у файлі .gitignore. Головне, що, здається, регулярно перемикається самостійно в .ipr - це порядок конфігурацій спільної збірки, але, можливо, ми можемо просто поділитися інформацією окремо про те, як їх налаштувати. Я не зовсім впевнений, як IDEA має справу з подібними речами, маючи лише деякі свої файли, особливо, коли це стосується нового замовлення.

Напевно, я сподіваюся, що ми пропустили якесь очевидне (або неочевидне) рішення, можливо, маючи справу з величезною налаштованістю, яку, схоже, мають і Git, і IDEA. Але, схоже, ми не могли бути єдиною командою, яка має цю проблему. Питання, схожі на Stack Overflow, включають 3495191 , 1000512 та 3873872 , але я не знаю, як вони точно однакові, і, можливо, хтось може придумати свої плюси та мінуси для різних підходів, які я окреслені підходи, перелічені у відповідях на ці запитання, або підходи, які вони рекомендують.



Відповідь нижче надала gitignore.io як гарну базу. Я вважаю це корисним, навіть якщо через три роки після факту: gitignore.io/api/java,android,eclipse,intellij
WernerCD

Зауважте, що проблему IDEA, яку я згадував youtrack.jetbrains.com/issue/IDEA-64312 , позначено як фіксовану в IntelliJ IDEA 14, тому ті, хто використовує останню версію та хочуть зберегти файли в контролі джерела, можуть мати її кращий час зараз ніж тоді, коли я опублікував це питання.

Відповіді:


48

Ви можете використовувати структуру проектів на основі каталогів IDEA , де налаштування зберігаються у каталозі .idea замість .ipr-файлу. Це дає більш дрібний контроль над тим, що зберігається у контролі версій. Файли .iml все ще будуть навколо, тому вони не вирішують випадкових змін у них (можливо, не дозволяють їм контролювати джерело?), Але обмін такими речами, як стиль коду та профілі перевірки, є простим, оскільки кожен з них буде у власному файлі під каталогом .idea.


Перехід до структури на основі каталогу, безумовно, дуже допоміг. Ми взяли файли .iml з контролю джерела, що робить IDEA трохи заплутаним при першому виїзді, але це здається найкращим компромісом на даний момент. Нам також довелося працювати з інспекціями TeamCity з файлу Maven та експортованого профілю інспекцій, але ми також працювали над цим. Дякую!

Посилання розірвано. Не впевнений, яким був оригінальний вміст, але ось посилання на відповідний документ про структуру проекту IDEA. І ось ще одне посилання, що стосується цього конкретного питання.
Бен.12,

31

З офіційного DOC: http://devnet.jetbrains.com/docs/DOC-1186

Залежно від формату проекту IntelliJ IDEA (на основі .ipr-файлу або на базі каталогу .idea), ви повинні поставити такі файли проектів IntelliJ IDEA під контроль версій:

формат на основі файлу .ipr

Поділіться файлом .ipr проекту та всіма файлами модуля .iml, не використовуйте.

Формат на основі каталогу .idea

Поділіться всіма файлами в каталозі .idea в корені проекту, за винятком файлів workpace.xml та task.xml, у яких зберігаються конкретні налаштування користувача, а також спільні файли всіх модулів .iml.

Я поміщую це у своєму .gitignore:

#Project
workspace.xml
tasks.xml

8
Так, і як я вже говорив у запитанні, ми поділили .ipr і .iml, а не .iws. Проблема полягає в тому, що в youtrack.jetbrains.com/issue/IDEA-64312 проблема в тому, що файли .iml постійно змінюються, що призводить до частих конфліктів. Збереження файлів .iml поза контролем джерела, здається, працює для нас краще, оскільки IDEA відновлює їх з Maven POM, і тоді вони можуть просто продовжувати змінюватися локально без конфліктів з іншими розробниками. Дякую!

При такому підході у нас виникають проблеми з деякими назвами ресурсів, наприклад: Android JDK-версії. Деякий член нашої команди має різні назви або різні версії налаштованого SDK. Надсилаючи файли проектів на репо, вам потрібно вирівняти такі речі з вашою командою. До вчорашнього дня ми не використовували для надсилання файлів proj на репо, але це стало важко, оскільки наш проект став великим і важким для налаштування.
Феліпе

Об’єднання використовуваних SDK та відносних шляхів - це просте та ефективне рішення
Kumait

1
Так. Тепер усі наші модулі вказують на "Проект SDK", і ми узгоджуємось з командою, щоб використовувати той самий SDK. Принаймні, це лише одне місце для зміни. Але IntelliJ міг би зробити це краще.
Феліпе

23

Офіційна відповідь доступний . Припустимо, що ви використовуєте сучасний .ideaформат проекту папок:

  • Додати все ...
  • За винятком .idea/workspace.xml (що залежить від користувача)
  • За винятком .idea/tasks.xml (що залежить від користувача)
  • За винятком деяких інших файлів, які можуть містити паролі / ключі / тощо (детальніше див. Вище посилання)

Це зразок .gitignore файлу може бути корисним посиланням, хоча все-таки слід прочитати вищезазначене посилання, щоб зрозуміти, чому ці записи з’являються, і вирішити, чи потрібні вони.

Особисто я також ігнорую .idea/find.xmlфайл, оскільки це, здається, змінюється щоразу, коли ви виконуєте пошукову операцію.


1
На основі посилання "зразок файлу gitignore" я би зробив це на крок далі і радий, що ви це надали. перейдіть за базовою адресою, і ви можете комбінувати різні типи, щоб отримати "повний" gitignore. Для мого проекту Android, який, очевидно, використовує Java, Android, Eclipse, IntelliJ: gitignore.io/api/java,android,eclipse,intellij
WernerCD

16

Я взяв workspace.xml з контролю джерела (+ додано до .gitignore).


10

Наша команда не перевіряє файли IntelliJ, орієнтовані на контур. Ми припускаємо, що люди знають, як використовувати IDE та створити проект. Файли IntelliJ переходять у список "ігнорованих" змін.

ОНОВЛЕННЯ:

Відповідь простіше тепер, коли я використовую Maven та його структуру каталогів за замовчуванням.

IntelliJ слід попросити , щоб ігнорувати всі файли /.svn, /.ideaі /targetпапки. Все, що стосується інформації про шлях людини, зберігається /.idea.

Все інше - це чесна гра, яка повинна бути прихильна до Subversion або Git.


14
Налаштування проекту не є великою справою, оскільки це трапляється не часто, але дуже зручно ділитися конфігураціями побудови та профілями інспекцій без необхідності надсилати скріншоти по електронній пошті чи щось подібне.

1
Перевірте речі, які не залежать від шляху людини.
дуффімо

2

Просто, щоб поділитися іншим підходом, який використовувала моя команда: Просто перемістіть усі файли, пов’язані з IDE, в інше місце, де IntelliJ не розпізнає, і створіть сценарій, щоб скопіювати їх у потрібне "активне" місце, яке GIT ігнорує.

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

Цей підхід покладається на те, що IntelliJ здійснює пошук лише у певних місцях для своїх файлів налаштувань, тому він застосовується і до файлів конфігурації фреймворку. Насправді ми проігнорували файл Grails .properties таким же чином, тому розробники не випадково зареєструються в їхніх локальних змінах конфігурації.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.