Git pull/fetch с различиями refspec

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

git fetch origin master:mymaster

и из

git pull origin master:mymaster

Обе вышеприведенные команды, похоже, дают точно такой же результат - это локальная ветвь с именем mymaster, такая же, как origin/master. Я прав или есть неопределенное различие между этими двумя?

Наконец, использование refspec создаст локальную ветвь не ветки отслеживания, правильно? Поскольку ветки отслеживания автоматически выдвигаются, когда вы вызываете git push без каких-либо аргументов AFAIK

ОТВЕТЫ

Ответ 1

Параметр refspec является только исходной/целевой. Использование refspec x:y с fetch сообщает git сделать ветку в этом репо с именем "y", которая является копией ветки с именем "x" в удаленном репо. Больше ничего.

С pull, git выдает слияние сверху. Во-первых, выборка выполняется с использованием заданного refspec, а затем ветвь назначения объединяется в текущую ветку. Если это смущает, здесь шаг за шагом:

git pull origin master:mymaster
  • Перейдите в начало и получите "master" в ветке
  • Сделайте копию локально с именем "mymaster"
  • Объединить "mymaster" в текущую ветвь

Полностью квалифицированный, который будет refs/heads/mymaster и refs/heads/master. Для сравнения, refspec по умолчанию, установленный git на клоне, +refs/heads/*:refs/remotes/origin/*. refs/remotes делает удобное пространство имен для ветки отдельных ветвей от локальных. То, что вы делаете, сообщает git разместить ветку удаленного отслеживания в том же пространстве имен, что и ваши локальные ветки.

Что касается "ветвей отслеживания", это просто запись в вашем файле конфигурации, сообщающая git, куда потянуть и поместить локальную ветвь в/из по умолчанию.

Ответ 2

git fetch origin master:mymaster обновляет ветвь mymaster в локальном репозитории путем выбора из главной ветки удаленного репозитория.

git pull origin master:mymaster делает выше и объединяет его в текущую ветвь.

Ответ 3

мастер происхождения git fetch: mymaster

Однако команда должна строго соответствовать следующим двум условиям:

  1. Местная текущая ветвь не может быть mymaster.

  2. Местный филиал mymaster является предком происхождения /master.

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

Если оба вышеуказанных условия выполняются, выполните команду:

мастер происхождения git pull: мой мастер

В дополнение к выполнению команды:

мастер происхождения git fetch: mymaster

Также выполню ：

git merge FETCH_HEAD.

Обратите внимание: не Git Merge Mymaster

FETCH_HEAD отличается от mymaster ，, потому что mymaster, возможно, уже слился с ускоренной перемоткой вперед.

Ответ 4

Я использовал smartgit для создания ветки, так что, возможно, в этой ветке не было должным образом объединено в master. Созданная ветвь поддержки для выпуска, т.е. Поддержка /4.2, тег автоматически создается, но теперь, когда я пытаюсь сделать git pull, он показывает мне ту же ошибку. Поскольку поддержка /4.2 brannch создается в github, но не правильно объединена в локальном. Поэтому я использовал это: git pull origin master: mymaster

В моем случае - git поддержка источника происхождения /4.2: поддержка/4.2

Он работает:)