Хорошо, чтобы проверить мое понимание:
Здесь нужно рассмотреть четыре типа контента: код небольшой вспомогательной библиотеки (который вмещается здесь только в один файл), производственные / внешние пользователиутилиты, а также тесты и примеры.Вы предоставляете библиотеку, тестовые и примерные примеры и хотите вписать свою полезную нагрузку в рабочие процессы внешних пользователей.
Если бы это был скомпилированный код, он был бы совершенно обычным: соберите и протестируйте свою утилиту, отправьтепродукт, производственные пользователи используют поставляемую библиотеку, или, если они в нее входят, создайте ее сами как подмодуль и отправляйте или переносите исправления.
Когда нет этапа компиляции и сборки, особенно когдаполезная нагрузка - это отдельный файл, как здесь, границы начинают немного раздражать, естественное желание - «я не могу просто получить один файл?».
Да?Предполагая, что я подобрался достаточно близко, чтобы работать с:
Важно понимать, что единственная действительно важная структура в Git - это родословная связь.Любой репозиторий может содержать любое количество различных историй.
В частности, люди, использующие вашу библиотеку стилей, могут вносить ваши опубликованные истории и работать с ними так, как им нравится.
Все пользователи:
git remote add acstyle u://r/l
git fetch acstyle
just-gimme-пользователи the-content могут затем сделать
git checkout acstyle/payload -- .
, и теперь их извлечение имеет самую последнюю полезную нагрузку.
Пользователи, более знакомые с Git, могут захотеть, чтобы он вел записи для них, они могут
git merge acstyle/payload # initially with `--allow-unrelated-histories`
и их извлечения имеют такое же дополнительное содержимое, но также записывают его происхождение.
Вы можете предложить несколько веток в опубликованном репо и, например, объединить пустую полезную нагрузку с тестовыми сценариями / примерами сценариев.Это легко сделать.
Допустим, у вас есть "основная" ветка разработки со всеми вашими тестовыми примерами и примерами, но вы хотите создать ветки полезной нагрузки, как описано выше, которые не будут засорять репозитории других людей.
Начальное построение минимальной ветви payload:
# from any clean checkout
git checkout --orphan payload
git reset --hard
git checkout master -- acstyle.sty
git commit -m "acstyle-payload-v1.0"
Когда пришло время опубликовать новую версию полезной нагрузки, сделайте это снова, но пропустите потерянные биты и биты сброса, или опубликуйте полную историюза подсказкой, так что она есть, но не засоряет оформление заказа, вы можете сделать
git checkout payload
git merge -s ours --no-commit master # add `--allow-unrelated-histories` the first time
git checkout master -- acstyle.sty
git commit -m "acstyle-payload-v1.1"
Я не знаю, как предсказать, понравится ли пользователям полная история разработки за -s ours, объединить этоТаким образом, поддерживать и то, и другое легко.
Вы можете поддерживать ветки «полезная нагрузка плюс примеры» и любые другие варианты, которые кажутся вам одинаковыми, пользователи просто выбирают то, что хотят, и объединяют его в свою собственную историю.
Если вы идете по этому пути, не используйте теги в опубликованном репозитории, Git по умолчанию копирует все теги из каждого репоистория, из которой они извлекаются, и они засоряют историю ваших пользователей.Вместо этого, просто используйте сообщения фиксации, пользователи могут использовать синтаксис :/ для ссылки на коммиты по содержимому сообщения, если они хотят что-то отличное от самого последнего,
git checkout :/^acstyle-payload-v0.9a -- acstyle.sty
, и они могут видеть журнал опубликованныхверсии с
git log --oneline ---first-parent acstyle/payload