Каждый в нашей команде использует 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. Но похоже, что мы не могли быть единственной командой, имеющей эту проблему. Вопросы, которые похожи на StackOverflow, включают 3495191 , 1000512 и 3873872 , но я не знаю, так как они точно такой же проблемы, и может быть, кто-то может придумать плюсы и минусы для различных подходов, которые я изложил, подходов, перечисленных в ответах на эти вопросы, или подходов, которые они рекомендуют.
Спасибо.