В моем рабочем процессе у меня много короткоживущих ветвей, и я хотел бы, чтобы они были отделены друг от друга. Итак, я планирую использовать git config --add merge.ff false. Тем не менее, когда я делаю pull (я понимаю, это fetch + merge), то мне нужно быстрое переключение, чтобы избежать ненужного дополнительного коммита.
Это хорошая вещь? Возможно ли это?
Примечание: 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, разбитая биссект и таинственность вины - все это симптомы, которые вы используете отверткой в качестве молотка.
Подробнее см.