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