it-swarm.com.ru

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

Должен ли я хранить файлы проекта, такие как Eclipse .project, .classpath, .settings, под контролем версий (например, Subversion, GitHub, CVS, Mercurial и т.д.)?

85
cretzel

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

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

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

91
VonC

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

30
Kevin

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

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

16
Chris Vest

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

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

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

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

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

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

7
Vihung

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

6
John Topley

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

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

5
Andreas Holstenson

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

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

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

5
Kevin Day

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

1
Jay R.

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

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

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

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

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

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

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


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

1
KLE

Да. Все, кроме создания выходных.

0
nitind

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

0
dbrien

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

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

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

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

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

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

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

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

0
Jonik