Обновление общего раздвоенного репозитория с помощью git

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

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

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

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

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

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

Как я должен действовать, чтобы избежать каких-либо проблем?

1 14
github gitlab git-fork

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 объединяет эти ветви ТРО. Как правило, это именно правильный способ решить эту проблему.

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

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

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

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

7