Как работать с файлами IntelliJ IDEA project под управлением git source control, которые постоянно меняются?

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

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

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

Итак, вот некоторые мысли, которые у нас есть о вариантах, которые мы должны иметь дело с этим:

1. полностью выведите файлы проекта из системы управления версиями. Положи их в машину .gitignore, и распространять их для каждого человека и TeamCity с помощью некоторых других средств, возможно, поместив их в систему управления версиями где-то еще или под другими именами. Наша команда достаточно мала этот вариант достаточно осуществим, чтобы рассмотреть, но это не кажется большим.


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


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

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

спасибо.