Быстрое слияние имеет смысл для кратковременных ветвей, но в более сложной истории слияние без быстрой перемотки может облегчить понимание истории и упростить возврат группы коммитов.
Предупреждение : не ускоренная пересылка также имеет потенциальные побочные эффекты. Пожалуйста, просмотрите https://sandofsky.com/blog/git-workflow.html , избегайте «no-ff» с его «фиксацией контрольной точки», которые нарушают пополам или обвиняют, и тщательно продумайте, должен ли это быть подход по умолчанию master.
(От nvie.com , Винсент Дриссен , пост " Успешная модель ветвления Git ")
Включение готовой функции по разработке
Готовые функции могут быть объединены в ветку разработки, чтобы добавить их в следующий выпуск:
$ git checkout develop
Switched to branch 'develop'
$ git merge --no-ff myfeature
Updating ea1b82a..05e9557
(Summary of changes)
$ git branch -d myfeature
Deleted branch myfeature (was 05e9557).
$ git push origin develop
--no-ffФлаг вызывает слияние всегда создавать новый объект коммита, даже если слияние может быть выполнена с быстрой перемотки вперед. Это позволяет избежать потери информации об историческом существовании ветви компонента и объединяет все коммиты, которые вместе добавляли функцию.
Якуб Narębski также упоминает о конфигурацииmerge.ff :
По умолчанию Git не создает дополнительный коммит слияния при слиянии коммита, который является потомком текущего коммита. Вместо этого верхушка текущей ветви быстро пересылается.
Когда falseэта переменная установлена в , эта переменная указывает Git создать дополнительный коммит слияния в таком случае (эквивалентно предоставлению --no-ffопции из командной строки).
Если установлено значение ' only', разрешено только такое ускоренное слияние (эквивалентно предоставлению --ff-onlyопции из командной строки).
Быстрая перемотка вперед по умолчанию, потому что:
- недолговечные ветки очень легко создавать и использовать в Git
- краткосрочные ветви часто изолируют много коммитов, которые могут быть свободно реорганизованы в пределах этой ветви
- эти коммиты фактически являются частью основной ветви: после реорганизации основная ветвь быстро пересылается для их включения.
Но если вы ожидаете итеративный рабочий процесс в одной теме / ветви функций (т. Е. Я объединяю, затем я возвращаюсь к этой ветви функций и добавляю еще несколько коммитов), тогда полезно включать только объединение в основную ветку, а не все промежуточные коммиты ветви функций.
В этом случае вы можете в конечном итоге установить этот тип файла конфигурации :
[branch "master"]
# This is the list of cmdline options that should be added to git-merge
# when I merge commits into the master branch.
# The option --no-commit instructs git not to commit the merge
# by default. This allows me to do some final adjustment to the commit log
# message before it gets commited. I often use this to add extra info to
# the merge message or rewrite my local branch names in the commit message
# to branch names that are more understandable to the casual reader of the git log.
# Option --no-ff instructs git to always record a merge commit, even if
# the branch being merged into can be fast-forwarded. This is often the
# case when you create a short-lived topic branch which tracks master, do
# some changes on the topic branch and then merge the changes into the
# master which remained unchanged while you were doing your work on the
# topic branch. In this case the master branch can be fast-forwarded (that
# is the tip of the master branch can be updated to point to the tip of
# the topic branch) and this is what git does by default. With --no-ff
# option set, git creates a real merge commit which records the fact that
# another branch was merged. I find this easier to understand and read in
# the log.
mergeoptions = --no-commit --no-ff
ОП добавляет в комментариях:
Я вижу некоторый смысл в перемотке вперед для [недолговечных] ветвей, но если сделать это действием по умолчанию, это означает, что git предполагает, что вы ... часто имеете [недолговечные] ветви. Разумно?
Джефроми отвечает:
Я думаю, что время жизни веток сильно варьируется от пользователя к пользователю. Однако среди опытных пользователей, вероятно, наблюдается тенденция к появлению гораздо более кратковременных веток.
Для меня короткоживущая ветвь - это ветвь, которую я создаю, чтобы упростить определенную операцию (перебазирование, скорее всего, или быстрое исправление и тестирование), а затем сразу же удалить, как только я закончу.
Это означает, что он, вероятно, должен быть включен в ветку темы, из которой он был разветвлен , и ветка темы будет объединена в одну ветку. Никто не должен знать, что я сделал внутри, чтобы создать серию коммитов, реализующих данную функцию.
В целом, я добавляю:
это действительно зависит от вашего рабочего процесса разработки :
- если он линейный, имеет смысл одна ветвь.
- Если вам нужно изолировать функции и работать с ними в течение длительного периода времени и многократно объединять их, имеет смысл использовать несколько веток.
Смотрите " Когда вы должны перейти? "
На самом деле, когда вы рассматриваете модель веток Mercurial, в ее основе лежит одна ветвь на репозиторий (даже если вы можете создавать анонимные заголовки, закладки и даже именованные ветки ).
См. «Git and Mercurial - Сравнение и контраст» .
Mercurial, по умолчанию, использует анонимные легкие кодовые строки, которые в его терминологии называются «заголовками».
Git использует легкие именованные ветви с инъективным отображением для отображения имен ветвей в удаленном репозитории на имена ветвей удаленного отслеживания.
Git «вынуждает» вас называть ветви (ну, за исключением одной неназванной ветви, которая называется « отсоединенный HEAD »), но я думаю, что это лучше работает с тяжелыми ветвями, такими как тема веток, то есть несколько ветвей в одной парадигме хранилища.
no-ff' с его " фиксацией контрольной точки", которая нарушает пополам или обвинение.