Хотя я думаю, что это будет относительно редкий случай использования, для которого это лучший способ поделиться кодом, давайте посмотрим, что для этого потребуется.
Если вы хотите, чтобы репозиторий Template подталкивал измененияна репо App1, затем в Template необходимо настроить App1 как удаленный.
/repos/template $ git remote add App1 url/of/app1/repo
Тогда Template аналогичен любому локальному репозиторию, способствующему App1.Это означает, что каждый раз, когда вы создаете новое репо приложения на основе шаблона, вам нужно будет добавить его в качестве другого пульта в репо Template.Также обратите внимание, что git push взаимодействует только с одним пультом за раз, поэтому вы, вероятно, захотите собрать скрипт для отправки обновлений во все репозитории приложений.
(В качестве отступления это выглядит задом наперед -и я думаю, что вам было бы лучше сделать Template удаленным для каждого репо приложения и настроить каждое репо приложения на отслеживание, а pull изменить с Template. Это просто выглядит как более дружественный к git способделать то, что вы пытаетесь сделать - и это отразится на сложностях, так как мы продолжим описывать, как на самом деле будет работать процесс push. Но если вам нужен процесс push, то Template «вносит свой вклад» в каждое приложениеРепо, рассматривая репозитории приложений как удаленные, является способом сделать это.)
Теперь дело в том, что push не может выполнять слияния.Таким образом, вам необходимо, чтобы в каждом репо приложения была ветвь, которая только продвигается, когда Template проталкивается к ней, и тогда кому-то еще придется включить эти изменения в ветку (и), используемые для локальных изменений.в приложение.Когда вы переходите от Template к репозиториям приложений, вам необходимо убедиться, что вы вносите новые изменения в ветки шаблонов репозиториев приложений.
По правде говоря, вам, вероятно, лучше иметьтакая ветка, независимо от того, используете ли вы механизм push - или pull.Разница лишь в том, как обновляется ветка Template.Но если вы используете модель, основанную на извлечении, то каждый репо будет отвечать за восходящую связь своей отдельной ветви шаблона с репо шаблона, а не за репо шаблона (и / или выданные ему команды push), поддерживающие все шаблонных связей ветви.
Во всяком случае, тогда в App у вас будет что-то вроде
T0 <--(template)
\
A -- B <--(master)
Через некоторое время в репо Template вы вносите некоторые изменения, и вы push эти измененияApp s template ответвление
T0 -- T1 <--(template)
\
A -- B <--(master)
и тогда кому-то придется объединить template в master и разрешить любые возникающие конфликты.
T0 ------ T1 <--(template)
\ \
A -- B -- M <--(master)
И это может повторитьсяпо мере необходимости.Конечно, если у вас есть несколько веток в репозитории приложения, вам нужно выяснить, как распространять новые изменения шаблона на каждую из них.Это может стать довольно утомительным, если в каждой из них нужно разрешить множество веток и конфликтов (хотя, возможно, вы могли бы использовать git rerere, чтобы сделать его менее хлопотным).Вот почему я думаю, что вместо схемы, основанной на push - или pull, поиск способа разделения общего кода и использование вашей системы сборки для обработки его в качестве зависимости может помочь вам лучше, если это целесообразно длятип общего кода, с которым вы имеете дело.