Git ускоренная перемотка вперед VS без быстрого слияния вперед

Ответ 1

Опция --no-ff полезна, когда вы хотите иметь четкое представление о вашей ветки функций. Таким образом, даже если в это время не было сделано никаких коммитов, FF возможен - вы все равно иногда хотите, чтобы каждый коммит в основной строке соответствовал одной функции. Таким образом, вы рассматриваете функциональную ветвь с кучей коммитов как один блок и объединяете их как один блок. Из вашей истории становится ясно, когда вы объединяете ветку объектов с --no-ff.

Если вас не волнует такая вещь - вы, возможно, сойдете с ФФ, когда это возможно. Таким образом, у вас будет больше svn-подобного ощущения рабочего процесса.

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

Рассмотрим ситуацию, когда ряд второстепенных коммитов в ветки "feature" вместе составляют одну новую функцию: если вы просто выполните "git merge feature_branch" без --no-ff, "из истории Git невозможно увидеть, какой из коммитов Объекты вместе реализовали функцию - вам нужно будет вручную прочитать все сообщения журнала. Возврат всей функции (то есть группы фиксаций) является настоящей головной болью [если --no-ff не используется], тогда как это легко сделать, если флаг --no-ff был использован [потому что это всего один коммит]. "

Ответ 2

Я могу привести пример, который обычно можно увидеть в проекте.

Здесь опция --no-ff (т.е. истинное слияние) создает новый коммит с несколькими родителями и обеспечивает лучшее отслеживание истории. В противном случае --ff (т.е. ускоренное слияние) по умолчанию.

$ git checkout master
$ git checkout -b newFeature
$ ...
$ git commit -m 'work from day 1'
$ ...
$ git commit -m 'work from day 2'
$ ...
$ git commit -m 'finish the feature'
$ git checkout master
$ git merge --no-ff newFeature -m 'add new feature'
$ git log
// something like below
commit 'add new feature'         // => commit created at merge with proper message
commit 'finish the feature'
commit 'work from day 2'
commit 'work from day 1'
$ gitk                           // => see details with graph

$ git checkout -b anotherFeature        // => create a new branch (*)
$ ...
$ git commit -m 'work from day 3'
$ ...
$ git commit -m 'work from day 4'
$ ...
$ git commit -m 'finish another feature'
$ git checkout master
$ git merge anotherFeature       // --ff is by default, message will be ignored
$ git log
// something like below
commit 'work from day 4'
commit 'work from day 3'
commit 'add new feature'
commit 'finish the feature'
commit ...
$ gitk                           // => see details with graph

(*) Обратите внимание, что здесь, если ветвь newFeature используется повторно, вместо того, чтобы создавать новую ветвь, git все равно должен будет выполнить слияние --no-ff. Это означает, что ускоренное слияние не всегда приемлемо.

Ответ 3

Когда мы работаем над средой разработки и сливаем наш код в промежуточную/производственную ветвь, тогда Git no fast forward не может быть лучшим вариантом. Обычно, когда мы работаем в ветке разработки для одной функции, мы склонны иметь несколько коммитов. Отслеживание изменений с несколькими коммитами может быть неудобным в дальнейшем. Если мы сливаемся с промежуточной/производственной веткой, используя Git без ускоренной перемотки, то у нее будет только 1 коммит. Теперь в любое время мы хотим отменить функцию, просто отменить эту фиксацию. Жизнь проста.

Ответ 4

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

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

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