Рекомендации для IntelliJ IDEA 9 + Maven + Контроль версий

Question

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

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

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

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

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