Обновите общий forked-репозиторий с помощью git

Рассмотрим репозиторий. Репозиторий github, который управляется через Gerrit. Я клонировал репозиторий A, и я создал новую ветку, начиная с основной ветки репозитория A. Я нажал эту новую ветку на новый репозиторий gitlab B. Я являюсь администратором репозитория B, и я поделился им с другими разработчиками. Разработчики не могут продвигать эту ветку, но я могу объединить их запросы на вытягивание. Я объединил несколько запросов на загрузку в главной ветке репозитория B. Таким образом, в репозитории B есть первоначальные фиксации репозитория A и новые коммиты запроса на вытягивание: B совершает над A фиксации (b a).

Затем я хочу обновить репозиторий B новыми коммитами репозитория A. Вызов этих коммитов a +.

Я вижу два варианта:

  • Если я объединю A на B, результатом будет: a + b a.
  • Если я переустанавливаю B на A +, результаты: b a + a.

Вариант 1: события совершаются смешаны с внешними. Трудно отлаживать и выделять различия.

Вариант 2: мне нужно наложить силу на пульт B. Последствия, если я не ошибаюсь, могут быть:  1. Если разработчики вытащит B и они совершают локальный хозяин B, они потеряют свои локальные изменения;  2. Разработчики могут столкнуться с большими проблемами во время восстановления своих локальных ветвей после принудительного обновления ветки B.

Как мне избежать любых проблем?

ОТВЕТЫ

Ответ 1

Если я правильно понимаю, у вас есть единственный (локальный) репозиторий, который выглядит примерно так:

            A/master
               ↓
* -- * -- * -- a
                \
                 * -- * -- b
                           ↑
                       B/mybranch

Теперь обновляется A, поэтому он выглядит так:

                          A/master
                              ↓
* -- * -- * -- a -- * -- * -- a+
                \
                 * -- * -- b
                           ↑
                       B/mybranch

Обратите внимание, что у вас есть две расходящиеся ветки, которые не имеют прямой линии. Так что вы говорите, что получите a+ b a, когда вы объедините A на B, неверно. Вы получаете слияние, но это сохраняет историю как есть:

                          A/master
                              ↓
* -- * -- * -- a -- * -- * -- a+
                \               \
                 * -- * -- b --- M
                                 ↑
                            B/mybranch

Как вы можете видеть, у вас все еще есть информация, откуда взялись коммиты: те, что были между A и a+, поступали из одной ветки, а другие между A и B поступали от другой. И M объединяет те ветки tro. Обычно это как раз правильный способ решить эту проблему.

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

Таким образом, слияние, безусловно, лучше работать здесь. Да, история не будет выглядеть такой же совершенной, как прямая линия, но она правильно передает то, что произошло: существует разрозненная линия разработки, которая является независимой и затем была обновлена ​​с изменениями из восходящего репозитория A. Эта информация может быть полезна и, как таковая, имеет смысл удержать их. И особенно если у вас есть пользователи, взаимодействующие с обоими пультами, они определенно предпочтут поддерживать совместимость своего репозитория с обоими пультами.

Если вы не хотите, чтобы история выглядела так и не заботилась о совместимости с A, вы также могли бы скворовать все изменения с A на ваш B:

                          A/master
                              ↓
* -- * -- * -- a -- * -- * -- a+
                \
                 * -- * -- b -- [A]
                                 ↑
                            B/mybranch

Здесь [A] - сжатый коммит, содержащий все изменения между A и a+ в одном коммите. Вы можете получить этот результат, перезарядив A на B, в то время как раздавить все коммиты. В этом случае вы должны четко указать, где эти изменения происходят из сообщения фиксации.