Какие настройки IDE подходят для регистрации?

IDE создают некоторые файлы конфигурации для каждого проекта/рабочей области.

В IntelliJ есть папка .idea/ и файлы .iml.

Eclipse имеет свои файлы .classpath и .project. Раньше для интеграции Eclipse Maven требовалась конфигурация жизненного цикла m2e в pom.xml (не уверен, что это все еще так)

Я видел проекты в прошлом,

  • где артефакты Eclipse (.classpath, .project) хранились в SVN, и это обычно нарушало рабочее пространство каждого разработчика.
  • где даже конфигурация m2e-lifecycle была запрещена
  • где разрешена конфигурация m2e-жизненного цикла, но не .classpath или .project
  • где регистрируются подмножества папки .idea/, поскольку она содержит конфигурации запуска
  • обычно файлы .gitignore содержат файлы, специфичные для IDE.

Я предпочитаю не включать в исходный код все артефакты IDE, включая конфигурацию, за исключением списка артефактов IDE в файле .gitignore.

Но интересно, какие веские причины за/против заселения

  • Артефакты, созданные IDE (например, .classpath или *.iml)
  • Специфические конфигурации IDE (например, в maven poms)

в СКМ?

Или это общий запрет?


person Gerald Mücke    schedule 28.08.2018    source источник
comment
Я бы сказал, что это вообще недопустимо.   -  person Jens    schedule 28.08.2018
comment
ерунда, либо помогает совершать их, либо вредит. Это зависит.   -  person Meo    schedule 28.08.2018
comment
...обычно это ломало рабочее пространство каждого разработчика... противоречит моему опыту. В Eclipse файл .project содержит описание проекта, т.е. грамм. Природа Maven и в конфигурации проекта подкаталога .settings, например. грамм. предупреждение компилятора, профиль форматирования и т. д. Таким образом, вопрос в том, должны ли все следовать одним и тем же или своим собственным правилам для e. грамм. форматирование исходного кода.   -  person howlger    schedule 28.08.2018


Ответы (2)


Если вы используете Maven/Gradle/SBT, нет смысла коммитить файлы *.iml, поскольку они повторно генерируются из Maven/Gradle/SBT. Артефакты также автоматически генерируются из этих систем сборки, поэтому, если вы не создаете свои собственные артефакты IDE, вам не следует фиксировать конфигурацию артефактов.

См. также Как управлять проектами в системах контроля версий.

См. также аналогичный вопрос: Какие файлы в папке .idea должны отслеживаться Git?.

person Andrey    schedule 28.08.2018

Почему вы должны их опустить:

  • вы хотите иметь возможность создавать свои проекты с помощью инструмента сборки по вашему выбору (например, maven, gradle и т. д.) на любом сервере сборки, который вам нравится (который фактически их поддерживает)
  • вы хотите иметь возможность загружать проект с любой IDE (никаких причуд в настройках проекта IDE, чтобы заставить его работать как-то)

Почему вы должны совершить их:

  • все используют одну и ту же IDE в проекте (и, возможно, также: все имеют одинаковую структуру каталогов; примечание: я бы никогда никого не заставлял использовать конкретную IDE или фиксированную структуру каталогов, поэтому мне на самом деле не нравится этот конкретный момент ;-) )
  • ИЛИ (возможно, более правильно): вы единственный, кто использует проект, и хотите (пере)настроить все довольно быстро/гладко

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

Что касается конкретных настроек IDE в файлах сборки, таких как m2e-lifecycle: ... это действительно зависит. Я бы предпочел использовать конфигурации плагинов, которые действительно работают без дополнительных m2e-lifecycle-boilerplate. В конце концов, это не делает файл сборки более читабельным ;-)

Подводя итог (мое мнение ;-)) Я фиксирую только определенные файлы IDE, когда работаю над проектом в одиночку, и в любом другом случае я опускал их, как это делали товарищи по команде. Если они были зафиксированы в проекте, я обычно не использовал его повторно (или только форматтер через плагины), поскольку я в основном был в другой IDE.

person Roland    schedule 28.08.2018