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

Question

Это может сводиться к мнению: Мне интересно, должны ли файлы проекта (файлы, сгенерированные и используемые IDE, а не компилятор) в исходные репозитории. Существуют ли определенные случаи, когда они должны и не должны?

Редактировать: Я должен упомянуть, что причина, о которой я прошу, заключается в том, что я смотрю на некоторые списки файлов, которые будут игнорироваться git при использовании Visual Studio. В некоторых из этих списков есть файлы проекта, а некоторые нет ,

Answer 1

Один простой вопрос: Вам нужен их для создания кода? Если нет, то они являются артефактами, а не исходными файлами, и им не место в исходной системе управления.

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

Мы храним все, необходимые для сборки, вплоть до установки операционной системы и необходимой конфигурации. Anal-retentive даже не приблизился к описанию нас :-) Если бы мы могли хранить аппаратное обеспечение, мы бы (мы должны справиться с хранением документа, детализирующего спецификации оборудования).

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

Answer 2

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

Answer 3

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

Answer 4

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

Answer 5

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

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

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

Answer 6

• держать под контролем версий все файлы проекта, которые необходимы для создания проекта
• избежать добавления производных (например, Ctags, и все файлы, которые могут генерировать)

Answer 7

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

Например, при использовании Visual Studio файлы '.proj' и '.sln' должны управляться версиями, но '.suo 'следует игнорировать.

Answer 8

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

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

Есть две разные выгоды от versionning файлов проекта:

• один легче developping. Специально для нового разработчика. Все, что вам нужно сделать, чтобы начать работать, это сделать заказ.
• другой должен иметь воспроизводимую сборку. Wether сборка происходит от разработчика A или разработки B, результирующий объект тот же. Это ИМО является более важным преимуществом и является шагом на пути автоматизации строительства.

Answer 9

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

Я могу сказать, что выполнение этого запроса было непростым!

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

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

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

Answer 10

Для .NET я думаю, что файлы проекта должны быть включены в репозитории управления версиями. В C# и VB это файл проекта, который определяет, какие исходные файлы являются частью сборки. Если вы добавите исходный файл в проект и не имеете файл проекта под контролем источника, все остальные разработчики в команде должны вручную добавить файл в проект THEIR.

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

Answer 11

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

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

Answer 12

Не уверен, если это было упомянуто, но Visual Studio (по крайней мере, C++ версии) производит два файла проекта:

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