Дублированные коммиты могут быть из-за перебазирования из нескольких источников

Чтобы разработать функцию, я создал ветку функции (названную feature/a).

Во время разработки feature/a я обнаружил, что существует существующая ошибка, поэтому я создаю ветку ошибок (называемую fix/b) на основе master.

После исправления и фиксации этой ошибки я снова проверил feature/a и запустил git rebase origin/master. Но поскольку это зависит от fix/b, я запустил git rebase origin/fix/b. Во время обоих ребейсов я исправил некоторые конфликты.

Затем я продолжил работу над feature/a, после того, как я закончил feature/a, прямо перед тем, как запросить pull request, я понял, что было много дублированных коммитов. Почему дублируется много коммитов? Я подумал, что это может быть, потому что я перебазировал из смешанных источников, но я попытался воспроизвести локально, но не получилось.

Еще вопросы, какова в этом случае правильная стратегия? У кого-нибудь есть мысли?


Обновление # 1

Извините, я забыл упомянуть, на тот момент fix/b еще не слился с master. Итак, ситуация больше похожа на следующую:

master --> m1 --> m2
 |\
 | \
 |  feature/a --> a1 --> a2
 |
fix/b --> b1 --> b2

Предположим, я был на a2 на feature/a, в идеале я ожидал, что произойдет следующее: * git rebase master, а диаграмма должна выглядеть так: -> m1 -> m2 -> a1 -> a2 * git rebase fix/b, а диаграмма должна выглядеть так: -> m1 -> m2 -> b1 -> b2 -> a1 -> a2

Однако в моем случае диаграмма больше похожа на приведенную ниже: -> m1 -> m2 -> b1 -> b2 -> m1 -> m2 -> b1 -> b2 -> a1 -> a2

Я не мог воспроизвести в моем локальном репозитории git.

На самом деле мой вопрос: если есть две ветви (A и B), обе не объединены с master, и одна зависит от другой (branch A зависит от branch B). В этом случае, чтобы продолжить разработку branch A, должен ли я выполнить перебазирование с master и branch B?

Вы должны нет запустить git rebase origin/fix/b. Если предположить, что вы действительно зафиксировали исправление ошибки непосредственно в master, тогда git rebase origin/master должен был внести это исправление в feature/a. Думаю, это источник вашей проблемы.

Tim Biegeleisen 26.10.2018 06:19

Извините, я забыл упомянуть, что после того, как я исправил fix/b, я запрашиваю запрос на перенос, но требуется время, чтобы выполнить слияние с мастером, то есть на данный момент fix/b еще не слился с master.

Ron 26.10.2018 11:32

Это не сильно меняет мой комментарий. Думаю, вам не следовало делать перебаз дважды.

Tim Biegeleisen 26.10.2018 11:33
1
3
282
3

Ответы 3

Всякий раз, когда вы выполняете перебазирование, создаются новые коммиты в целевой ветви (feature/a), из ветвей перебазирования (origin/master) и (origin/fix/b). Поскольку origin/master уже имеет коммиты origin/fix/b, вы видите дублирующиеся коммиты в своей целевой ветке feature/a, когда вы перебазируете с origin/master.

Что вам следовало сделать, так это то, что вы должны были рассматривать origin/master как общую ветвь для всех ваших слияний / ребазов. Итак, после слияния fix/b с origin/master вы должны просто переустановить origin/master на целевую ветку feature/a.

Если вы хотите сохранить историю, вам следует пойти на слияние. Если вам нужна более чистая история, сделайте перебазирование. В любом случае вы должны просто оставить origin/master в качестве общей ветки, а rebase/merge из origin/master в своей ветке. здесь это feature/a.

git checkout feature/a
git merge origin/master #if you are fond of merge, to keep history accurately
git rebase origin/master #if you are fond of rebase, to keep history cleaner

Спасибо за ваш вклад. На самом деле я только что понял, что не упомянул, что fix/b еще не слился с master. Я обновил свой вопрос, не могли бы вы взглянуть, спасибо.

Ron 26.10.2018 11:56

Давайте посмотрим на вашу последовательность перебазирования, потому что аналогичные коммиты не должны перебазироваться дважды, учитывая механизм идентификатора патча.
Это означает, что вы не должны повторять m1 / m2 дважды. И все же вы их видите.

Supposing I was at a2 on feature/a, Ideally I expected the following will happen: git rebase master, and the diagram should become

     (master)
 m1 --> m2 --> a1' --> a2' (feature/a)
   \
     -> b1 --> b2 (fix/b)

git rebase fix/b, and the diagram should become:

m1 --> m2 --> b1 --> b2 --> a1 --> a2

Ну ... нет: вы воспроизводите функцию / a (которая теперь включает коммиты master) поверх fix/b, но master все еще существует.

 m1 --> m2 (master)
   \
     -> b1 --> b2 --> m1' --> m2' --> a1'' --> a2'' (feature/a)

Отсюда повторение m1 / m2.

Как правило, коммиты из master не следует перебазировать.

Простое слияние fix/b с feature/a лучше всего для быстрого продолжения разработки функции / а, одновременно извлекая выгоду из fix/b.

     (master)
 m1 --> m2 --> a1' --> a2' --> M (feature/a)
   \                          /
     -> b1 ----------------> b2 (fix/b)

Я думаю, что это вопрос ответ очень хорошо объясняет.

В основном, последний шаг, мы должны git push --force-with-lease. Если мы сделаем git push, он будет генерировать дублированные коммиты.

Другие вопросы по теме