Каждый в нашей команде использует IntelliJ IDEA, и мы считаем полезным поместить его файлы проекта (.ipr и .iml) в систему контроля версий, чтобы мы могли обмениваться конфигурациями, настройками и проверками сборки. Кроме того, мы можем использовать эти параметры проверки на нашем сервере непрерывной интеграции с TeamCity. (У нас есть файл .iws рабочей области для пользователя в файле .gitignore, а не в системе контроля версий.)
Однако эти файлы меняются незначительно, когда вы делаете что-либо в IDEA. Для этого существует проблема в базе данных проблем IDEA ( IDEA-64312 ), поэтому, возможно, можно считать это ошибкой в IDEA, но с ней нам придется смириться в обозримом будущем.
До недавнего времени мы использовали Subversion, но недавно перешли на Git. Каждый из нас привык к тому, что у нас есть список изменений файлов проекта, который мы игнорировали и не регистрировали, если не было изменений файла проекта, которыми мы хотели поделиться с другими. Но с Git реальная сила, кажется, (из того, что мы исследуем) - это непрерывное ветвление, которое оно поощряет, и переключение между ветвями - это проблема с файлами проекта, которые всегда модифицировались. Часто он может просто каким-то образом объединить изменения и попытаться справиться с изменениями файла проекта, которые теперь применяются к новой ветви. Однако, если новая ветвь изменила файлы проекта (например, ветвь работает над новым модулем, которого пока нет в других ветвях), git просто выдаст ошибку, которую он не ' Не имеет никакого смысла объединять файлы, когда обе ветви имеют изменения, и у вас есть изменения локально, и я могу лучше понять его смысл. Из командной строки можно использовать «-f» в команде «git checkout», чтобы заставить ее выбрасывать локальные изменения и использовать вместо этого ветки, но (1) команду Git Checkout GUI в IDEA (10.5.1) Похоже, что это не вариант, который мы можем найти, поэтому нам нужно было бы регулярно переключаться на командную строку, и (2) мы не уверены, что хотим использовать эту привычку флаг и говорит Git выбросить наши локальные изменения.
Итак, вот некоторые мысли, которые у нас есть по поводу вариантов, с которыми мы должны иметь дело:
- Вывести файлы проекта из-под контроля исходного кода полностью. Поместите их в .gitignore и раздайте их каждому человеку и TeamCity с помощью других средств, возможно, поместив их в систему контроля версий где-либо еще или под другими именами. Наша команда достаточно мала, и этот вариант достаточно выполним, чтобы рассмотреть, но он не кажется отличным.
- Продолжайте жить с этим, стараясь быть уверенными в том, какие файлы и ветки у нас есть в данный момент времени. В рамках этого мы могли бы рекомендовать каждому разработчику иметь более одной копии каждого проекта в своей системе, чтобы они могли получить каждый извлеченный файл в другой ветви с возможно разными наборами файлов проекта.
- Попробуйте использовать только проект (.ipr) в системе контроля версий, а файлы модуля (.iml) не в системе управления версиями, а в файле .gitignore. Кажется, что главное, что само по себе регулярно переключается в .ipr, это порядок общих конфигураций сборки, но, возможно, мы можем просто поделиться информацией отдельно о том, как их настроить. Я не совсем уверен, как IDEA справляется с такого рода вещами, имея только некоторые из своих файлов, особенно на новой кассе.
Думаю, я надеюсь, что есть какое-то очевидное (или неочевидное) решение, которое мы упустили, возможно, имеющее дело с огромной настраиваемостью, которую, похоже, имеют Git и IDEA. Но похоже, что мы не могли быть единственной командой, имеющей эту проблему. Вопросы, которые похожи на переполнение стека, включают 3495191 , 1000512 и 3873872 , но я не знаю, так как они абсолютно одинаковые, и, возможно, кто-то может придумать плюсы и минусы для различных подходов, которые я изложены, подходы, перечисленные в ответах на эти вопросы, или подходы, которые они рекомендуют.
источник
Ответы:
Вы можете использовать структуру проекта IDEA на основе каталогов , где настройки хранятся в каталоге .idea, а не в файле .ipr. Это дает более детальный контроль над тем, что хранится в контроле версий. Файлы .iml по-прежнему будут присутствовать, поэтому они не решают случайные изменения в них (возможно, не допускают их контроля над исходным кодом?), Но совместное использование таких вещей, как стиль кода и профили проверки, является простым, поскольку каждый из них будет в своем собственном файле в каталоге .idea.
источник
Из официального документа DOC: http://devnet.jetbrains.com/docs/DOC-1186.
Я положил это в мой .gitignore:
источник
Официальный ответ доступен . Предполагая, что вы используете современный (и теперь используемый по умолчанию)
.ideaформат проекта папки:.idea/workspace.xml(который зависит от пользователя).idea/tasks.xml(который зависит от пользователя)Этот пример файла .gitignore может быть полезной ссылкой, хотя вы все равно должны прочитать вышеуказанную ссылку, чтобы понять, почему появляются эти записи, и решить, нужны ли они вам.
Лично я также игнорирую
.idea/find.xmlфайл, так как он, кажется, меняется каждый раз, когда вы выполняете операцию поиска.источник
Я взял workspace.xml из системы контроля версий (+ добавлен в .gitignore).
источник
Наша команда не регистрирует файлы IntelliJ для конкретных путей. Мы предполагаем, что люди знают, как использовать IDE и настроить проект. Файлы IntelliJ попадают в список игнорируемых изменений.
ОБНОВИТЬ:
Теперь ответ проще, когда я использую Maven и его структуру каталогов по умолчанию.
IntelliJ следует попросить , чтобы игнорировать все файлы
/.svn,/.ideaи/targetпапки. Все, что относится к индивидуальной информации о пути, хранится в/.idea.Все остальное - это честная игра, которую можно посвятить Subversion или Git.
источник
Просто чтобы поделиться другим подходом, использованным моей командой: просто переместите любые связанные с IDE файлы в другое место, где IntelliJ не распознает, и создайте сценарий, чтобы скопировать их в желаемое «активное» место, которое игнорируется GIT.
Преимущество этого подхода заключается в том, что вы сохранили возможность обмениваться настройками IDE с помощью контроля версий. Единственный недостаток - вы должны решить, когда запускать сценарий (возможно, один раз для каждого клона рабочей области или когда требуются изменения), и вы можете автоматизировать это, включив сценарий в свой процесс сборки или ловушку после слияния.
Этот подход основан на том, что IntelliJ выполняет поиск файлов настроек только в определенных местах, поэтому он применяется и к файлам конфигурации платформы. Фактически мы игнорировали файл .properties Grails таким образом, чтобы разработчики не могли случайно зафиксировать свои локальные изменения конфигурации.
источник