Должны ли файлы проекта IDE быть переведены под контроль исходного кода? - PullRequest
11 голосов
/ 04 августа 2010

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

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

Ответы [ 12 ]

14 голосов
/ 04 августа 2010

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

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

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

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

6 голосов
/ 04 августа 2010

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

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

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

2 голосов
/ 04 августа 2010

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

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

2 голосов
/ 04 августа 2010

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

2 голосов
/ 04 августа 2010

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

1 голос
/ 04 августа 2010

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

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

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

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

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

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

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

0 голосов
/ 04 августа 2010

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

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

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

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

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

...