Git: регулярное слияние / перебазирование долгоживущих веток исправлений ошибок в master - PullRequest
3 голосов
/ 15 июля 2011

Контекст

Мы используем несколько репозиториев git с одним и тем же рабочим процессом, включающим две ветви, и задаемся вопросом, как лучше всего "синхронизировать" коммиты от одного к другому.

Проще говоря, нашрепозитории git содержат:

  • Долгоживущие ветки
  • Две ветви:
    • master (ветка для текущей разработки)
    • 1.0 (ветка только для исправлений, для поддержания стабильной версии)
  • Обе ветви регулярно отправляются в общедоступное хранилище
  • Иногда текущая разработка и исправления затрагивают одни и те же строки в одних и тех же файлах,конфликты возникают при слиянии / перебазировании / т. д.

У нас также есть несколько менее распространенных условий:

  • Необычное соотношение: различия в исправлениях (на ветке 1.0) намного большепо сравнению с текущими разработками (в основной ветке).
  • Иногда коммиты из ветки 1.0 выбираются вишней в основную ветку («срочные» исправления необходимы как для стабильных выпусков, так и для for development)

Мы могли бы проиллюстрировать это следующим образом (commit 5' - это виш-пиковый коммит 5 из ветви 1.0):

-1--2-3--5'--7-- (master)
     \
      4--5---6-- (1.0)

Цель

Время от времени нам нужно убедиться, что все исправления в ветке 1.0 доступны в основной ветке.

При этом нам нужны:

  • Ветвь 1.0 не должна изменяться (никакие коммиты от мастера не переходят на ветку 1.0)
  • Мастер должен оставаться совместимым с origin / master, чтобы мы могли продвигаться к удаленному репо.По сути, это означает, что нужно избегать переписывания истории мастера (если нет волшебного способа продвинуть это, о котором мы не знаем!)
  • Мы не хотим потерять историю коммитов: нам нужно иметь возможность увидеть,commit из ветки 1.0 был применен к основной ветке.
  • Мы бы предпочли не вручную разрешать конфликты, возникающие из предыдущих вишневых пиков, я думаю, что git должен быть способен решить это сам (какна страницах руководства).
  • В будущем мы снова столкнемся с подобной ситуацией, и нам нужно будет разрешить ее таким же образом, но мы не хотим помнить, какие разрешения использовать длякоммиты 4 и 6, которые мы уже разобрали один раз.

Итак, иллюстрация ситуации, к которой мы стремимся:

-1--2-3--5'--7--4'--6'-- (master)
     \
      4--5---6-- (1.0)

То, что мы попробовали

  • Использование копии ветви 1.0 и перебазирование ее на мастер:
    • Кажется, что работает
    • Но если мы сделаем то же самоеоперация снова в будущем, мы должны рассмотретьновые коммиты и старые
  • Перебазирование мастера на ветку 1.0
    • Работает в локальном репо
    • Но не может быть перенесено на удаленное, так какэто будет перезапись origin / master
  • Слияние ветки 1.0 в master
    • Все разрешения конфликтов заканчиваются в ОДНОМ единственном коммите, поэтому история не показывает фактические изменениятребуются предыдущие коммиты
    • В идеале нам нужен "git merge --interactive", похожий на "git rebase --interactive": объединяйте ветви, но в интерактивном режиме выбирайте, какие коммиты включать или нет, пока мы идем

Вопрос

Нам кажется, что это, вероятно, довольно типичный вариант использования для git или для тех, кто поддерживает и разрабатывает программное обеспечение в публичном git-репо,в любом случае.

Как бы вы поступили об этом?

Спасибо!

1 Ответ

3 голосов
/ 15 июля 2011

Существуют взлеты и падения во всех вариантах, и принятие взвешенного решения будет в значительной степени зависеть от прочтения всего, что вы можете найти. Самая большая проблема в том, что git не был спроектирован с нуля, чтобы поддерживать несколько «долгосрочных» веток, где вам может понадобиться сохранять изменения в ветке годами. Так что, вероятно, вы в конечном итоге столкнетесь с проблемами слияния, когда базы кода между ветвями будут значительно изменены.

Если вы читаете большинство документов рабочего процесса, одна из самых важных вещей, которую вы многократно читаете, это: «применять исправления к ветвям исправления ошибок и объединять их вверх», и никогда наоборот.

Вот то, что я придумал как решение, которое я придумал для нашего Net-SNMP проекта. Я написал страницу Git WorkFlow [в Net-SNMP] , которую вы можете прочитать, так как она содержит круги и стрелки, пытающиеся объяснить, как работают многие ветки с исправлениями ошибок.

Недостатком слияния является то, что история становится очень нелинейной. Что делает чтение «git log», независимо от того, сколько опций вы пытаетесь его добавить, сбивает с толку.

Один из наших разработчиков любезно отметил, что нам необходимо использовать 'git merge --log', который хотя бы немного помогает истории.

Удачи!

...