Git fast forward VS без ускоренного слияния

Question

Git merge позволяет нам выполнять ускоренную перемотку вперед и без быстрой перемотки ветвления.Любые идеи, когда использовать ускоренное слияние вперед и когда не использовать ускоренное слияние?

Answer 1

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

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

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

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

Answer 2

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

Здесь опция --no-ff (т.е. true merge ) создает новый коммит с несколькими родителями и обеспечивает лучшее отслеживание истории. В противном случае --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. Это означает, что ускоренное слияние не всегда приемлемо.

Answer 3

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

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

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