Различия между командами "git pull" при извлечении из источника?

Ответ 1

git pull - это команда удобства, которая выполняет разные действия одновременно. В основном это всего лишь комбинация git fetch, которая подключается к удаленному репозиторию и извлекает новые коммиты, а git merge (или git rebase), который включает новые коммиты в вашу локальную ветвь. Из-за двух разных команд значение git pull не всегда очевидно.

Вы можете настроить восходящий поток для локальной ветки. После свежего клона у вас будет локальная ветвь "master", удаленное "происхождение", а ваша главная ветвь имеет "источник/мастер" как вверх по течению. Я предполагаю эту установку ниже. (Вы можете увидеть свою конфигурацию восходящего потока с помощью git branch -vv или просмотрев файл .git/config.)

Теперь для ваших вопросов:

• git pull= git fetch origin + git merge origin/master (или независимо от того, что у вас есть)
• git pull origin= git pull (пока источник - это ваш восходящий пульт)
• git pull origin master= git fetch origin master + git merge FETCH_HEAD
• git pull origin/master: недействительный, если у вас нет удаленного имени "origin/master"
• git pull origin HEAD:master: Пытается непосредственно reset локальному хозяину, независимо от того, на что указывает HEAD, о происхождении. (Не делайте этого.)

Ответ 2

A pull - это в основном fetch (который получает некоторые коммиты и связанные объекты из удаленного репозитория в ваш), а затем операцию, которая "применяет" их в вашу рабочую копию. Второй этап, по умолчанию, выполняется с помощью merge, но вы можете установить переменную pull.rebase в true, а затем вместо нее будет rebase.

Есть два вопроса, которые появляются с помощью команды pull. Во-первых, что именно получает? И второе: как это применимо к моей рабочей копии? Начнем с первого. Полная форма команды

git pull [options] [repository] [<refspec>...]

options - это флаги, которые управляют поведением (например, --rebase, чтобы сделать pull работать как fetch + rebase, даже если pull.rebase есть false).

repository - имя (или URL) пульта для извлечения.

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

Сначала возьмем наиболее явный вид.

 git pull origin branch1:branch2

Это в основном говорит, вытащите изменения в ссылке branch1 на удаленном телефоне под названием origin, а затем слейте (или переустановите) их в локальную ветвь branch2. Если я, например, скажу git pull origin master:dev, я получу локальную ветвь с именем dev, которая будет указывать на то же сообщение, что и master. Подробности о том, как указать refspecs, здесь. Вы можете использовать * для обозначения нескольких refspec. Например, git pull origin refs/heads/*:refs/heads/* вытащит все ветки (сохраненные в heads) в локальный репозиторий и объединит их в локальные ветки с одинаковыми именами.

Теперь давайте удалим аргументы один за другим, чтобы обсудить, как работает по умолчанию. Во-первых, мы можем удалить пункт назначения из нашего refspec и просто сказать git pull origin branch1. Сначала будет fetch удаленная ветвь branch1 в ваш локальный репозиторий. Он будет доступен как временная ссылка под названием FETCH_HEAD. После этого он запустит git merge FETCH_HEAD, который объединит эту ветвь в вашу текущую активную ветвь (т.е. HEAD). Это часто делается, когда вы находитесь в локальной ветке и хотите получать изменения с удаленного в эту ветку.

Теперь оставьте branch1 полностью и просто скажите git pull origin. Теперь git знает, где взять из (origin), но не знает, что выбрать. Для этого есть некоторые значения по умолчанию. Самый сценарий - это когда ваш файл конфигурации имеет параметр branch.<name>.merge (это запись с именем merge внутри раздела типа [branch "master"]). Если это так, он будет использовать refspecs для операции.

Если мы полностью опустим origin и просто скажем git pull, он проверит конфигурацию, чтобы увидеть, есть ли branch.<name>.remote, который указывает, с какого пульта вывести. Это вместе с вышесказанным говорит вам, что тянуть.

Ваши баллы №4 и №5 не являются нормальными вариантами использования. Первое имеет смысл, если у вас есть удаленный вызов origin/master, что маловероятно. origin/master обычно является локальной ссылкой, которая отслеживает ветвь master на пульте дистанционного управления origin. Второй попытается получить изменения на HEAD на удаленном сервере (ветвь по умолчанию, которая обычно master), а затем объединить их в локальный master. Хотя это может быть что-то, что вы хотите делать на регулярной основе, команда довольно нетрадиционная, а не то, что я часто использовал.

Я пропустил несколько деталей, но их должно быть достаточно, чтобы вы были в безопасности и комфорте в своей повседневной работе. Для всех деталей gory вы можете проверить страницу руководства для git pull.