рабочий процесс git: одноразовые слияния и git-rerere - какой смысл?

Question

Как и большинство новичков в Git, у меня возникла путаница, когда я пытался расшифровать варианты использования, применимые к git merge и git rebase. Я думаю, что наконец-то решил, что в отношении конечного состояния рабочей копии они дают вам то же самое. Кроме того, они оба приводят к одним и тем же конфликтам. Если это неверно, приведите пример, чтобы просветить меня.

С моей точки зрения, основным преимуществом использования rebase вместо слияния (если ваши изменения не были перенесены или извлечены) является сохранение истории линейной. Что я действительно не понимаю, так это причины разработки git-rerere.

Из справочных страниц git-rerere должен помочь вам в том случае, если вы пытаетесь разрешить конфликт, который вы ранее разрешили. Пример, на который я собираюсь ссылаться, находится по адресу http://www.kernel.org/pub/software/scm/git/docs/git-rerere.html.

Если политика вашего проекта состоит в том, чтобы постоянно не объединять изменения из основной линии в ветку вашей темы (например, ядро ​​linux), в приведенном выше примере говорится о создании «одноразовых» коммитов слияния. По сути, объедините мастер с вашей темой, запустите тесты, чтобы убедиться, что все по-прежнему работает, затем выполните «git reset --hard HEAD ^», по сути, отбросив коммит слияния. Позже, когда вы создадите еще один «одноразовый» коммит слияния, git-rerere поможет вам разрешить конфликты, которые вы уже разрешили в первом одноразовом слиянии.

Может кто-нибудь объяснить, почему вместо того, чтобы пройти через все трудности создания временного коммита слияния, разработчик вместо этого не просто перенесет свою тему на master? Не в этом ли смысл git-rebase - получить изменения, но избежать слияния? Разве это не делает то же самое, и, предполагая, что никто не потянул ваши изменения в ветке темы, разве это не был бы намного более простой подход? Является ли рабочий процесс throw-away-merge + git-rerere действительно только для случая, когда ваши изменения были перенесены / извлечены?

Последний вопрос - про Линуса говорят: «Но если я увижу много« веток слияния веток »в ваших журналах, я не собираюсь от вас отрываться, потому что у вашего дерева, очевидно, была случайная чушь, что не должно быть там ... "У Линуса также были бы проблемы с постоянными ребазами?

Answer 1

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

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

Например, у вас может быть исправление, которое относится к техническому выпуску, а также к текущему выпуску;Вы хотели бы отделить его от последнего коммита, который является предком обоих выпусков.Вы никогда не сможете перебросить эту ветку вперед вдоль главной ветки или ветки обслуживания, или вы больше не сможете объединить ее с другой.

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

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

Ваш последний вопрос на самом деле о чем-то совершенно ином, никак не связанном с конфликтами слияния.Линус сказал, что в контексте слияний, которые не нужно было делать .Это очень важный вопрос философии ветвления и слияния.Джунио Хамано написал превосходное сообщение в блоге об этой самой проблеме.Краткая цитата, подытоживающая данную тему:

Когда вы объединяете ветку темы 'add-frotz' с вашей веткой 'master', вы, очевидно, включаете новую функцию 'frotz', ночто еще более важно, вы заявляете, что желательно иметь эту функцию 'frotz' в ветке 'master'

Линус не хочет видеть, как вы объединяете эту странную ветку под названием 'linus' всевремя, потому что, очевидно, вы не объединяете какую-то конкретную тему, которую желательно иметь в вашей ветке.Вы постоянно объединяете ветку upstream с веткой theme, что совершенно неверно.Вам не нужны все вещи от мастера (или Линус), чтобы развить свою тему.Вы должны закончить свою тему, а затем объединить ее в обратном направлении с мастером!Не желательно иметь все содержимое мастера в вашей ветке тем.(А для одного интегратора это действительно тематическая ветка, поскольку это касается интегратора.)

Итак, у Линуса нет проблем с частыми слияниями;у него проблема с бесцельными и контрпродуктивными слияниями.(И вообще, если вы убедитесь, что ваши слияния сделаны по уважительной причине, они не будут частыми - и они почти никогда не будут слияниями вниз по течению.) Если ваши ребазы сделаны по уважительной причине, и они делают историюлучше, тогда они хорошие, хотя и частые.

Answer 2

Разве это не делает то же самое, и, предполагая, что никто не потянул изменения вашей ветки темы, разве это не был бы намного более простой подход?Является ли рабочий процесс throw-throw-merge + git-rerere действительно только для случая, когда ваши изменения были сдвинуты / вытянуты?

Вы ударили ногтем по голове.Перебазировка хороша для веток, которые вы еще не опубликовали;rerere полезно для опубликованных вами веток (т. Е. Веток, для которых перебазирование было бы неуместным / раздражающим для разработчиков нижестоящих версий).

Будет ли у Линуса также проблема с постоянными ребазами?

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

Answer 3

Ветвь

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

Rerere, хотя и поможет значительно облегчить повторяющуюся боль слияния.