Как работать с файлами проекта IntelliJ IDEA при Git постоянном изменении источника?

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

Однако эти файлы немного меняются, когда вы делаете что-то в IDEA. В нем есть проблема в базе данных проблем IDEA (IDEA-64312), поэтому, возможно, это может показаться ошибкой в ​​IDEA, но это один из нас в обозримом будущем нужно жить.

До недавнего времени мы использовали Subversion, но недавно мы переключились на Git. Мы только что привыкли к тому, что у меня есть список изменений файлов проектов, которые мы проигнорировали и не выполнили проверку, если не были изменения файла проекта, которые мы хотели бы поделиться с другими. Но с Git реальная власть кажется (из того, что мы изучаем) непрерывным ветвлением, которое она поощряет, а переключение между ветвями - это боль, когда файлы проекта всегда были изменены. Часто он может как-то слить изменения, и пытается применить изменения файла проекта, которые теперь применяются к новой ветке. Однако, если новая ветвь изменила файлы проекта (например, ветка работает над новым модулем, который еще не находится в других ветвях), git просто выдает ошибку, которая не имеет смысла сливаться в файлы, когда и ветка имеет изменения, и у вас есть изменения локально, и я могу лучше понять ее точку. Из командной строки можно использовать "-f" в команде "git checkout", чтобы заставить ее выбросить локальные изменения и использовать ветку вместо этого, но (1) команда GUI GUI git в IDEA ( 10.5.1), похоже, не может быть в качестве опции, которую мы можем найти, поэтому нам нужно будет переключаться на командную строку на регулярной основе и (2) Мы не уверены, что хотим быть в привычку использовать этот флаг и сообщать git, чтобы выбросить наши локальные изменения.

Итак, вот некоторые мысли, которые мы имеем о вариантах, с которыми нам приходится иметь дело:

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

Я предполагаю, что я надеюсь найти какое-то очевидное (или неочевидное) решение, которое мы пропустили, возможно, имея дело с огромной настраиваемостью, которая, как кажется, имеет git и IDEA. Но похоже, что мы не могли быть единственной командой, имеющей эту проблему. Вопросы, похожие на StackOverflow, включают 3495191, 1000512 и 3873872, но я не знаю, поскольку это точно такая же проблема, и, возможно, кто-то может придумать все плюсы и минусы для различных подходов, которые я изложил, подходы, перечисленные в ответы на эти вопросы или подходы, которые они рекомендуют.

Спасибо.

Ответ 1

Вы можете использовать IDEA структуру проекта на основе каталога, где настройки хранятся в каталоге .idea вместо файла .ipr. Это дает более мелкозернистый контроль над тем, что хранится в управлении версиями. Файлы .iml все равно будут находиться вокруг, поэтому он не решает случайные изменения в них (возможно, не вмешивается их в исходное управление?), Но совместное использование таких вещей, как стиль кода и профили проверки, легко, поскольку каждый из них будет в собственном файле в каталоге .idea.

Ответ 2

От официального DOC: http://devnet.jetbrains.com/docs/DOC-1186

В зависимости от формата проекта IntelliJ IDEA (файл .ipr на основе или .idea), вы должны поместить следующий IntelliJ IDEA файлы проекта под управлением версии:

.ipr формат на основе

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

. каталог на основе каталога

Поделитесь всеми файлами в каталоге .idea в корне проекта, за исключением файлы workspace.xml и tasks.xml, которые хранят специфические для пользователя, также можно использовать все файлы модулей .iml.

Я положил его в свой .gitignore:

#Project
workspace.xml
tasks.xml

Ответ 3

Доступен официальный ответ . Предполагая, что вы используете современный (и теперь по умолчанию) формат файла папки .idea:

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

Этот образец .gitignore файл может быть полезной ссылкой, хотя вы должны прочитать приведенную выше ссылку, чтобы понять, почему эти записи появляются, и решить, нужны ли они вам.

Лично я также игнорирую файл .idea/find.xml, поскольку это, кажется, меняется каждый раз, когда вы выполняете операцию поиска.

Ответ 4

Я взял workpace.xml из источника управления (+ добавлен в .gitignore).

Ответ 5

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

UPDATE:

Теперь легче ответить, что я использую Maven и его структуру каталогов по умолчанию.

IntelliJ следует попросить игнорировать все файлы в папках /.svn, /.idea и /target. Все, относящееся к информации о отдельном пути, хранится в /.idea.

Все остальное - честная игра, предназначенная для Subversion или Git.

Ответ 6

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

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

Этот подход основан на том, что IntelliJ ищет только определенные местоположения для своих файлов настроек, поэтому он также применяется к файлам конфигурации каркаса. На самом деле мы игнорировали файл Grails.properties таким же образом, поэтому разработчики не будут случайно проверять свои локальные изменения конфигурации.