Есть ли смысл в направлениях слияния между апстримом / темой / интеграцией в git? - PullRequest
2 голосов
/ 17 ноября 2009

Я читал статью Packaging Software, используя git , пока у меня не болят глаза, как я вижу по этому изображению , он рекомендует объединиться с upstream-> topic branch-> local ветка интеграции.

Меня особенно интересует сценарий, в котором существуют конфликты между вышестоящей ветвью и ветвью локальной интеграции. Если я вообще читаю статью правильно, она говорит, что если я объединю upstream-> локальную ветвь интеграции-> topic, у меня будут проблемы, если тема уже объединена с локальной ветвью интеграции ..?

В идеале я хотел бы объединиться в любом старом направлении, которое я нашел бы полезным, но мне кажется, что я готовлюсь к некоторым неприятностям, если я это сделаю? Моя голова также начинает болеть, когда я пытаюсь визуализировать коммиты на ветвях тем, переплетенных с коммитами из апстрима, в разном порядке на разных ветках. Кто-то должен сказать мне, что мне все равно.

В настоящее время мы объединяемся из апстрима с тем, что нам нравится, и я не уверен, является ли это оптимальным решением с точки зрения уменьшения конфликтов. Мне кажется, что git трудно отследить разумного общего предка, и я подозреваю, что мы вводим ситуации перекрестного слияния путем слияния таким образом? У нас, безусловно, есть значительная доля конфликтов, и мне кажется, что общий предок, которого я вижу в git mergetool, указывает на то, что (для меня) выглядит как очень плохой выбор (но, возможно, правильный). Следует ли избегать какого-либо порядка слияния и почему?

Я до сих пор не уверен, что понимаю и те подводные камни, которые они пытаются описать в этой статье ...

1 Ответ

3 голосов
/ 19 ноября 2009

Это классическая проблема с рабочим процессом слияния , осложненная коэффициентом публикации этого DVCS (как в «Распределенном»):

  • rebase обязателен, чтобы включить восходящие эволюции в вашу локальную ветку (и разрешить конфликт локально)
  • но переписывание истории ветки для нижестоящих пользователей - это большое нет-нет

Следовательно, дополнительные ветви (развивающиеся только через морг, без перебазирования) описаны в:

альтернативный текст http://www.golden -gryphon.com / software / misc / rebase_merge.png

В настоящее время мы объединяемся из апстрима с тем, что нам нравится

Как уже упоминалось в Git rebase против слияния

"rebase затем merge" может быть допустимым рабочим процессом, который сначала разрешает конфликт в изоляции, а затем возвращает вашу работу.

Как Линус сказал в своем комментарии :

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

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

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...