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

Question

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

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

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

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

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

---

Обновление # 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?

Answer 1

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

Предположим, я был на a2 на feature/a, в идеале я ожидал, что произойдет следующее: git rebase master, и диаграмма должна стать

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

git rebase fix/b, и диаграмма должна выглядеть так:

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 лучше всего быстро продолжить разработку функции / a, извлекая при этом выгоду от fix/b.

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

Answer 2

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

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

Answer 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