Когда использовать параметр слияния "--no-ff " в Git

Успешная Модель Ветвления Git рекомендует использовать --no-ff при слиянии веток:

на --no-ff флаг заставляет слияние всегда создавать новую фиксацию объект, даже если слияние может быть выполнено с перемоткой вперед. Этот позволяет избежать потери информации об историческом существовании объекта ветвь и группы вместе все коммиты, которые вместе добавили особенность. [...]

Да, он создаст еще несколько (пустой) объекты commit, но выигрыш гораздо больше затрат. К сожалению, я не нашел способа make --no-ff поведение по умолчанию git merge еще, но это действительно должно быть.

понимание рабочего процесса с Git, однако, рекомендует не использовать --no-ff:

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

на --no-ff лейкопластырь, разбитый bisect и blame тайны все симптомы того, что вы используете отвертку как молоток. [...]

оба подхода кажутся разумными для разных сценариев, но что считается " хорошей практикой?"

если вы используете --no-ff, когда вы этого не делаете, почему?

57
fast-forward git git-merge

3 ответов

Это действительно зависит от того, что ты пытаешься сделать. Мое эмпирическое правило заключается в том, что если слияние "что-то значит", я использую опцию --no-ff. Когда слияние не значит и можно использовать rebase и нет никаких причин, чтобы использовать опцию --no-ff в

дело в том, что git - это очень мощный инструмент, и вы можете использовать его многими способами - большинство из которых не ошибаются. Спрашивать, каков "правильный путь", это все равно, что спрашивать, Как правильно нарисовать изображение.

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

42

для случая готовой ветви с одной фиксацией не используйте --no-ff, просто перемотайте вперед, потому что история будет намного проще и менее загромождена. Трудно спорить, что --no-ff дает вам какие-либо преимущества в этом случае, потому что неинтересно видеть параллельную ветвь разработки только с одной фиксацией против одной фиксации в последовательной строке:

# No fast-forward
$ git merge --no-ff awesome-feature
*   3aa649c Merge branch 'awesome-feature'
|\
| * 35ec88f Add awesome feature
|/
* 89408de Modify feature-001.txt and fix-001.txt
* c1abcde Add feature-003

# versus fast-forward
$ git merge awesome-feature
* 35ec88f Add awesome feature
* 89408de Modify feature-001.txt and fix-001.txt
* c1abcde Add feature-003

для случая готовой ветви с более чем одной фиксацией, это зависит от вас, независимо от того, вы хотите сохранить тот факт, что разветвленная разработка происходила параллельно против последовательной. Я бы, вероятно, использовал --no-ff для более чем одного фиксации, просто чтобы я мог визуально видеть эту разветвленную работу, и чтобы я мог легко манипулировать ею с помощью одного git revert -m 1 <sha-of-merge-commit> если бы пришлось.

# No fast-forward
$ git merge --no-ff epic-feature
*   d676897 Merge branch 'epic-feature'
|\
| * ba40d93 Add octocat.txt
| * b09d343 Add bye.txt
| * 75e18c8 Add hello.txt
|/
* 89408de Modify feature-001.txt and fix-001.txt
* c1abcde Add feature-003

# versus fast-forward
$ git merge epic-feature
* ba40d93 Add octocat.txt
* b09d343 Add bye.txt
* 75e18c8 Add hello.txt
* 89408de Modify feature-001.txt and fix-001.txt
* c1abcde Add feature-003

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

42

это действительно зависит от вашего рабочего процесса и от того, как вы используете ветви.

допустим, у вас есть" Мастер "и две ветви функций," foo "и" bar", в разработке.

в этом случае ветви существуют только для того, чтобы позволить различным разработчикам работать без конфликтов, когда функции сделаны, они должны быть объединены в master, и не важно знать, были ли эти функции реализованы в разных ветвях.

но вы могли бы иметь другой рабочий процесс, были ветви, "foo" и "bar", относится к независимым модулям в вашей системе.

в этом случае, некоторые коммиты могут изменять файлы вне рамок модуля. Когда вы объединяете эти две ветви в master, журнал файлов за пределами конкретного модуля может стать запутанным и трудно узнать, откуда эти изменения.

вам нужно решить, является ли история слияния ветвей важной для вашего рабочего процесса.

и, следуя комментариям, я предпочитаю rebase и pull --rebase рабочего процесса.

2