Я думал, что git тяга была как git выборка + git слияние.
Это так. Однако синтаксис, который используется с git pull, не совпадает с синтаксисом, который используется практически со всеми другими командами Git. Это связано с историей: git pull предшествует ряду улучшений, сделанных в Git между версиями до 1.5 и после 1.6 Git. (Обратите внимание, что Git сейчас находится в версии 2.26, так что это действительно древняя история, восходящая к 2005 году или около того. Самые старые версии Git, которые люди все еще используют сегодня, находятся в диапазоне версии 1.7, но когда вы беги git pull, ты возвращаешься к до-каменному веку, эпохе динозавров Git 1,5.)
[но] я пробовал git pull origin/master, и это не сработало [ while] git pull origin master сработало
Это потому, что это специальный синтаксис только для git pull.
Внимательно прочитайте git pull документацию для исключений (которых много), но в целом большинство аргументов, которые вы передаете git pull, git pull, передаются git fetch. Точно так же, как вы не запускаете:
git fetch origin/master # wrong
вы не можете запустить
git pull origin/master # also wrong: this runs git fetch origin/master
Однако вы можете запустить:
git fetch origin master
Здесь origin - это remote и master - это refspe c (см. git fetch документацию для получения дополнительной информации об удаленных устройствах и refspecs). Это конкретно ограничивает вашу git fetch операцию по извлечению только новых сообщений, которые находятся на их master, чтобы обновлять только ваш origin/master. 1
После завершения выборки pull запускает merge или, если вы укажете, rebase, для некоторого набора коммитов с ветвью. 2 Общая идея здесь - какая восходит к той истории до Git -1.6, о которой я упоминал, - это то, что, получив некоторые коммиты из какого-то другого Git, вы теперь с sh до включаете эти коммиты в свой текущая ветвь .
В начале Git было время, когда не существовало всей концепции remote , и, следовательно, не было удаленного отслеживания имена: вообще не было origin, следовательно, origin/master. Поэтому было важно немедленно включить их коммиты, чтобы ваш Git не запустил проход сбора мусора и не удалил новых полученных вами коммитов.
В эпоху после 1.6, т. Е. С тех пор, как 2006 или около того - было безопасно собирать коммиты и пусть они некоторое время сидят , пока вы их просматриваете, думаете о них или даже некоторое время полностью их игнорируете. remote name origin ввел remote-tracking имён, таких как origin/master, который сохраняет эти коммиты неопределенно долго. Больше не нужно безумно ценить эти коммиты в одну из своих веток, чтобы предотвратить их удаление.
Суть: Если вы находите git pull удобным, используйте его. Если нет, не надо. Помните, что аргументы, которые вы будете использовать, если вы используете аргументы, являются уникальными для него. Это просто комбинация git fetch плюс немедленная вторая команда для включения некоторых извлеченных коммитов в current филиал. Я нахожу это в - удобным, в большинстве случаев: мне нравится проверять извлеченные коммиты первыми. Если вы не используете git pull, вы будете называть входящие коммиты именами удаленного отслеживания, такими как origin/master, но если вы используете git pull, вы не сможете использовать эти имена в самой команде git pull, потому что она совместима с древними временами, когда эти имена не существовали.
1 Этот тип git fetch обновит ваш origin/master в любой современной Git, но в Git версиях до 1.8.4 он не обновит origin/master.
2 Выбранные коммиты в качестве аргументов для слияния или перебазирования используются те из ссылок, которые вы специально назвали в командной строке, если вы назвали их. В противном случае (одиночный) коммит, выбранный в качестве аргумента, является тем, который соответствует настройке upstream текущей ветви.
В некоторых угловых случаях git pull запускает что-то кроме слияния или перебазировки в качестве второй команды. Наиболее интересным из этих особых случаев является включение в совершенно пустой репозиторий: здесь ни git merge, ни git rebase ничего не сделают, поэтому git pull по сути просто вместо этого запускает git checkout. Этот особый случай, очевидно, происходит только один раз в любом данном хранилище.