Что НЕ должно быть под контролем источника?

Было бы неплохо иметь более или менее полный список того, какие файлы и/или каталоги не должны (в большинстве случаев) находиться под контролем источника. Как вы думаете, что должно быть исключено?

Предложение до сих пор:

Обычно

  • Конфигурируйте файлы с конфиденциальной информацией (пароли, закрытые ключи и т.д.).
  • Thumbs.db,.DS_Store и desktop.ini
  • Резервные копии редактора: * ~ (emacs)
  • Сгенерированные файлы (например, вывод DoxyGen)

С#

  • Bin\*
  • OBJ\*
  • *. Ехе

Visual Studio

  • *. Суо
  • *. НКТ
  • *. Пользователь
  • *. АПС
  • *. cachefile
  • *. backup
  • _UpgradeReport_Files

Java

  • *. Класс

Eclipse,

Я не знаю, и это то, что я ищу прямо сейчас: -)

Python

  • *. Pyc

Временные файлы  -. *. sw?  - * ~

ОТВЕТЫ

Ответ 1

Все, что сгенерировано. Двоичный, байт-код, код/​​документы, созданные из XML.

От моих комментаторов исключить:

  • Все, что генерируется сборкой, включая документацию кода (doxygen, javadoc, pydoc и т.д.).

Но включите:

  • Сторонние библиотеки, у которых у вас нет источника ИЛИ, не создаются.

FWIW, в моей работе для очень большого проекта, в ClearCase есть следующее:

  • Все исходные коды
  • Источник Qt И встроенная отладка/выпуск
  • (Ужасно устаревшие) характеристики

У нас нет встроенных модулей для нашего программного обеспечения. Полный бинар распространяется каждые две недели с последними обновлениями.

Ответ 2

Особые файлы ОС, созданные их файловыми браузерами, такие как Thumbs.db и .DS_Store

Ответ 3

Некоторые другие типичные файлы/папки Visual Studio

*.cachefile 
*.backup 
_UpgradeReport_Files

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

bin obj *.suo *.user *.cachefile *.backup _UpgradeReport_Files

Ответ 4

файлы, которые создаются, не должны быть отмечены в

Ответ 5

Как Corey D сказал все, что сгенерировано, в частности все, что генерируется процессом сборки и среда разработки - хорошие кандидаты. Например:

  • Бинарники и инсталляторы
  • Байт-код и архивы
  • Документы, созданные из XML и кода
  • Код, сгенерированный шаблонами и генераторами кода
  • Файлы настроек IDE
  • Резервные файлы, созданные вашей IDE или редактором

Некоторые исключения из вышеизложенного могут быть:

  • Изображения и видео
  • Сторонние библиотеки
  • Файлы настроек IDE для конкретной команды

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

Paul также дает отличный комментарий о сгенерированных файлах, и вы должны проверить его ответ:

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

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

Ответ 6

Все, что может быть сгенерировано IDE, процессом сборки или двоичным исполняемым процессом.

Ответ 7

Я бы подошел к проблеме по-другому; какие вещи должны включаться в исходный контроль? Вам следует только управлять этими файлами, которые:

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

В список входят такие вещи, как:

  • исходные файлы
  • make, project и файлы решений
  • другие файлы конфигурации инструмента сборки (не связанные с пользователем)
  • Сторонние библиотеки
  • готовые файлы, которые идут на носители, такие как PDF файлы и документы.
  • документация
  • изображения, видео, звуки
  • файлы описания, такие как WSDL, XSL

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

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

Ответ 8

Исключение:

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

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

Примеры:

  • парсеров, созданных bison/yacc/antlr,
  • файлы autotools, такие как configure или Makefile.in, созданные autoconf, automake, libtool и т.д.,
  • файлы перевода или локализации,
  • файлы могут быть сгенерированы дорогостоящими инструментами, и может быть дешевле устанавливать их только на нескольких машинах.

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

Это исключение обсуждается ребятами svn в их отзывах лучших практик.

Ответ 9

Файлы Temp от редакторов.

.*.sw?
*~

и др.

Ответ 10

desktop.ini - это еще один файл Windows, который я видел.

Ответ 11

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

Ответ 12

Фактические конфигурационные файлы, такие как web.config в asp.net, потому что люди могут иметь разные настройки. Обычно способ, которым я справляюсь с этим, - это иметь web.config.template, который находится на SVN. Люди получают его, вносят нужные изменения и переименовывают его как web.config.

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

Избегайте всех раздражающих файлов, созданных Windows (большой палец) или Mac OS (.ds_store)

Ответ 13

*.bak, созданный WinMerge.

Ответ 14

дополнительно:

Visual Studio

  • *. НКТ

Ответ 15

Лучший способ, о котором я подумал, выглядит следующим образом:

Притворись, что у тебя есть совершенно новый, купленный в магазине компьютер. Вы устанавливаете ОС и обновления; вы устанавливаете все свои средства разработки, включая клиент управления версиями; вы создаете пустую директорию как корень ваших локальных источников; вы делаете "получать последние" или независимо от того, что ваша система управления версиями вызывает его для извлечения чистых копий выпуска, который вы хотите построить; вы затем запускаете сборку (выбираете из исходного элемента управления), и все строит.

Этот процесс мышления говорит вам, почему определенные файлы должны находиться в исходном управлении: все те, которые необходимы для сборки для работы в чистой системе. Сюда входят файлы .designer.cs, выходы шаблонов T4 и любой другой артефакт, который не будет создавать сборка.

Ответ 16

Temp файлы, конфигурация для чего-либо, кроме глобального развития и конфиденциальной информации.

Ответ 17

Независимо от языка:

  • файлы кеша
  • обычно импортируемые файлы не должны (например, изображения, загруженные пользователями, в веб-приложении).
  • временные файлы; даже те, которые генерируются вашей ОС (например, thumbs.db под окнами) или IDE
  • файлы конфигурации с паролями? Зависит от того, кто имеет доступ к репозиторию.

И для тех, кто этого не знает: svn:ignore отлично!

Ответ 18

Вещи, которые не входят в исходное управление, входят в 3 класса

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

Ответ 19

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

Ответ 20

У меня есть файл .c, который не входит в исходный код.

Правило ничего не содержит в исходном управлении, которое создается во время процесса сборки.

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

Ответ 21

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

Ответ 22

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

Github вышла с очень полезным, объединенным сообществом списком файлов .gitignore для всех видов проектов и IDE, которые стоит посмотреть.

Здесь ссылка на git repo: https://github.com/github/gitignore

Чтобы ответить на вопрос, приведенные ниже примеры:

Существуют также файлы .gitignore, специфичные для ОС. После:

Итак, если вы используете Windows и используете Eclipse, вы можете просто конкатенировать Eclipse.gitignore и Windows.gitignore с файлом .gitignore на верхнем уровне каталог вашего проекта. Очень классный материал.

Не забудьте добавить .gitignore в свое репо и зафиксировать его!

Скорее всего, ваша IDE уже обрабатывает это для вас. Visual Studio все равно.

И для файлов .gitignore Если вы видите какие-либо файлы или шаблоны, отсутствующие в определенном .gitignore, вы можете открыть PR в этом файле с предлагаемым изменением. Взгляните на commit и запрос pull трекеры для идей.

Ответ 23

Я всегда использую www.gitignore.io для создания правильного файла .ignore.

Ответ 24

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

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

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