Git: разница между git fetch и git pull

Начинающему программисту или даже многим опытным программистам может быть сложно изучить и освоить контроль версий Git. На мой взгляд, во многом причина кроется в существовании множества различных команд и небольших различиях между ними. Одним из таких примеров является разница между git fetch и git pull. На первый взгляд, названия команд не дают большого представления о том, чем они отличаются, поэтому в этой статье я объясню разницу между git fetch и git pull comman.

Начинающему программисту или даже многим опытным программистам может быть сложно изучить и освоить контроль версий Git. На мой взгляд, во многом причина кроется в существовании множества различных команд и небольших различиях между ними.

Одним из таких примеров является разница между git fetch и git pull . На первый взгляд, названия команд не дают большого представления о том, чем они отличаются, поэтому в этой статье я объясню разницу между командами git fetch и git pull

Git Fetch

Команда fetch извлекает любые коммиты, ссылки (например, теги), ветки и файлы из удаленного репозитория вместе с любыми другими соответствующими объектами. Однако не все теги извлекаются, поскольку эта команда принимает только те, которые указывают на извлекаемые вами коммиты. По сути, эта команда извлекает все, что необходимо для восстановления истории конкретной интересующей вас ветки.

Базовый синтаксис следующий:

 $ git fetch <remote-repo> <remote-branch> 

Если указать <remote-branch> будут получены изменения только из этой ветки. Если этот параметр опущен, будут получены изменения из всех ветвей.

Что интересно в fetch это то, что она на самом деле ни на что не влияет в вашем локальном репо. Никакие рабочие изменения не будут потеряны, и вы не увидите прямого влияния на ваши локальные филиалы. Это связано с тем, что Git хранит извлеченный контент отдельно от контента вашего собственного репо, пока он не будет объединен.

Итак, предположим, вы хотите просмотреть изменения для «главной» ветки из удаленного репо «origin», прежде чем принять решение об объединении их в свое репо. Для этого вы можете использовать следующие команды:

 $ git fetch origin master 

Теперь, когда у вас есть изменения в вашем репозитории, вы, вероятно, захотите их просмотреть, что вы можете сделать, просто проверив ветку:

 $ git checkout origin/master 

Это позволит вам увидеть изменения, и они по-прежнему не объединены ни в одну из ваших собственных веток.

Более быстрый способ просмотреть эти изменения - просто просмотреть журналы фиксации, что вы можете сделать с помощью:

 $ git log master..origin/master 

Обратите внимание, что это считается «более безопасным» методом, чем pull поскольку он фактически не вносит никаких изменений в ваши локальные ветки.

Теперь, когда мы увидели, что fetch , и немного о том, как это работает, давайте взглянем на pull .

Git Pull

git pull я бы назвал командой «высокого уровня». Под этим я подразумеваю, что он последовательно выполняет действия нескольких других команд Git, о которых я расскажу подробнее ниже. В этом разделе, после того как я опишу разницу между fetch и pull , я также кратко расскажу о многочисленных различных способах использования команды.

Общий синтаксис следующий:

 $ git pull <remote-repo> <remote-branch> 

Оба параметра <remote-repo> и <remote-branch> являются необязательными, если ваша текущая ветвь отслеживает удаленную.

Вероятно, самый простой способ объяснить эту команду и то, чем она отличается от fetch , состоит в том, что это псевдоним для двух других команд Git при использовании в режиме по умолчанию: fetch и merge . Итак, запустив git pull вы, по сути, выполняете эти две команды последовательно:

 $ git fetch <remote-repo> 
 $ git merge FETCH_HEAD 

Здесь FETCH_HEAD - это ссылка на подсказку последней выборки, которая объединяется с вашей текущей веткой.

Таким образом, очевидно, что большая разница между fetch и pull заключается в том, что pull фактически выполняет fetch помимо merge .

Хотя в зависимости от параметра, который вы даете git pull , он может работать иначе. Например, если вы добавите параметр --rebase вместо git merge будет использоваться git rebase .

Существует также --no-commit вариант, который будет выполнять merge команды, но (как указано в официальной документации) «делает вид , что слияние не удалось» , а не Autocommit его. Это позволяет вам взглянуть на изменения, которые вы только что выбрали, прежде чем фактически зафиксировать их в своем коде.

Доступно еще несколько вариантов, большинство из которых выходит за рамки этой статьи. Я бы рекомендовал взглянуть на официальную документацию для получения дополнительной информации.

Licensed under CC BY-NC-SA 4.0
comments powered by Disqus

Содержание