Git передать общий подмодуль (главная ветвь)

У меня есть два или более проектов (пусть их называют ProjectFoo и ProjectBar), имеющих некоторый общий код, который я помещал в подмодуль.

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

(master) $ cd ProjectFooBarCommoneSubmodule/
(master) $ git commit -am "Common code fix."
(56f21fb0...) $ git push
Everything up-to-date

Возможно, потому, что ветвь master не изменилась. Возможно, я мог бы сделать что-то вроде git checkout master && git merge Everything up-to-date, но это кажется довольно уродливым. Может быть, git reset --hard master будет делать то же самое, но кажется еще более уродливым.

Как получить общий код, совместно используемый проектом, обновленный из тех проектов, которые его используют? Другими словами, фиксация этого подмодуля должна обновлять все различные репозитории (репозитории, а не только клоны), которые используют этот же подмодуль.

---- EDIT ----

Видимо мой изъятый репозиторий был испорчен и сломан. Это должно было с самого начала работать (в ProjectFoo в этом примере):

(master) $ cd ProjectFooBarCommoneSubmodule/
(master) $ git commit -am "Common code fix."
(master) $ git push
....
   fbfdd71..0acce63  master -> master
(master) $ cd ..
(master) $ git add ProjectFooBarCommoneSubmodule
(master) $ git commit -m "Submodule update."

Затем, чтобы получить это изменение в других проектах, например ProjectBar:

(master) $ cd ProjectFooBarCommoneSubmodule/
(master) $ git pull

Будет обновлен последний распространенный код. A git checkout master может потребоваться, если он находится на отдельной голове.

Ответ 1

Короткий ответ:

cd ProjectFooBarCommoneSubmodule
git checkout master
<Do your editing>
git commit --all -m "Lots of fixes"
git push submodule_origin master
cd ..

git add ProjectFooBarCommoneSubmodule
git commit -m "Bumped up the revision of ProjectFooBarCommoneSubmodule"
git push origin master

Чем длиннее:

Подмодули

Git - это механизм зависимости, где основной проект (скажем, A) определяет указанную ревизию в подпроекте (скажем, B), который будет использоваться при построении проекта A. Для того чтобы инструмент был полезным, поведение должно быть предсказуемым с точки зрения A: s. Зависимости не могут измениться, если кто-то не решит включить изменение в проект A. Могут произойти всевозможные неприятные вещи: автоматически ли импортировались изменения проекта B: s, из которых ошибки компиляции, вероятно, являются лучшими, поскольку A незамедлительно заметил бы сбои. Вот почему головка B: s находится в отключенном состоянии.

Состояние B хранится в (проверьте git submodule status), и изменение изменения должно быть выполнено и зафиксировано в A, чтобы оно имело какой-либо эффект. Это то, что происходит в приведенном выше примере, A изменяет номер ревизии, хранящийся в репо, и набирает версию до последней. Этот процесс необходимо будет повторить и в другом основном репо, поэтому автоматическое "использование мастер-переключателя" AFAIK.

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

Оба ProjectFoo и ProjectBar совместно используют код в общем подмодуле.

ProjectFooBarCommoneSubmodule: master 6850e4e4c1fac49de398

В ProjectFoo:

git submodule status

-6850e4e4c1fac49de39890703f21486ca04b87a0 общий

В ProjectBar:

git submodule status

-6850e4e4c1fac49de39890703f21486ca04b87a0 общий

Итак, оба указывают на ту же ревизию, верно? Трюк здесь заключается в том, чтобы увидеть, что ProjectFoo и ProjectBar указывают на версию (6850e4e4c1fac49de39890703f21486ca04b87a0) не ветвь (мастер), хотя они - одно и то же. Первая - отдельная голова, а другая - именованная ветка.

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

git checkout master 
<Do your coding and pushing here>

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

git submodule status

+ e24bd2bf45d52171a63b67ac05cd4be0ac965f60 общий (heads/master-1-ge24bd2b)

Теперь вы можете сделать git add, чтобы установить ссылку на эту конкретную фиксацию (ge24bd...), выполнить фиксацию, и после этого ссылка на подмодуль указывает на эту ревизию, которая также является мастером на ProjectFooBarCommoneSubmodule.

Теперь вам нужно обновить ссылку в ProjectBar. Перейдите в ProjectBar/common и выполните git fetch origin (это быстрое слияние вперед), do

git checkout master 
cd ..
git add common
git commit -m "Bumped up the revision"
git push origin master # to publish the revision bump to everybody else

Итак, как и в любом репозитории git, вам не нужно работать с отдельной головой. Вы можете либо работать с мастером, либо создать именованную ветку. В любом случае, убедитесь, что вверх по потоку содержит изменения ProjectFooBarCommoneSubmodule, или вы сломаете ProjectFoo и ProjectBar, если они ссылаются на то, что не существует. Надеюсь, это объяснило это лучше.

Ответ 2

На submodule: git push origin HEAD:master

Ответ 3

Если вы хотите зафиксировать и подтолкнуть все подмодули сразу: git submodule foreach 'git commit -a' ; git submodule foreach 'git push --all' ; git commit -a && \ git push --all --recurse-submodules=on-demand

Ответ 4

Чтобы объединить изменения из отдельной HEAD в master, запустите:

git rebase HEAD master

затем мастер проверки (используйте -f для силы):

git checkout master

Если у вас есть несколько подмодулей для работы, используйте: git submodule foreach, например.

git submodule foreach git pull origin master -r

Ответ 5

Я просто делаю:

git submodule foreach git push -u origin master