Должен ли я хранить файлы моего проекта под контролем версий?
Должен ли я хранить файлы проекта, такие как.project, .classpath, .settings в Eclipse, под контролем версий (например, Subversion, GitHub, CVS, Mercurial и т. Д.)?
12 ответов
Вы хотите сохранить в управлении версиями любые переносимые файлы настроек,
имея в виду:
Любой файл, в котором нет абсолютного пути.
Это включает:
- .project,
- .classpath (если не используется абсолютный путь, что возможно при использовании переменных IDE или переменных среды пользователя)
- Настройки IDE (где я категорически не согласен с "принятым" ответом). Эти параметры часто включают в себя правила статического анализа кода, которые жизненно важны для последовательного применения для любого пользователя, загружающего этот проект в свое рабочее пространство.
- Рекомендации по конкретным настройкам IDE должны быть записаны в большом файле README (и, конечно, также с версионными версиями).
Эмпирическое правило для меня:
Вы должны быть в состоянии загрузить проект в рабочее пространство и иметь в нем все необходимое, чтобы правильно настроить его в своей среде IDE и приступить к работе за считанные минуты.
Никакой дополнительной документации, вики-страниц для чтения или чего нет.
Загрузите это, установите это, иди.
Файлы.project и.classpath да. Однако мы не храним наши настройки IDE в управлении версиями. Есть некоторые плагины, которые не справляются с сохранением настроек, и мы обнаружили, что некоторые настройки не были очень переносимыми с одной машины на другую. Таким образом, вместо этого у нас есть страница Wiki, которая освещает шаги, необходимые разработчику для настройки своей IDE.
Это то, что я считаю сгенерированными файлами, и поэтому я никогда не помещаю их под контроль версий. Они могут отличаться от машины к машине и от разработчика к разработчику, например, когда у людей установлены разные плагины Eclipse.
Вместо этого я использую инструмент сборки (Maven), который может генерировать первоначальные версии этих файлов при создании новой проверки.
Я разрываюсь между двумя вариантами здесь.
С одной стороны, я думаю, что каждый должен иметь право использовать набор инструментов developmnt, с которыми они наиболее продуктивны, если все исходные артефакты хранятся в системе контроля версий, а сценарий сборки (скажем, ANT или Maven) обеспечивает соответствие стандартам путем указание, какой именно JDK использовать, от каких версий сторонних библиотек зависеть, проверки стилей (например, checkstyle) и модульных тестов и т. д.
С другой стороны, я думаю, что многие люди используют одни и те же инструменты (например, Eclipse), и часто гораздо лучше стандартизировать некоторые вещи во время разработки, а не во время сборки - например, Checkstyle гораздо более полезен как плагин Eclipse, чем как Задача ANT или Maven - лучше стандартизировать набор инструментов разработки и общий набор плагинов.
Я работал над проектом, в котором все использовали один и тот же JDK, одну и ту же версию Maven, одну и ту же версию Eclipse, один и тот же набор плагинов Eclipse и одни и те же файлы конфигурации (например, профили Checkstyle, правила форматирования кода и т. Д.). Все они хранились в системе контроля версий -.project,.classpath и все в папке.settings. Это действительно облегчило жизнь на начальных этапах проекта, когда люди постоянно настраивали зависимости или процесс сборки. Это также очень помогло при добавлении новых стартеров в проект.
В целом, я думаю, что если не так уж много шансов на религиозную войну, вам следует стандартизировать базовый набор инструментов разработки и плагинов и обеспечить соответствие версии в ваших сценариях сборки (например, путем явного указания версии Java).I не думайте, что сохранение JDK и установки Eclipse в системе управления версиями приносит большую пользу. Все остальное, что не является производным артефактом, включая файлы проекта, настройки и настройки плагинов (в частности, форматировщик кода и правила стиля), должно входить в систему контроля версий.
PS Если вы используете Maven, есть аргумент, что файлы.project и.classpath являются производными артефактами. Это верно только в том случае, если вы генерируете их каждый раз, когда делаете сборку, и если вам никогда не приходилось настраивать их вручную (или неумышленно изменять их, изменяя некоторые предпочтения) после генерации их из POM
Нет, потому что я использую только файлы контроля версий, необходимые для сборки программного обеспечения. Кроме того, отдельные разработчики могут иметь свои собственные настройки проекта.
Нет, я опытный пользователь Maven и использую плагин Q для Eclipse, который создает и поддерживает обновления.project и.classpath. Для других вещей, таких как настройки для плагинов, я обычно поддерживаю README или Wiki-страницу об этом.
Также те, с кем я работал, предпочитают другие IDE, просто используют плагины Maven для генерации файлов, необходимых для того, чтобы их IDE (и они сами) были довольны.
Я полагаю, что это все мнение, но лучшие практики за эти годы показывают, что файлы, специфичные для данной IDE, не должны храниться в системе контроля версий, если только вся ваша организация не стандартизирована в одной IDE и вы никогда не собираетесь переключаться.
В любом случае, вы определенно не хотите сохранять пользовательские настройки - и.project может содержать настройки, которые действительно специфичны для разработчика.
Я рекомендую использовать что-то вроде Maven или Ant в качестве стандартизированной системы сборки. Любой разработчик может настроить classpath в своей IDE за несколько секунд.
Хотя я в целом согласен с подходом "не создавать сгенерированные файлы", у нас есть проблемы с ним, и мы должны вернуться назад.
Примечание: меня также интересует ответ VonC, в частности, о том, что нужно "получить Eclipse за несколько минут". Но это не имеет решающего значения для нас.
Наш контекст - Eclipse+Maven, использующий плагин m2eclipse. У нас общая среда разработки, с максимально возможными общими каталогами. Но иногда случается, что кто-то может попробовать подключаемый модуль, изменить мелочи в конфигурации или импортировать второе рабочее пространство для другой ветви...
Наша проблема заключается в том, что генерация.project выполняется при импорте проекта в Eclipse, но позже не обновляется во всех случаях. Это печально и, вероятно, не навсегда, так как плагин m2eclipse улучшится, но это правда сейчас. Таким образом, мы получаем разные конфигурации. То, что у нас было сегодня, было так: несколько натур были добавлены во многие проекты на какой-то машине, которые затем вели себя по-разному:-(
Единственное решение, которое мы видим, - это версия файла.project (чтобы избежать рисков, мы сделаем то же самое для.classpath и.settings). Таким образом, когда один разработчик меняет свой pom, локальные файлы обновляются с использованием m2eclipse, все они фиксируются вместе, и другие разработчики видят все изменения.
Примечание: в нашем случае мы используем относительные имена файлов, поэтому у нас нет проблем с тем, чтобы делиться этими файлами.
Итак, чтобы ответить на ваш вопрос, я говорю да, передайте эти файлы.
Мне также понравилось:
- Богатый ответ продавца
Да, кроме папки.settings. Передача других файлов хорошо работает для нас. Здесь есть похожий вопрос.
Мы используем IntelliJ IDEA и сохраняем ".sample" версии файлов проекта (.ipr) и модуля (.iml) под контролем версий.
ИМХО, здесь важнее обмен и повторное использование, чем управление версиями. Но если вы собираетесь поделиться этими конфигурациями, что может быть лучше, чем поместить их в хранилище, рядом со всем остальным.
Некоторые преимущества общих и версионных файлов проекта:
- Вы можете проверить любой тег / ветку и быстро начать работу
- Новому разработчику легче сначала настроить среду разработки и ускориться
- Это лучше придерживается СУХОЙ, которая всегда глубоко удовлетворяет. До этого всем разработчикам приходилось время от времени настраивать эти вещи, по сути, повторяя работу. Конечно, у каждого были свои маленькие способы избежать повторения, но, глядя на команду в целом, было много дублированных усилий.
Обратите внимание, что в IDEA эти файлы содержат конфигурации, такие как: что такое каталоги "source" и "test source"; все о внешних зависимостях (где находятся библиотеки jar, а также связанные источники или javadocs); параметры сборки и т. д. Это вещи, которые не отличаются от разработчика к разработчику (я не согласен с этим довольно сильно). IDEA хранит больше личных настроек IDE в другом месте, а также любые конфигурации плагинов. (Я не очень хорошо знаю Eclipse; это может отличаться или не сильно отличаться.)
Я согласен с этим ответом, который говорит:
Вы должны быть в состоянии загрузить проект в рабочее пространство и иметь в нем все необходимое, чтобы правильно настроить его в своей среде IDE и приступить к работе за считанные минуты. [...] Загрузите это, установите это, иди.
И у нас это так, благодаря версионным файлам проекта.
Кажется, что эти файлы проекта могут меняться со временем, когда вы работаете над проектом, так что да, я помещаю их под контроль версий.