Git pull с rebase, вызывающий чрезмерные конфликты.Как я могу исправить наш рабочий процесс? - PullRequest
Новая
       29

Git pull с rebase, вызывающий чрезмерные конфликты.Как я могу исправить наш рабочий процесс?

5 голосов
/ 20 августа 2010

У нас есть базовая система, настроенная для каждого клиента. База живет в своем собственном хранилище, и каждый клиент живет в своем собственном хранилище (первоначально клонировано из базы).

Цель состоит в том, чтобы иметь возможность добавлять исправления / функции ошибок в базу, которые могут быть распространены среди клиентов по требованию.

Пока рабочий процесс был следующим:

  • Создание коммитов / веток тем для базовых исправлений / функций: (на базе, мастер) git commit -m "Fix admin typo"
  • Объединить эти изменения с клиентом: (на клиенте, мастер) git merge base/master. Очевидно, это включает в себя исправление любых конфликтов между базой и настройками клиента.
  • Нажмите слияние с источником клиента: (на клиенте, мастер) git push origin master
  • Наше соглашение состояло в том, чтобы тянуть с rebase (чтобы история читалась). Итак, тогда другой разработчик, работающий над клиентским проектом, будет (на клиенте, мастере) git pull --rebase origin master

Именно в этот момент мы достигаем значительных проблем с этим извлечением / перебазированием. Разработчики получают конфликты при извлечении / перебазировании после слияния базы с клиентом. И это не просто несколько конфликтов, это много (для многих коммитов, которые воспроизводятся?), И часто код, который конкретный разработчик даже не коснулся. Я думаю, что это неразумно и неустойчиво.

Какое здесь лучшее решение?

Моя единственная мысль - перестать использовать rebase при извлечении и иметь дело с неаккуратными и трудно читаемыми журналами, но я бы предпочел этого не делать. Эти клиентские проекты могут продолжаться годами, и я хотел бы иметь возможность еще разглядеть слияния базовых систем в будущем.

1 Ответ

3 голосов
/ 21 августа 2010

Позвольте мне получить это прямо на ваших репо:

  1. основной проект отдельный, называется base
  2. каждый клиентский проект клонируется из base, только получение обновлений
  3. разработчики работают из публичного client_foo репо и push / pull в / из этого

Рабочий процесс завершается сбоем, потому что один разработчик перебрасывает ветку client_foo на новые коммиты из репо base и возвращает обратно к client_foo. Это в конечном итоге сломает всех остальных разработчиков, использующих client_foo, когда они попытаются сделать следующий шаг. Так что вы не можете этого сделать и ожидаете, что git автоматически с этим справится.

Если бы это был всего один разработчик на клиентское репо, то, возможно, это сработало бы. Я предполагаю, что это не так.

Параметры:

  1. Продолжайте делать то же, что и вы, но когда разработчик выталкивает перебазированную ветку client_foo (с новыми base коммитами) обратно в публичное репо client_foo, все остальные должны сделать reset --hard на origin/master. Если они хранят все свои невыпущенные изменения в закрытой ветке тем, они должны rebase вернуть их на новый client_foo/master.

  2. Ваш dev merge изменится с base на client_foo. Это даст вам коммит слияния на client_foo, который, как вы сказали, вы пытаетесь избежать, но даст вам наиболее точную историю. Когда ваши разработчики выполняют команду «pull --rebase», вы больше не должны получать длинный список конфликтов, которые у вас сейчас есть.

  3. У вашего разработчика cherrypick изменения с base на client_foo. Это сохраняет вашу историю линейной, но git больше не будет отслеживать, что коммиты cherrypick были получены от base. Вам придется придумать другой способ отследить его.

Я бы сказал, придерживайтесь # 2, потому что именно так должен работать git. Однако кто-то может подумать о лучшем неочевидном решении.

...