Ускоренная перемотка вперед при использовании pull и no-ff при слиянии ветки

В моем рабочем процессе у меня много короткоживущих ветвей, и я хотел бы, чтобы они были отделены друг от друга. Итак, я планирую использовать git config --add merge.ff false. Тем не менее, когда я делаю pull (я понимаю, это fetch + merge), то мне нужно быстрое переключение, чтобы избежать ненужного дополнительного коммита.

Это хорошая вещь? Возможно ли это?

Ответ 1

Примечание: Git 2.0 (Q2 2014) будет представлен с commit b814da8 a config push.ff:

pull.ff::

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

Когда установлено значение false, эта переменная сообщает Git создать дополнительное слияние в таком случае (что эквивалентно предоставлению опции -no-ff из командной строки).

Если установлено только значение, допускаются только такие быстрые слияния (эквивалентно предоставлению опции --ff-only из командной строки).

Первоначальный ответ (октябрь 2012 г.)

Попробуйте:

git pull --ff

Он должен иметь приоритет в настройке конфигурации слияния.
Он передаст параметр --ff в основное слияние в команде Git pull.

Остерегайтесь опции --no-ff, хотя, как указано в " Понимание Git Workflow"

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

Рассмотрим, как общий рабочий процесс Git разваливается.

Create a branch off Master, 
do work, 
and merge it back into Master when you’re done

В большинстве случаев это ведет себя так, как вы ожидаете, потому что Мастер изменился с тех пор, как вы разветвлялись. Затем в один прекрасный день вы объединяете ветвь функции в Master, но Master не расходится. Вместо создания фиксации слияния, Git указывает Мастер на последнюю фиксацию в ветки функции или "быстрая перемотка вперед". (Схема)

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

Итак, вы добавляете новое правило: "Когда вы объединяетесь в ветки вашей функции, используйте –no-ff для принудительного создания нового коммита". Это выполняет свою работу, и вы двигаетесь дальше.

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

Вы сокращаете ошибку до одного файла. Вы запустите blame, чтобы узнать, как он изменился за последние 48 часов. Вы знаете его невозможное, но blame сообщает, что файл не был затронут в течение нескольких недель.
Оказывается, blame изменяет отчеты за время первоначальной фиксации, а не при объединении. Ваша первая контрольная точка зафиксировала этот файл несколько недель назад, но изменение было снесено сегодня.

Ментальная помощь no-ff, разбитая биссект и таинственность вины - все это симптомы, которые вы используете отверткой в качестве молотка.

Подробнее см.