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

Question

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

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

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

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

Является ли .gitignore моим единственным вариантом?

Answer 1

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

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

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

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

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

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

• http://ayende.com/Blog/archive/2011/01/10/the-problem-with-git-submodules.aspx
• http://ayende.com/Blog/archive/2011/01/10/git-subtree.aspx
• http://hobocentral.net/blog/2010/07/28/git-subtree/
• http://h2ik.co/2011/03/having-fun-with-git-subtree/

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

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

Answer 2

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

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

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

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

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

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

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

Answer 3

Храните ваши сценарии сборки и командные файлы в отдельном репозитории?

Answer 4

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

git checkout workingbranch
git checkout sharedbranch <needed file>

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

git checkout sharedbranch <needed file>

Answer 5

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

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

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

Answer 6

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

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