Должен ли я хранить файлы проекта под контролем версий?

Ответ 1

Вы хотите сохранить в управлении версиями любые переносные файлы настроек,
Значение:
Любой файл, который не имеет абсолютного пути в нем.
Это включает в себя:

• .project,
• .classpath(если абсолютный путь не используется, что возможно с использованием переменных IDE или переменных среды пользователя)
• Настройки IDE (где я не согласен с "принятым" ответом). Эти настройки часто включают в себя правила анализа статического кода, которые жизненно важны для последовательного применения для любого пользователя, загружающего этот проект в его/ее рабочее пространство.
• Рекомендации по конкретным настройкам IDE должны быть записаны в большом файле README (и, конечно же, с версией).

Правило для меня:
Вы должны иметь возможность загружать проект в рабочее пространство и иметь в нем все, что вам нужно, чтобы правильно настроить его в своей среде разработки и начать работу за считанные минуты.
Нет дополнительной документации, страниц вики для чтения или нет.
Загрузите его, настройте, идите.

Ответ 2

.project и .classpath файлы да. Однако мы не сохраняем наши настройки среды IDE в контроле версий. Есть некоторые плагины, которые не очень хорошо справляются с сохраняющимися настройками, и мы обнаружили, что некоторые настройки не очень переносимы с одной машины dev на другой. Итак, вместо этого у нас есть страница Wiki, в которой описаны шаги, необходимые разработчику для настройки их IDE.

Ответ 3

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

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

Ответ 4

Я разрывается между двумя вариантами.

С одной стороны, я считаю, что каждый должен иметь право использовать набор инструментов разработки, с которыми они наиболее продуктивны, до тех пор, пока все исходные артефакты хранятся в управлении версиями, а сборка script (скажем, ANT или Maven) обеспечивает соответствие стандартам, определяя, какой именно JDK использовать, какие версии сторонних библиотек зависят от них, выполнение проверок стиля (например, checkstyle) и тестовых модулей и т.д.

С другой стороны, я думаю, что многие люди используют одни и те же инструменты (например, Eclipse), и зачастую гораздо лучше иметь некоторые вещи, стандартизированные во время разработки, а не время сборки - например, Checkstyle гораздо полезнее в качестве Eclipse плагин, а не как задача ANT или Maven - лучше стандартизировать набор инструментов разработки и общий набор плагинов.

Я работал над проектом, в котором все использовали точно такой же JDK, ту же версию Maven, ту же версию Eclipse, тот же набор плагинов Eclipse и те же файлы конфигурации (например, профили Checkstyle, правила форматирования кода и т.д.). Все они содержались в исходном управлении -.project,.classpath и все в папке .settings. Это сделало жизнь очень легкой на начальных этапах проекта, когда люди постоянно настраивали зависимости или процесс сборки. Это также очень помогло при добавлении новых начинающих в проект.

В целом, я думаю, что, если у вас не так много шансов на религиозную войну, вы должны стандартизировать базовый набор инструментов разработки и плагинов и обеспечить соответствие версии в сценариях сборки (например, явно указывая версию Java). Я не думаю, что есть большая польза для хранения JDK и Eclipse в контроле источника. Все остальное, что не является производным артефактом, включая ваши файлы проекта, настройки и настройки плагина (в частности, форматирование кода и правила стиля), должно идти в исходное управление.

P.S. Если вы используете Maven, есть аргумент в пользу того, что файлы .project и .classpath являются производными артефактами. Это справедливо только в том случае, если вы генерируете их каждый раз, когда выполняете сборку, и если вам никогда не приходилось вручную их подстраивать (или непреднамеренно менял их, изменяя некоторые настройки) после генерации их из POM

Ответ 5

Нет, потому что я только файлы управления версиями, необходимые для создания программного обеспечения. Кроме того, у отдельных разработчиков могут быть свои собственные настройки для проекта.

Ответ 6

Нет, я тяжелый Maven пользователь и Q для Eclipse, который создает и сохраняет обновления .project и .classpath. Для других вещей, таких как настройки для плагинов, я обычно использую README или Wiki-страницу об этом.

Также те, с кем я работал, предпочитают, чтобы другие IDE просто использовали Maven-плагины для генерации файлов, необходимых для поддержки их IDE (и самих себя).

Ответ 7

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

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

Я рекомендую использовать что-то вроде Maven или Ant в качестве стандартизованной системы сборки. Любой разработчик может получить путь к классам, сконфигурированный в их IDE, через несколько секунд.

Ответ 8

Да, кроме папки .settings. Согласование других файлов работает хорошо для нас. Существует аналогичный вопрос здесь.

Ответ 9

Несмотря на то, что я вообще согласен с подходом "не сгенерированные версии файлов", у нас есть проблемы с ним и нужно вернуться.

Примечание. Меня также интересует ответ VonC, в частности, о точке "получить Eclipse в считанные минуты". Но это не является решающим для нас.

Наш контекст - Eclipse + Maven, используя плагин m2eclipse. У нас есть общая среда разработки с максимально возможными общими каталогами. Но иногда бывает, что кто-то будет пытаться подключить плагин или изменить мелочи в конфигурации или импортировать второе рабочее пространство для другой ветки...

Наша проблема заключается в том, что генерация .project выполняется при импорте проекта в Eclipse, но не обновляется во всех случаях позже. Это печально и, вероятно, не является постоянным, поскольку плагин m2eclipse улучшится, но это правда сейчас. Таким образом, у нас есть разные конфигурации. То, что у нас было сегодня, было то, что: несколько натур были добавлены ко многим проектам на какой-то машине, а затем вели себя по-другому: - (

Единственное решение, которое мы видим, - это версия файла .project (во избежание рисков мы сделаем то же самое для .classpath и .settings). Таким образом, когда один разработчик меняет свой pom, локальные файлы обновляются с использованием m2eclipse, все они передаются вместе, а другие разработчики будут видеть все изменения.

Примечание: в нашем случае мы используем относительные имена файлов, поэтому у нас нет проблем для обмена этими файлами.

Итак, чтобы ответить на ваш вопрос, я говорю "да", передайте эти файлы.

Мне также понравилось:

• Богатый продавец ответ

Ответ 10

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

Ответ 11

Да. Все, кроме сборки.

Ответ 12

Мы используем IntelliJ IDEA и сохраняем версии ".sample" проекта (.ipr) и модуля (.iml) под контролем версий.

Немного больше здесь - совместное использование и повторное использование, чем управление версиями, ИМХО. Но если вы собираетесь поделиться этими конфигурациями, то, что лучше разместить их, чем репозиторий, рядом со всем остальным.

Некоторые преимущества общих и версий файлов проекта:

• Вы можете проверить любой тег/ветку и быстро начать работать над ней.
• Это облегчает для нового разработчика сначала настройку среды разработки и ускорение
• Это лучше соответствует DRY, что всегда глубоко удовлетворяет. До этого все разработчики время от времени устанавливали эти вещи, делая по существу повторную работу. Конечно, у каждого были свои собственные способы избежать повторения себя, но, глядя на команду в целом, было много дублированных усилий.

Обратите внимание, что в IDEA эти файлы содержат такие конфигурации, как: какие источники "источник" и "источник тестирования"; все о внешних зависимостях (где расположены баки библиотеки, а также связанные источники или javadocs); варианты сборки и т.д. Это материал, который не отличается от разработчика к разработчику (я не согласен с этим довольно сильно). В IDEA хранятся более личные настройки IDE в другом месте, а также любые конфигурации плагинов. (Я не очень хорошо знаю Eclipse, это может быть или не быть совсем другим.)

Я согласен с этим ответом, который гласит:

Вы должны иметь возможность загрузить проект в рабочее пространство и иметь в нем все, что вам нужно, чтобы правильно установить его в вашей среде IDE и минут. [...] Загрузите его, настройте, идите.

И мы имеем это как это, благодаря версиям файлов проекта.