Следует ли мне держать файлы проекта под контролем версий? [закрыто]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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