Лучшие практики для IntelliJ IDEA 9 + Maven + Контроль версий

Question

В проекте используется Maven, поэтому файлы POM являются основными источниками информации о проекте. В файлах проекта есть несколько полезных настроек, которые было бы неплохо сохранить.

OTOH IDEA, похоже, создает слишком много избыточных изменений в файловой структуре проекта, что загрязняет историю SVN и иногда создает конфликты.

Должен ли я хранить каталог .idea и файлы * .iml под контролем версий? в полном объеме? частично?

Обновление: Итак, лучшая практика, которую я нашел, работает для меня и моей команды:

1. Проверьте все файлы IDEA, * .iml и .idea каталоги. Они содержат ценную информацию, и каждый раз, когда вы обновляете ее, воссоздайте ее.
2. Создание приватной ветки для каждого разработчика
3. перейдите в каталог .idea
4. svn переключите его на аналогичный филиал
5. Не проверяйте в файлах IDEA регулярные коммиты - они загрязняют историю. Отметьте их в специальных коммитах.

Таким образом, вы сохраняете содержимое каталога .idea в системе управления версиями, но не допускаете его для регулярных коммитов. Любой разработчик может иметь доступ к чьим-либо другим каталогам IDEA.

Обновление 2: С тех пор, как этот вопрос был написан, я изменил свою практику на , а не , проверяя любые файлы IntelliJ в системе контроля версий, как советовали многие респонденты. Это моя нынешняя практика для Maven и Gradle. Инструменты разработаны так, что критическая информация всегда может быть воспроизведена из исходных файлов .POM или .gradle. Когда файлы меняются, среда IDE надежно отслеживает изменения, поэтому вы не теряете свои файлы IDE так часто, что нет необходимости регистрировать их.

Обновление 3: Через 7 лет после того, как задать этот вопрос, оно все еще актуально. Те же самые лучшие практики применимы и к Gradle (возможно, и к SBT): не регистрируйте файлы IDE, заново создавайте их при необходимости из базовых файлов POM, .gradle или SBT.

Answer 1

Краткий ответ: не помещайте эти файлы в репозиторий управления исходным кодом, поскольку вы можете их «сгенерировать» (и это еще более верно, если они вам не нужны, если они раздражают, если они могут нарушить окружение) ).

Я лично использую следующие значения для svn:ignore:

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

Answer 2

Одна из замечательных особенностей Maven заключается в том, что существует инструментальная поддержка для превращения POM в собственный проект в Eclipse, Idea и Netbeans. Если у вас есть pom, вы можете довольно быстро создать собственный проект.

По этой причине я бы не стал регистрировать файлы .idea или * .iml под контролем исходного кода больше, чем проверял бы в заглушках RMI или файлах классов.

Answer 3

Я думаю, вы должны поместить каталог .idea в систему управления версиями. Большая часть содержащейся здесь конфигурации должна отслеживаться, например, конфиги компилятора.

Единственный файл, который не относится к управлению версиями, это .idea / workspace.xml, поскольку он содержит только конфигурацию, относящуюся к вашей локальной среде.

IntelliJ Idea фактически помещает workspace.xml в список игнорирования по умолчанию, поэтому, если вы используете Idea для регистрации, у вас все должно быть готово, ничего не меняя.

Answer 4

Я вижу, что стандартный ответ "не проверяйте в файле проекта, только .pom". Но такие вещи, как файлы .ipr, содержат много полезных настроек, которые НЕ могут быть получены из файла .pom. Что если другие пользователи IntelliJ захотят поделиться этими настройками? Я знаю, что файлы .ipr предназначены для управления версиями (см., Например, этот поток ). Хотелось бы, чтобы у меня был фактический ответ, но я еще не нашел хорошую практику по этому вопросу.

Answer 5

Мое мнение таково, что мы должны держать любые специфичные для IDE файлы вне контроля версий.Идея заключается в том, что мы должны хранить как можно больше информации в независимой от IDE форме, такой как файлы Maven pom и так далее.Все важные настройки проекта можно сохранить там.И, сохраняя все основные настройки проекта в pom-файле, я не вижу серьезных причин проверять не только конфигурацию проекта IDEA, но и любые другие специфические настройки IDE.Кроме того, конфигурация проекта в стиле папок .idea действительно загрязняет журналы изменений.И мы все еще хотим сохранить настройки проекта IDEA в управлении версиями, мы можем, по крайней мере, сохранить их в одном формате .ipr.

Answer 6

Я опаздываю на эту вечеринку, но именно эта проблема преследует меня. И я был просто вдохновлен тем, что, по моему мнению, могло бы работать, по крайней мере, с нашей системой контроля версий.

Файлы IntelliJ не должны храниться «вместе» с авторитетным pom.xml и источником. История управления версиями не «загрязнена», если эти не связанные с источником изменения записаны в другом месте в дереве исходников.

Поэтому я попытаюсь переместить файлы IntelliJ в параллельное место в системе управления версиями, использовать простое сопоставление файлов / каталогов, чтобы воссоединить исходные файлы и файлы проекта на компьютере разработчика, и отслеживать изменения в системе управления версиями, которые предназначены только для файлы, которые влияют на сборку.