git pull, git fetch и rebase: как подтягивать изменения и не ломать историю

В Git команды git pull, git fetch и git pull –rebase на первый взгляд делают одно и то же — помогают подтянуть изменения из удалённого репозитория. Но работают они по разному. Если использовать эти команды бездумно, можно поломать историю проекта и усложнить работу коллег.

В этой статье разберёмся, что это за команды, как они работают и когда что использовать.

Что делает git fetch

Команда git fetch нужна, когда мы хотим посмотреть изменения из удалённого репозитория, но не уверены, что готовы применять их к рабочей ветке.

Представим ситуацию, мы пишем код для интернет-магазина, наш коллега обновил часть, отвечающую за корзину и залил изменения на удалённый репозиторий в ветку main. Мы тоже работаем с корзиной в локальной ветке.

Перед тем как применить правки от коллеги к нашей рабочей ветке, нужно убедиться, что в коде и истории изменений нет конфликтов. Для этого нужен git fetch.

Эта команда:

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

С её помощью можно проверить изменения и только потом, если всё в порядке, применить их.

Что такое origin и локальная ветка отслеживания origin/<branch>

При клонировании удалённого репозитория Git создаёт короткое имя (алиас) по которому может к этому репозиторию обращаться. Если мы сами ничего не меняем в настройках, то это имя по умолчанию origin:

[remote "origin"]
    url = https://github.com/<username>-byte/online-store.git
    fetch = +refs/heads/*:refs/remotes/origin/*

Благодаря origin нам не надо прописывать полный адрес репозитория в командах, мы можем просто написать git fetch origin.

Это же имя используется в локальных ветках отслеживания, куда Git заносит данные об истории изменений. Оно указывается как origin/<branch>. Branch — название конкретной ветки. Например, если мы отслеживаем изменения с удалённой ветки main, то данные об истории будут записываться в ветку для отслеживания origin/main.

Ветки отслеживания только хранят данные об изменениях и сами по себе не применяют их к рабочим веткам. Это позволяет изолировать изменения и проверять их перед применением.

git fetch origin — синтаксис и опции

У git fetch можно выделить как минимум 3 варианта аргументов для вызова.

git fetch без аргументов. Git подтягивает информацию о новых коммитах с удалённого репозитория, по умолчанию использует origin, как имя и адрес этого репозитория.

Пример команды:

PS> git fetch
remote: Enumerating objects: 7, done.
remote: Counting objects: 100% (7/7), done.
remote: Compressing objects: 100% (2/2), done.
remote: Total 4 (delta 2), reused 4 (delta 2), pack-reused 0 (from 0)
Unpacking objects: 100% (4/4), 448 bytes | 12.00 KiB/s, done.
From https://github.com/<username>-byte/online-store
 67d079d..9e1861a  main       -> origin/main

В этом примере стоит обратить внимание на последнюю строку. Запись 67d079d..9e1861a main -> origin/main означает, что раньше в ветке отслеживания коммит 67d079d считался последним.

После команды fetch Git нашёл новый коммит 9e1861a на удалённом репозитории и добавил информацию о нём в origin/main, теперь он является последним коммитом.

git fetch origin. Иногда в проекте может быть несколько удалённых репозиториев. В таком случае, чтобы обратиться к одному конкретному, например, origin, можно явно указать его имя в команде.

Пример команды:

PS> git fetch origin
From https://github.com/<username>-byte/online-store
  67d079d..9e1861a  main       -> origin/main

Здесь Git как и в первом примере находит данные об изменениях удалённого репозитория, который привязан к имени origin и обновляет информацию в локальной ветке отслеживания origin/main. Разница с предыдущей командой только в том, что мы явно указали имя origin.

git fetch origin <branch>. Эта команда нужна, когда надо собрать данные об изменениях по одной конкретной ветке, а не всему репозиторию. Например, команда git fetch origin main будет подтягивать изменения только из ветки main.

Пример команды:

PS> git fetch origin main
From https://github.com/<username>-byte/online-store
* branch            main       -> FETCH_HEAD
  67d079d..9e1861a  main       -> origin/main

Здесь Git получил изменения из удалённой ветки main и пометил их записью * branch main -> FETCH_HEAD. Она означает, что новые данные сохранены в специальной ссылке FETCH_HEAD и готовы к слиянию.

Если кратко:

Команда	Что делает
git fetch	Получает данные о новых коммитах из удалённого репозитория по умолчанию. Обычно это origin.
git fetch origin	Явно обращается к удалённому репозиторию с именем origin. Полезно, если в проекте несколько удалённых репозиториев.
git fetch origin <branch>	Получает данные только по одной ветке. Например, git fetch origin main загрузит новые данные из удалённой main.

Как проверить изменения после fetch

После того, как git fetch собрал информацию об изменениях, мы можем проверить новые коммиты и, если всё в порядке, добавить их в нашу рабочую ветку. В этом помогут команды: git log и git diff.

git log HEAD..origin/main

git log HEAD..origin/main показывает новые коммиты, которые Git добавил в ветку отслеживания, но ещё не применил к нашей рабочей ветке.

Посмотрим на составные части команды:

Пример вывода после использования команды:

PS> git log HEAD..origin/main
commit 9e1861aa8b754aa203708f520d9748c15484f086 (origin/main, origin/HEAD)
Author: online-store demo <demo@online-store.local>
Date:   Fri Jun 26 09:46:00 2026 +0300
 
   исправил расчёт суммы корзины после скидки

В этом примере команда показала один новый коммит, его автора, дату создания и комментарий от коллеги. Он уже есть в origin/main, но ещё не попал в нашу рабочую ветку HEAD. Это значит, что git fetch обновил ветку отслеживания, но не изменил код в рабочей ветке.

git diff HEAD..origin/main

Для просмотра изменений можно воспользоваться командой git diff. С её помощью мы можем проверить отличия между разными строками кода.

Эта команда устроена похожим образом, как и git log HEAD..origin/main:

Пример вывода после использования команды:

PS> git diff HEAD..origin/main
diff --git a/src/cart.js b/src/cart.js
index 113cc81..bf229a5 100644
--- a/src/cart.js
+++ b/src/cart.js
@@ -5,9 +5,8 @@
// задаём текст кнопки для добавления товара в корзину
let buttonText = 'Добавить в корзину';
 
-// считаем сумму товаров в корзине
-// сохраняем цену товара как итоговую сумму
+// считаем сумму товаров в корзине с учётом скидки
function getCartTotal(price, discount) {
-  const total = price;
+  const total = price - discount;
  return total;
}

В выводе Git показывает файл, в котором нашёл изменения: 

diff --git a/src/cart.js b/src/cart.js

a/src/cart.js — старая версия файла, из нашей текущей ветки.

b/src/cart.js — новая версия файла, из origin/main.

--- a/src/cart.js
+++ b/src/cart.js

Координаты изменённого фрагмента в файле:

@@ -5,9 +5,8 @@

Часть кода, которая идёт перед этим фрагментом:

// задаём текст кнопки для добавления товара в корзину
let buttonText = 'Добавить в корзину';

Код в файле, который был изменён:

-// считаем сумму товаров в корзине
-// сохраняем цену товара как итоговую сумму
+// считаем сумму товаров в корзине с учётом скидки
function getCartTotal(price, discount) {
-  const total = price;
+  const total = price - discount;

Минус означает, что строка есть в нашей рабочей ветке, но изменилась в удалённом репозитории и в origin/main. Строки с плюсом — правки от коллег, которых нет в нашем коде.

Часть кода, которая не изменилась, но идёт после отредактированного фрагмента:

  return total;
}

Так при помощи git fetch и git diff мы можем быстро сравнить историю изменений и проверить код внутри конкретных файлов.

Что делает git pull

Команда git pull нужна, чтобы забрать изменения из удалённого репозитория и добавить их в проект. В отличие от fetch, она не просто показывает новые коммиты, а сразу пытается применить их к рабочей ветке.

git pull — что происходит пошагово

git pull включает в себя команды git fetch + git merge. Во время выполнения Git:

Если в истории веток есть расхождения, то Git создаёт общий коммит в локальной ветке, он называется merge-коммитом и объединяет в себе изменения из разных коммитов.

Допустим в локальной ветке есть коммит D, в удалённом репозитории появился коммит C. Чтобы слить изменения git pull выполнит команду merge и объединит изменения из C и D в коммит M.

Если расхождений нет, есть только новый коммит, то git pull добавляет его в рабочую ветку и сохраняет единую, линейную историю. 

Предположим, в локальной ветке были коммиты A и B. В общем репозитории появился коммит C. Так как история не расходилась, git pull не станет создавать merge-коммит а просто добавит коммит C в локальную ветку:

В выводе это будет выглядеть так:

PS> git pull origin main
From https://github.com/<username>-byte/online-store
* branch            main       -> FETCH_HEAD
  67d079d..9e1861a  main       -> origin/main
Updating 67d079d..9e1861a
Fast-forward
src/cart.js | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)

Этот вывод можно разделить на две части. 

Часть первая с fetch:

From https://github.com/<username>-byte/online-store
* branch            main       -> FETCH_HEAD
  67d079d..9e1861a  main       -> origin/main

Часть вторая с merge:

Updating 67d079d..9e1861a
Fast-forward
src/cart.js | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)

Конфликты при git pull и как их решать

Иногда команда git pull заканчивается конфликтами, если в разных версиях кода при слиянии есть противоречащие друг другу правки:

PS> git pull origin main
From https://github.com/<username>-byte/online-store
* branch            main       -> FETCH_HEAD
  67d079d..9e1861a  main       -> origin/main
Auto-merging src/cart.js
CONFLICT (content): Merge conflict in src/cart.js
Automatic merge failed; fix conflicts and then commit the result.

В этом примере конфликт случился внутри файла src/cart.js.

Чтобы узнать подробности, можно выполнить команду git status. Она показывает текущее состояние репозитория и даёт подсказки, что можно делать дальше:

PS> git status
On branch main
Your branch and 'origin/main' have diverged,
and have 1 and 1 different commits each, respectively.
 (use "git pull" if you want to integrate the remote branch with yours)
 
You have unmerged paths.
 (fix conflicts and run "git commit")
 (use "git merge --abort" to abort the merge)
 
Unmerged paths:
 (use "git add <file>..." to mark resolution)
       both modified:   src/cart.js
 
no changes added to commit (use "git add" and/or "git commit -a")
PS>

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

<<<<<<< HEAD
Версия кода 1
=======
Версия кода 2
>>>>>>> ID коммита из ветки отслеживания

Пример:

<<<<<<< HEAD
// Считает итоговую сумму корзины со скидкой 10%.
function getCartTotal(price, discount) {
  const total = price * 0.9;
=======
// Считает итоговую сумму корзины с учётом скидки.
function getCartTotal(price, discount) {
  const total = price - discount;
>>>>>>> 9e1861aa8b754aa203708f520d9748c15484f086
  return total;
}

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

После правок нужно выполнить команду git add, она добавит файл с изменениями в специальную промежуточную зону Git, которая называется staging area. Далее можно снова проверить статус:

PS> git add src/cart.js
PS> git status
On branch main
Your branch and 'origin/main' have diverged,
and have 1 and 1 different commits each, respectively.
 (use "git pull" if you want to integrate the remote branch with yours)
 
All conflicts fixed but you are still merging.
 (use "git commit" to conclude merge)
 
Changes to be committed:
       modified:   src/cart.js

Если в выводе есть текст: All conflicts fixed, значит, конфликт решён, нужно завершить объединение командой git commit:

PS> git commit
[main c7c41f3] Merge branch 'main' of https://github.com/<username>-byte/online-store

git pull –rebase: линейная история

У команды git pull есть флаг –rebase. С его помощью Git забирает изменения из удалённого репозитория и добавляет наши локальные коммиты поверх свежей версии ветки.

Допустим история ветки main на удалённом репозитории и в нашей локальной рабочей ветке разошлись:

При объединении истории в рабочей ветке обычный git pull сделал бы merge-коммит, который объединяет изменения из разошедшихся коммитов:

Но git pull –rebase просто передвинет наш коммит вперёд, после новых коммитов коллег, словно никакого расхождения истории не было:

В этом сильная сторона git pull –rebase, он помогает сделать историю линейной и более удобной для чтения. Но его не всегда безопасно использовать.

Когда rebase безопасен, а когда нет

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

Допустим, мы сделали два новых коммита в локальной feature-ветке. Пока мы работали, коллеги добавили на GitHub новые коммиты, и история разошлась:

В такой ситуации можно выполнить git pull –rebase, чтобы перенести наши локальные коммиты C и D поверх коммитов коллег и получить линейную историю:

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

Допустим в удалённом репозитории есть ветка main с коммитами A и B. Мы работаем в feature-ветке, добавили туда коммит C и залили его тоже на репозиторий.

Теперь там есть:

Ветка main с коммитами A и B.

Ветка feature с коммитами A, B, C.

Далее коллега сохранил изменения из feature-ветки себе и добавил коммит D. В это время в ветке main появились ещё два коммита: E и F.

В итоге, истории веток разошлись:

Чтобы сделать историю линейной, мы решили выполнить rebase и добавили коммиты E и F в нашу feature ветку:

Далее выложили новую историю изменений в удалённый репозиторий.

Когда коллега решит залить свои изменения на репозиторий, он увидит, что его история сильно отличается от истории в удалённой ветке:

Если коллега решит залить изменения то появится проблема. У него уже есть коммит C с изменениями, которые аналогичны изменениям в коммите C’ на репозитории. C и C’ для Git — разные коммиты. Когда коллега попробует сделать merge или rebase и залить результат на репозиторий, Git может не распознать, что в коммитах одинаковые патчи и получится дублирование изменений. Это может привести к путанице и конфликтам:

Использовать rebase без договорённости с командой — плохая идея. Если переписать историю ветки, которую уже скачали другие, их локальные клоны перестанут совпадать с удалённым репозиторием. После этого придётся вручную разбираться, какая история теперь правильная.

Настройка git pull.rebase в git config

По умолчанию команда git pull выполняет fetch и merg, но это можно перенастроить. Допустим, мы часто выполняем rebase в нашей локальной ветке, делаем это чисто для себя, без риска поломать историю на общем репозитории.

Мы можем настроить git pull таким образом, чтобы вместо связки fetch + merge она выполняла по умолчанию fetch + rebase.

Для этого нужно выполнить команду git config pull.rebase true. Она включит rebase для git pull по умолчанию. Проверить изменение можно при помощи команды git config –local –get pull.rebase, она вернёт true:

PS> git config pull.rebase true
PS> git config --local --get pull.rebase
true

Ещё для проверки можно открыть файл конфигурации Git, он лежит в скрытой папке .git и содержит код с настройками. В этом файле должна появиться такая запись:

[pull]
    rebase = true

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

Если нам нужно, чтобы git pull во всех проектах по умолчанию выполнял rebase, то можно добавить в команду флаг –global:

PS> git config --global pull.rebase true
PS> git config --global --get pull.rebase
true

В файле конфигурации с глобальными настройками Git появится такая запись:

[pull]
    rebase = true

После этого rebase будет работать по умолчанию в любых проектах при использовании команды git pull.

Если мы решили, что rebase в git pull по умолчанию нам не подходит, то можно откатить изменения к merge.

Первая команда возвращает merge в git pull в одном проекте, вторая проверяет результат:

PS> git config --local --unset pull.rebase
PS> git config --local --get pull.rebase
PS>

Точно так же, при помощи флага –global мы можем вернуть merge в глобальные настройки git pull:

PS> git config --global --unset pull.rebase
PS> git config --global --get pull.rebase
PS>

Команда git config –local –get pull.rebase запрашивает вывод настроек, если в выводе ничего нет, значит отмена rebase прошла успешно.

Команда git pull –ff-only

Кроме rebase и merge, Git может выполнять команду git pull –ff-only. ff — это fast-forward, «перемотка вперёд». Она возможна, когда в истории нет расхождений. Например в нашей локальной ветке нет своих новых коммитов, а в удалённом репозитории просто появились новые коммиты поверх старых:

Здесь нет расхождения истории, поэтому Git передвинет локальную ветку и добавит коммиты C и D:

История останется линейной, без merg-коммитов.

Но если в ветках есть расхождения истории, то git pull –ff-only не станет выполнять merge или rebase. Вместо этого Git остановится. Нам придётся самостоятельно выбирать, что делать дальше, выполнять merge, rebase или не принимать правки:

–ff-only тоже можно настроить как опцию по умолчанию при выполнении команды git pull.

Так её можно настроить для одного текущего проекта:

git config pull.ff only

А так глобально, для всех репозиториев:

git config –global pull.ff only

Отменить –ff-only можно при помощи команды:

git config –unset pull.ff

Если нужно отменить настройку глобально для всех проектов, то нужно добавить флаг –global:

git config –global –unset pull.ff

Таблица с вариантами настройки git pull:

	pull.rebase true	pull.rebase false	pull.ff only
Что делает	Переносит локальные коммиты поверх коммитов удалённой ветки	После загрузки изменений объединяет ветки через merge	Обновляет ветку только если нет расхождения истории, в противном случае останавливается
Для текущего проекта	git config pull.rebase true	git config pull.rebase false	git config pull.ff only
Для всех проектов	git config –global pull.rebase true	git config –global pull.rebase false	git config –global pull.ff only
Отменить в текущем проекте	git config –unset pull.rebase	git config –unset pull.rebase	git config –unset pull.ff
Отменить глобально	git config –global –unset pull.rebase	git config –global –unset pull.rebase	git config –global –unset pull.ff

git fetch и git pull: в чём различие

После того, как мы разобрали основные особенности git fetch и git pull, ещё раз коротко зафиксируем чем они отличаются:

Параметр	git fetch	git pull
Что скачивает	Новые коммиты, ветки и теги из удалённого репозитория.	Те же данные, потому что сначала тоже выполняет fetch.
Изменяет рабочую ветку	Нет. Обновляются только ветки отслеживания вроде origin/main. В рабочую ветку изменения не вносятся.	Да. Git пытается влить изменения в рабочую ветку.
Создаёт merge commit	Нет. Слияния не происходит.	Может создать, если локальная и удалённая истории разошлись.
Риск конфликтов	На этапе загрузки конфликтов нет.	Конфликт возможен во время merge.

Когда что использовать

ННет какого-то одного универсального правила, как правильно подтягивать изменения при помощи git. Всё зависит от конкретной ситуации.

Ситуация 1 — командная работа

Допустим, мы решили обновить свою локальную ветку main перед решением задачи. Сами мы туда коммиты не добавляем, ветка используется только как основа для работы. В таком случаем мы можем выполнить git pull.

Раз в локальной main нет наших коммитов, она ничем не отличается от той версии, что была на сервере при последнем обновлении. Нет расхождений истории, а значит pull просто добавит новые коммиты без создания merge-коммитов и риска конфликтов.

В командной разработке после push обычно включается CI/CD: тесты, сборка и проверки запускаются автоматически, поэтому чистая история и понятные ветки экономят время всей команде.

Ситуация 2 — одиночная feature-ветка

Мы работаем в своей feature-ветке, а в main за это время появились новые коммиты от коллег. Мы можем использовать git pull –rebase origin main, чтобы получить линейную историю. Если больше никто не строит свою работу на этой ветке, то это это безопасно.

Ситуация 3 — ревью чужих изменений

Мы с коллегой работаем в одном участке кода. Он внёс правки и залил изменения на удалённый репозиторий. Если мы не глядя выполним git pull и применим изменения к рабочей ветке, то можем получить проблемы в коде. Безопаснее сначала изучить правки при помощи команды git fetch и только потом, если всё в порядке, применить их.

Ситуация 4 — подготовка PR

Предположим, мы работаем только со своей веткой и перед pull request хотим почистить историю. Для этого тоже можно применить git pull –rebase origin main.

Rebase перед PR убирает из истории случайные merge-коммиты — ревьюеру проще читать только изменения по задаче. Но такой способ подойдёт если изменения будут выложены в ветку, на которой работаем только мы. Если ей пользуется кто-то ещё, мы можем поломать историю изменений.

Это только несколько примеров, выбор команды зависит от конкретного случая. Главное понимать контекст и что команды выполняют. 

git fetch безопасно загружает изменения и даёт время их проверить. git pull сразу применяет новые коммиты к текущей ветке, поэтому подходит, когда мы готовы обновиться. git pull –rebase помогает сохранить линейную историю, но только если мы работаем со своей веткой и не мешаем коллегам.

Линейная история перед PR помогает пройти код-ревью быстрее: ревьюер видит изменения по задаче, а не случайные merge-коммиты из соседних веток.

Что советуем ещё почитать 

Бэкенд с нуля в 2026: учим Flask, Docker, Redis и ещё 7 технологий — роадмап для начинающего бэкендера: язык, API, базы, Docker, тестирование и деплой. Хорошее продолжение после базового Git.

Куда расти бэкенд-разработчику в 2026–2027 — материал для тех, кто уже работает с кодом и хочет выбрать следующий трек: архитектура, DevOps, Go/Rust, AI-инженерия или MLOps.

DevSecOps: что это такое и как работает — безопасность, встроенная в разработку: проверки после коммита, сканирование Docker-образов, SAST, SCA и Shift Left.

10 мастхэв-плагинов для VS Code — свежая подборка расширений для редактора, которые помогают писать код быстрее и удобнее.

Переход из 1С в Java: IntelliJ IDEA, Git и CI/CD — практический материал про инструменты Java-разработчика после 1С: IDE, Git, CI/CD и AI-агенты в разработке.