Объединение из восходящей ветви в ветвь поставщика, где ветвь поставщика содержит подмножество восходящих коммитов - PullRequest
4 голосов
/ 06 мая 2011

Я работаю с поставщиком, который предоставляет набор патчей для ядра Linux, чтобы поддерживать Android поверх своей платформы. Это означает, что они основывают свою строку патчей на определенной версии Linux, а в их строку патчей включены некоторые из патчей для Android (предположительно, выбранным cherry), которые применяются к той же версии Linux.

Итак, история выглядит примерно так при импорте в git вместе с нашими изменениями, которые применяются сверху:

     v2.6.x.y                          v_rel_x.y      o_rel_z
l--l--l---------v--v--a--v--a--a--v--v--v--------o--o--o

Где l - это коммиты linux, v - коммиты от вендоров, a - коммиты Android, а o - наши коммиты.

Что делает это сложным, так это то, что исходный код ядра Android Git, основанный на той же версии ядра Linux, совершенно отдельный, выглядит так:

     v2.6.x.y      v2.6.x.y+1
l--l--l---------l---l
       \             \           android-2.6.x
        \             a--a--a--a--a
         \
          \                       v_rel_x.y      o_rel_z
           v--v--a--v--a--a--v--v--v--------o--o--o

Теперь я хочу включить все выпуски android в выпуск android-2.6.x, однако я также хочу, чтобы все исправления вендоров поддерживали их платформу. К сожалению, довольно много изменений в наборе изменений v2.6.x.y+1..android-2.6.x уже применены к ветви v_rel_x.y. Таким образом, простое слияние с android-2.6.x на o_rel_z создает огромное количество конфликтов, которые просто невозможно решить вручную.

Есть ли у вас какие-либо идеи о том, как надежно выполнить слияние с android-2.6.x на o_rel_z?

И да, в каждой ветви действительно огромное количество коммитов, и патчи для Android на v_rel_x.y полностью запутаны патчами вендоров.

1 Ответ

0 голосов
/ 06 мая 2011

Мои два цента:

  1. Причина конфликта не в том, что некоторые вишни коммитов выбраны, а в том, что некоторые коммиты меняют одни и те же файлы в одних и тех же местах, а git не можетпримените diff аккуратно.
  2. В случае противоречивых изменений у вас не так много вариантов: а) вы объединяете и разрешаете конфликты, чтобы привести код в желаемое состояние; б) вы пытаетесь разрешить конфликты автоматически путем объединения, используя стратегии объединения, такие как--ours или --theirs, в зависимости от того, что вы считаете более правильным для ваших целей.

См. здесь Документация по Git merge

Другой подход, который вы можете попробовать, -чтобы перебазировать вашу ветку 0_rel_z поверх обновленной версии android-2.6.x

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

Надеюсь, это поможет!

...