Как мне настроить промежуточное хранилище в git?

Question

Я хочу создать хранилище [B], которое отслеживает мастер удаленного хранилища [A] в ветви с именем x_master. Его собственный мастер также должен быть клоном в начальное время создания, в которое другие [Devs] могут клонировать и вносить изменения.

Время от времени, когда в A происходят изменения, мне нужно иметь возможность вытащить их вниз и объединить их с x_master B (который, если я понимаю, должен быть ускоренным, поскольку они будут единственными изменениями ветвь x_master на B), а затем сможет объединить эти изменения с хозяином B и, таким образом, с любым, кто клонирует хозяина B, когда они потянут.

Что я концептуально хочу, так это:

master      x_master
 [A] <---------> [B] <-------> [Dev2]
                  ^-------> [Dev1]
                  master

В конце концов мне нужно будет передать изменения в мастере B до мастера A, когда все разработчики будут сделаны, но в A будут происходить изменения, которые необходимо объединить в B

• Как мне это настроить?
• Как мне толкать и тянуть из B в и из A?
• Имеет ли эта настройка смысл?

Я пробовал все виды клонов --mirror, branch --track, и, похоже, просто не получаются изменения в толчках и толчках A и B.

Answer 1

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

$ cd repo_B
$ git init --bare
$ git remote add upstream URL_FOR_REPO_A
$ git fetch upstream +master:refs/heads/x_master
$ git branch master x_master

При изменении вышестоящего репозитория эти изменения нужно перенести в пустой репозиторий ¹ :

$ git fetch upstream +master:refs/heads/x_master

Это перезапишет ² любые возможные изменения в x_master, поэтому вам лучше оставить эту ветку в покое.:)

Вы захотите объединить восходящие изменения в x_master в master, когда / если A изменится.К сожалению, на этой стадии могут возникнуть конфликты, поэтому это должно быть сделано с помощью клона нашего открытого хранилища.Просто клонируйте репозиторий B (в локальное или удаленное местоположение) и объедините x_master в master, разрешите конфликты и вернитесь назад.

И последняя задача - продвижение разработки, выполненной в master в хранилище А. Это можно сделать двумя способами.Во-первых, это непосредственное перемещение мастера B в хранилище A. Это можно сделать, выполнив:

$ git push upstream

в хранилище B. Альтернативой является более контролируемое слияние от master до x_master с использованием третьегорепозиторий:

$ git clone URL_FOR_REPO_A
$ cd repoDir
$ git remote add dev URL_FOR_REPO_B
$ git fetch dev
$ git branch --track master_b dev/master
$ git merge master_b
$ <resolve conflicts, if any>
$ git push origin master

---

Примечание 1

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

$ git configure branch.upstream.fetch +master:refs/heads/x_master

И с помощью --add, вы можете даже добавить больше веток для извлечения:

$ git configure --add branch.upstream.fetch +branch_1_0:refs/heads/x_branch_1_0

Теперь выборка будет работать правильно без ссылок:

$ git fetch upstream

---

Примечание 2

Чтобы предотвратить толчки к master из repo_B, вы можете использовать ловушку на стороне сервера , например pre-receive или update.

Answer 2

Я был вдохновлен, но также несколько смущен ответом Вальлака. Я думаю, что что-то более простое может работать так же хорошо ...

mkdir (name).staging.git ; cd (name).staging.git
git init --bare
git remote add origin (remote-repo)

Периодически (в том числе изначально) вы будете получать изменения и обновлять локальные ветви ...

git fetch
for remote in $(git branch -r) ; do git branch --force --no-track $(basename $remote) $remote ; done

Обратите внимание, что необходимо обновлять локальные ветки каждый раз, когда вы выбираете, в противном случае репо третьего уровня не увидит изменения в восходящем потоке. Мой пример обновляет все локальные ветки, но вместо этого вы можете сделать это вручную только для интересующих отраслей. Я предлагаю создать псевдоним "git staging-fetch", который объединяет эти две строки в одну команду.

Перенос из промежуточного репозитория в главный репозиторий является простым, если не требуется слияние (просто выполняйте обычное перетаскивание). Если принудительное завершение не удается из-за конфликтов, вам необходимо получить обновления через оба уровня и решить проблемы в рабочем хранилище.

---

Примечание: эта схема не требует ветки с именем "x_master". Git имеет встроенную поддержку для использования локальной ветви для теневой удаленной ветви. Таким образом, все «главные» ветви просто называются «основными», но при обращении к ветви в ближайшем исходном хранилище вы бы назвали ее «origin / master» или «staging / master» в зависимости от обстоятельств.

branch:       origin master    staging master    working master
              =============    ==============    ==============
origin sees:  master
staging sees: origin/master    master
working sees:                  staging/master    master

Answer 3

Я полагаю, что и A, и B являются открытыми репозиториями, используемыми только для проталкивания и вытягивания, верно?

Я бы сказал, что самым простым способом было бы просто иметь промежуточное хранилище между A и B. То есть не пустое хранилище с рабочим деревом. Таким образом, вы можете тянуть и сливаться с любой из ветвей в А и В в полном покое и изоляции от всех остальных, настраивать слияния до тех пор, пока вы не будете полностью довольны ими, а затем подтолкнуть их к одной из А и В .

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

Answer 4

Лучшим способом было бы иметь одного ответственного разработчика (назовите его dev0), который будет заниматься всем этим. У него должен быть доступ на чтение и запись к A. Он может установить A в качестве удаленного в своем локальном репо и поддерживать B / x_master, передавая коммиты из A / master своему локальному x_master и передавая его в B. Как вы упомянули, это должно будь легким и всегда ускоренным. (Так что это может быть написано в сценарии)

Поскольку B / x_master также виден всем разработчикам, любой может объединить (и увидеть / исправить конфликты) x_master с мастером, когда они почувствуют необходимость интегрировать его в разработку.

Когда разработка будет завершена, dev0 объединит мастер с x_master. Во всяком случае, это требует контроля человека из-за возможных конфликтов. У него также есть шанс отменить слияние в этот момент и выполнить дополнительные коммиты, чтобы отразить разрешение конфликтов в вашей ветке разработки. Так что вы также можете обсудить их в группе. Когда это будет сделано, dev0 может снова попытаться объединить master с x_master. После этого x_master перемещается в A / master.