Git subtree - окончание изучения
- Алик Ким
- 3 авг. 2023 г.
- 2 мин. чтения
Обновлено: 10 февр. 2024 г.
добил тему изучения git subtree.
(полусырые) результаты предыдущего изучения - тут.
дисклеймер: пока что не практике поддерево не пробовал, практический опыт имею только с git submodule (который и побудил поискать альтернативы). планирую попробовать в ближайшем будущем.
что для себя вынес:
ядро функционала git subtree - это копирование части истории изменений (коммитов) какого-то репозитория, относящейся к определенной подпапке в этом репозитории, в отдельную ветку/последовательность коммитов (или как сказать то). все коммиты, затрагивающие эту подпапку, копируются. при чем, если коммит так же затрагивает что-то вне папки поддерева - эти изменения просто отбрасываются.
ну и ,вот, вокруг этой фичи строится вся остальная функциональность.
как я вижу воркфлоу работы с проектом, использующим другой проект (библиотеку) в качестве поддерева гит:
создаем в проекте папку, в которую хотим положить библиотеку
добавляем в проект второй origin, указывающий на библиотеку (в tortoice git: контекстное меню папки - настройки - Git - Remote - добавляем)
привязываем библиотеку в качестве поддерева - так (все делается в папке проекта):
git subtree add --prefix имя_папки имя_ориджина_библиотеки имя_ветки_библиотеки
например:
git subtree add --prefix TestSubProj subproj_origin lib_branch
работаем-работаем, используем библиотеку. в общем случае - в ветке задачи (ну типа гитфлоу)
потом все, функциональность дописали, сделали сквош-мердж в основную ветку (в том числе туда попали и изменения в файлах подпапки библиотеки)
и теперь заливаем изменения обратно в библиотеку:
git subtree push --rejoin --prefix SubTreeLib subtree_lib_origin master --annotate "этот текст будет префиксом к тексту переносимых в поддерево коммитов"
--rejoin -создает что-то типа мердж-коммита между последними изменениями, которые мы залили в поддерево (которые скопированы из подпапки поддерева в нашем проекте), и (текущей) веткой нашего проекта (ох, надеюсь, это понятно написано, ох я костноязычный). без этого будут тупые конфликты при дальнейшей работе.
слабое место этой всей схемы - изменения в поддерево идут с комментариями, данными для вышеупомянутого сквош-коммита проекта. соответственно, комментарий коммита будет содержать описание выполненной в проекте задачи, и в контексте библиотеки он будет непонятен. тут как то может помочь annotate. но было бы здорово, если б какое то решение получше нашлось.
в процессе работы над задачей в (отдельной) ветке обновлять поддерево из удаленного репозитория (ну, может, там кто то другой изменения внес) нужно - как и в случае с обычной родительской веткой - чем чаще, тем лучше. делается это командой pull:
git subtree pull --prefix SubTreeLib subtree_lib_origin master
если после этой команды возникнут конфликты - они разруливаются в общем порядке
есть у команды push , вроде как, свой параметр sqwash. в моем воображаемом воркфлоу он, вроде, не нужен, но , вот, мало ли, вот, упоминаю.
Дополнение: в проекте-пользователе поддерева нужно как-то вести список поддеревьев, какое к какому репозиторию приписано (например, в текстовом файле). потому что если такой проект клдонировать - информации о поддеревьях не будет
---
см. так же:
Comments