Что НЕ должно быть под контролем источника?
Было бы неплохо иметь более или менее полный список файлов и / или каталогов, которые не должны (в большинстве случаев) находиться под контролем исходного кода. Как вы думаете, должно быть исключено?
Предложение пока:
В общем
- Конфиг файлы с конфиденциальной информацией (пароли, закрытые ключи и т. Д.)
- Thumbs.db,.DS_Store и desktop.ini
- Резервные копии редактора: *~ (emacs)
- Сгенерированные файлы (например, вывод DoxyGen)
C#
- бен \*
- OBJ \*
- *.EXE
Visual Studio
- *.suo
- *.ncb
- *.user
- *.aps
- *.cachefile
- *.резервное копирование
- _UpgradeReport_Files
Джава
- *.учебный класс
Затмение
Я не знаю, и это то, что я сейчас ищу:-)
питон
- *.pyc
Временные файлы - .*. Sw? - *~
24 ответа
Все, что генерируется. Двоичный, байт-код, код / документы, сгенерированные из XML.
Из моих комментаторов исключить:
- Все, что сгенерировано при сборке, включая документацию кода (doxygen, javadoc, pydoc и т. Д.)
Но включают в себя:
- Сторонние библиотеки, для которых у вас нет исходного ИЛИ, не собираются.
FWIW, в моей работе над очень крупным проектом у нас есть следующее под ClearCase:
- Весь оригинальный код
- Исходный код Qt И встроенная отладка / выпуск
- (Ужасно устаревшие) спецификации
У нас нет встроенных модулей для нашего программного обеспечения. Полный бинарный файл распространяется каждые пару недель с последними обновлениями.
Специфичные для ОС файлы, созданные их файловыми браузерами, такими какThumbs.db а также .DS_Store
Некоторые другие типичные файлы / папки Visual Studio
*.cachefile
*.backup
_UpgradeReport_Files
Например, моя картина игнорирования черепахи выглядит так:
bin obj *.suo *.user *.cachefile *.backup _UpgradeReport_Files
Как сказал Corey D, все, что генерируется, в частности, все, что генерируется процессом сборки и средой разработки, являются хорошими кандидатами. Например:
- Двоичные файлы и установщики
- Байт-код и архивы
- Документы, сгенерированные из XML и кода
- Код, сгенерированный шаблонами и генераторами кода
- Файлы настроек IDE
- Резервное копирование файлов, созданных вашей IDE или редактором
Некоторые исключения из вышеперечисленного могут быть:
- Изображения и видео
- Сторонние библиотеки
- Файлы настроек конкретной команды IDE
Возьмите сторонние библиотеки, если вам нужно отправить или ваша сборка зависит от сторонней библиотеки, было бы неразумно поставить ее под контроль исходного кода, особенно если у вас нет исходного кода. Также учтите, что некоторые системы контроля версий не очень эффективны для хранения двоичных двоичных объектов, и вы, вероятно, не сможете воспользоваться инструментами системного различий для этих файлов.
Paul Biggar также делает отличный комментарий о сгенерированных файлах, и вы должны проверить его ответ:
По сути, если вы не можете разумно ожидать, что разработчик будет иметь точную версию именно того инструмента, который им нужен, есть возможность поместить сгенерированные файлы в систему управления версиями.
С учетом всего сказанного в конечном итоге вам нужно будет рассмотреть то, что вы поставили под контроль источников, в каждом конкретном случае. Определение жесткого списка того, что и что не следует включать в него, будет работать только для некоторых и, вероятно, так долго. И, конечно же, чем больше файлов вы добавляете в систему управления версиями, тем больше времени потребуется для обновления вашей рабочей копии.
Я бы подошел к проблеме по-другому; какие вещи должны быть включены в систему контроля версий? Вы должны контролировать только те файлы, которые:
- (нужна история изменений ИЛИ создаются вне вашей сборки, но являются частью сборки, установки или носителя) И
- не может быть сгенерирован процессом сборки под вашим контролем И
- являются общими для всех пользователей, которые создают продукт (без пользовательских настроек)
Список включает в себя такие вещи, как:
- исходные файлы
- создавать, проектировать и файлы решений
- другие файлы конфигурации инструмента сборки (не связанные с пользователем)
- Сторонние библиотеки
- предварительно созданные файлы, которые отправляются на носители, такие как PDF-файлы и документы
- документация
- изображения, видео, звуки
- файлы описания, такие как WSDL, XSL
Иногда выходные данные сборки могут быть входными данными для сборки. Например, файл переименования обфускации может быть выходом и входом для сохранения одной и той же схемы переименования. В этом случае используйте отмеченный файл в качестве входных данных для сборки и поместите выходные данные в другой файл. После сборки извлеките входной файл, скопируйте в него выходной файл и проверьте его.
Проблема с использованием списка исключений заключается в том, что вы никогда не узнаете все правильные исключения и в конечном итоге можете контролировать источник, который не должен контролироваться источником.
Все, что может быть сгенерировано IDE, процессом сборки или двоичным исполняемым процессом.
Исключение:
4 или 5 разных ответов говорят, что сгенерированные файлы не должны попадать под контроль исходного кода. Это не совсем так.
Файлы, созданные специальными инструментами, могут входить в систему контроля версий, особенно если необходимы определенные версии этих инструментов.
Примеры:
- парсеры, сгенерированные bison/yacc/antlr,
- файлы autotools, такие как configure или Makefile.in, созданные autoconf, automake, libtool и т. д.;
- файлы перевода или локализации,
- Файлы могут быть сгенерированы дорогими инструментами, и может быть дешевле установить их только на несколько машин.
По сути, если вы не можете разумно ожидать, что разработчик будет иметь точную версию именно того инструмента, который им нужен, есть возможность поместить сгенерированные файлы в систему управления версиями.
Это исключение обсуждают ребята из svn в своих выступлениях о лучших практиках.
desktop.ini это еще один файл Windows, в котором я пробирался
Фактические файлы конфигурации, такие как web.config в asp.net, потому что люди могут иметь разные настройки. Обычно я справляюсь с этим, имея web.config.template в SVN. Люди получают его, вносят необходимые изменения и переименовывают его в web.config.
Помимо этого и того, что вы сказали, будьте осторожны с конфиденциальными файлами, содержащими пароли (например).
Избегайте всех раздражающих файлов, созданных Windows (большой палец) или Mac OS (.ds_store)
Файлы конфигурации, содержащие пароли или любую другую конфиденциальную информацию.
Лучший способ подумать об этом:
Представьте, что у вас есть новый, купленный в магазине компьютер. Вы устанавливаете ОС и обновления; Вы устанавливаете все свои инструменты разработки, включая клиент управления исходным кодом; вы создаете пустой каталог, который будет корнем ваших локальных источников; вы делаете "Получить последнюю версию" или как ее называет ваша система контроля версий, чтобы получить чистые копии релиза, который вы хотите собрать; Затем вы запускаете сборку (полученную из системы контроля версий), и все собирается.
Этот мыслительный процесс говорит вам, почему определенные файлы должны находиться в системе контроля версий: все, что необходимо для сборки, чтобы работать в чистой системе. Это включает файлы.designer.cs, выходные данные шаблонов T4 и любой другой артефакт, который сборка не будет создавать.
Временные файлы, конфигурация для всего, кроме глобальной разработки и конфиденциальной информации
Вещи, которые не входят в систему контроля версий, делятся на 3 класса
- Вещи, совершенно не связанные с проектом (очевидно)
- Вещи, которые можно найти на установочном носителе и которые никогда не меняются (например, сторонние API).
- Вещи, которые могут быть сгенерированы механически через ваш процесс сборки, из вещей, находящихся в управлении исходным кодом (или из вещей в классе 2).
У меня есть определенный файл.c, который не входит в систему контроля версий.
Правило - ничто в управлении исходным кодом, которое генерируется во время процесса сборки.
Единственное известное исключение - если для сборки инструмента требуется более старая версия (проблема с загрузкой). В этом случае вам понадобится хорошо зарекомендовавшая себя загрузочная копия в управлении исходным кодом, чтобы вы могли создавать ее с нуля.
Независимо от языка:
- файлы кеша
- как правило, импортированные файлы также не должны (например, изображения, загруженные пользователями в веб-приложении)
- временные файлы; даже те, что сгенерированы вашей ОС (например, thumbs.db под windows) или IDE
- конфигурационные файлы с паролями? Зависит от того, кто имеет доступ к хранилищу
И для тех, кто не знает об этом: svn:ignore отлично!
Если у вас есть среда выполнения для вашего кода (например, библиотеки зависимостей, конкретные версии компилятора и т. Д.), Не помещайте пакеты в систему контроля версий. Мой подход жестокий, но эффективный. Я фиксирую make-файл, роль которого состоит в том, чтобы загружать (через wget) материал, распаковывать его и создавать свою среду выполнения.
Прошло много времени с тех пор, как был задан этот вопрос, и я думаю, что многие ответы, хотя и актуальны, не содержат подробных сведений о .gitignore на уровне языка или IDE.
Github выпустил очень полезный, совместный с сообществом список .gitignore файлы для всех видов проектов и IDE, которые стоит посмотреть.
Вот ссылка на этот репозиторий git: https://github.com/github/gitignore
Чтобы ответить на вопрос, вот соответствующие примеры для:
- C# -> см. Visual Studio
- Visual Studio
- Джава
- Затмение
- питон
Есть также ОС-специфичные .gitignore файлы. Следующий:
Итак, если вы работаете в Windows и используете Eclipse, вы можете просто объединить Eclipse.gitignore а также Windows.gitignore к .gitignore файл в каталоге верхнего уровня вашего проекта. Очень изящные вещи.
Не забудьте добавить.gitignore к вашему репо и зафиксировать его!
Скорее всего, ваша IDE уже обрабатывает это для вас. Visual Studio делает в любом случае.
И для .gitignore файлы, если вы видите какие-либо файлы или шаблоны, отсутствующие в конкретном .gitignore Вы можете открыть PR для этого файла с предлагаемым изменением. Взгляните на коммит и потяните трекеры запросов на идеи.
Я всегда использую https://www.gitignore.io/ для создания правильного .ignore файл.
Выступая здесь, я считаю, что если вы используете списки задач в Visual Studio, они сохраняются в файле.suo. Возможно, это не причина держать их под контролем исходного кода, но это причина хранить резервную копию где-то, на всякий случай...
Мнение: при необходимости все может находиться под контролем исходного кода, если только это не приводит к значительным накладным расходам хранилища, таким как часто меняющиеся или большие двоичные объекты.
Сторонние бинарные файлы, которые трудно генерировать (с точки зрения времени) для ускорения процесса развертывания, все в порядке.
Основная цель системы контроля версий состоит в том, чтобы сопоставить одно согласованное состояние системы с номером редакции. Если бы это было возможно, я бы заморозил всю вселенную с помощью инструментов для сборки кода и целевой операционной системы.