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

Каков наилучший рабочий процесс git для библиотек / фреймворков классов

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

Сценарий

Итак, у меня есть проект WinForm, который использует определенный элемент управления, я хочу управлять этим конкретным элементом управления отдельно, с помощью тестовой оснастки, но этот конкретный элемент управления должен существовать в основном проекте winform, так как он будет полезен для обновления / тестирования определенных элементов " жить »(например, вещи, которые имеют сложный ввод).

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

1
chrispepper1989 4 Дек 2014 в 12:08

2 ответа

Лучший ответ

Есть случай, когда весь «проект» необходимо клонировать и собрать (скажем, сервером сборки), включая его «пользовательские библиотеки классов». И иногда метод серверов сборки находится вне вашего контроля (например, изменение скрипта для клонирования более одного репо).

В этом случае библиотеку классов необходимо «добавить» в репозиторий git, но вы хотите поддерживать ее отдельно . В этом случае я обнаружил, что « git subtree » является хорошее решение. Однако здесь есть некоторая путаница.

Если вы загуглите "git subtree", вы получите 2 немного разных результата

  1. Рабочий процесс слияния поддеревьев GIT
  2. git поддерево

Теперь я приветствую разъяснения к этому ответу, но, как мне кажется, второе заменило первое, завершив его.

Лучшая статья, которую я нашел о том, как использовать git subtree, - это здесь, а также очень подробная статья о рабочем процессе слияния поддеревьев git здесь, они оба сравниваются с подмодулями git в соответствующих статьях, если вам интересно.

Краткое описание того, как я использую это сейчас

Чтобы добавить последнюю стабильную версию моей библиотеки классов в основной проект:

pullclasslibrary

Чтобы протолкнуть любые изменения, которые я внес в библиотеку классов в основном проекте:

pushclasslibrary

Как я туда попал

Примечание. Это может показаться устрашающим, но большая часть этого "настроена" и не занимает много времени.

Имейте два отдельных репозитория, например:

  • путь / к / mainproject / .git
  • путь / к / библиотеке классов / .git

Здесь цель состоит в том, чтобы "mainproject" содержал последний стабильный код из "classlibrary".

Cd в свой основной проект. например , "cd path / to / mainproject"

Придумайте простое в использовании "имя" ? 1 для своей библиотеки классов.

git remote add -f <a_remote_name> <your seperately maintained repo>

например ,

git remote add -f my_class_library path/to/classlibrary/.git

Теперь добавьте это как поддерево .

git subtree add --prefix <folder within main proj> <a_remote_name> <branch_in_class_library_you_want_to_track> --squash **?2**

например ,

git subtree add --prefix source/libraries/class_library my_class_library stable --squash 

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

git fetch <a_remote_name> <branch_in_class_library_you_want_to_track>

например ,

git fetch my_class_library stable

На этом этапе вы можете просто вытащить и нажать поддерево (библиотеку)

git subtree pull <folder within main proj> <a_remote_name> <branch_in_class_library_you_want_to_track> --squash
git subtree push <folder within main proj> <a_remote_name> <branch_in_class_library_you_want_to_track> --squash

Я лично установил псевдоним bash, потому что набирать его очень много:

например ,

alias pullclasslib="git subtree pull --prefix source/libraries/class_library my_class_library stable --squash"
alias pushclasslib="git subtree push --prefix source/libraries/class_library  my_class_library stable --squash"

Так я и попал :)

Я пропустил некоторые детали здесь, поэтому настоятельно рекомендую чтение первой статьи

< Сильного > Сноска :

?1 Итак, мы действительно создаем «удаленный», точно так же, как «origin» является удаленным, а «name» - это очень упрощенное упрощение. Git позволяет создавать столько пультов, сколько захотите, и, как выясняется, совершенно разные репозитории. По умолчанию для git pull обычно установлено значение git pull origin, где origin - это репозиторий git, который вы клонировали.

?2 --squash является необязательным, и его стоит прочитать отдельно, но грязное резюме - когда вы сливаетесь с --squash, вы сбрасываете история коммитов. Мое личное предпочтение - я не хочу, чтобы богатая история библиотеки классов была связана с моим основным репо, это не имело бы смысла для меня, самое большее, я хочу, чтобы одна фиксация говорила «извлеченная последняя версия библиотеки классов». Однако, если я обнаруживаю, что вносю изменения в библиотеку классов в основном репо, и я хочу вставить это в библиотеку классов, я действительно хочу вставить в нее историю. Однако в настоящее время я подумываю о том, чтобы раздавить это, а также, кажется, вытолкнуть всю историю фиксации для моего основного репо, что с точки зрения библиотеки классов не имеет смысла. Так что я бы, вероятно, придерживался предложения статей об использовании "сквоша" в двух направлениях.

< Сильный > - ОБНОВЛЕНИЕ -

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

Я обновил примеры для двунаправленного сжатия

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

1
chrispepper1989 12 Дек 2014 в 15:37

Лучше всего по возможности использовать отдельные репозитории git. Особенно, если вы хотите использовать CBI Tool, например Jenkins. Git-подмодули добавляют много сложности. Если вы новичок в git или около того, я настоятельно рекомендую не использовать подмодули.

1
mithrandir 4 Дек 2014 в 11:19