Совместное использование файлов по веткам в Git

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

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

Как вы справляетесь с этой ситуацией?

Отслеживаете ли вы все, связанные с вашим проектом, в Git? Каков ваш подход к общему объекту?

Является ли .gitignore моей единственной опцией?

Ответ 1

Сохраняйте сценарии сборки и пакетные файлы в отдельном репо?

Ответ 2

Вместо того, чтобы полагаться на подмодули, считали ли вы git-subtree?

Как указано в документации:

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

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

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

Ниже приведены некоторые сообщения, дающие некоторую обратную связь и объясняющие плюсы поддеревьев над подмодулями:

Очень интересная (и несколько нагретая) нить из списка рассылки git, обсуждающая плюсы и минусы git -subtree и subodule

http://amailbox.org/mailarchive/git/2010/7/21/34793

Ответ 3

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

Во-первых, git не имеет понятия отслеживания отдельных файлов, только целых хранилищ и ветвей.

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

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

Я не мог найти решение, потому что я не читал книги на git, и я не знал правильного условия поиска. git решение для этой ситуации submodule.

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

В этом случае должен быть настроен репозиторий remote git, и файлы будут поддерживаться в отдельном репозитории с помощью git -push.

Ответ 4

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

Если я использую более сложную цепочку инструментов, я создам исходные XML файлы, которые описывают базовые части, файлы XML, которые описывают конкретные варианты экземпляров, затем запускают XSLT, используя свойство профиля или командной строки, чтобы генерировать локальные соответствующие версии как часть конфигурации сборки / script в зависимости от вашего яда. Это не должно быть XML/XSL, я просто разбираюсь в XML много, вы можете использовать любую систему перебора, которая работает с вашей средой сборки, скажем, текстовые файлы с perl-скриптами или просто sed/awk.

Ответ 5

Вы можете добиться того же эффекта, что и файлы .gitignore, установив бит отслеживаемых файлов отслеживаемых файлов.

git update-index --skip-worktree <path_to_file>

Git теперь будет притворяться, что ваши файлы обновлены.