Обмен файлами между ветками в Git

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

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

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

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

есть .gitignore мой единственный вариант?

16
branch git git-branch version-control

6 ответов

хранить сценарии сборки и пакетные файлы в отдельном РЕПО?

2

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

Как говорится в документация:

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

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

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

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

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

4

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

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

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

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

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

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

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

2

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

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

0

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

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

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

0

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

git checkout workingbranch
git checkout sharedbranch <needed file>

позже можно обновить, просто с помощью той же команды 

git checkout sharedbranch <needed file>
0