Другой вопрос говорит, что git pull
похож на git fetch
+ git merge
.
Но в чем разница между git pull
и git fetch
+ git rebase
?
Другой вопрос говорит, что git pull
похож на git fetch
+ git merge
.
Но в чем разница между git pull
и git fetch
+ git rebase
?
Из вашего вопроса должно быть совершенно очевидно, что вы на самом деле просто спрашиваете о разнице между git merge
и git rebase
.
Итак, давайте предположим, что вы находитесь в обычном случае - вы проделали некоторую работу в своей основной ветке и извлекаете из источника, который также проделал некоторую работу. После выборки все выглядит так:
- o - o - o - H - A - B - C (master)
\
P - Q - R (origin/master)
Если вы объединитесь в этот момент (поведение git pull по умолчанию), предполагая, что конфликтов нет, вы получите следующее:
- o - o - o - H - A - B - C - X (master)
\ /
P - Q - R --- (origin/master)
Если, с другой стороны, вы сделали соответствующую перебазировку, вы получите следующее:
- o - o - o - H - P - Q - R - A' - B' - C' (master)
|
(origin/master)
Содержимое вашего рабочего дерева должно быть одинаковым в обоих случаях; вы только что создали другую историю, которая привела к этому. Перебазирование переписывает вашу историю, делая ее похожей на то, как если бы вы совершили коммит поверх новой основной ветки происхождения (R
), а не там, где вы изначально совершили коммит (H
). Вы никогда не должны использовать подход перебазирования, если кто-то уже вытащил из вашей главной ветки.
Наконец, обратите внимание, что вы можете настроить git pull
для данной ветки на использование перебазирования вместо слияния, установив для параметра конфигурации branch.<name>.rebase
значение true. Вы также можете сделать это за один раз, используя git pull --rebase
.
- o - o - o - o - P - A - Q - B - R - C
(т. е. временной порядок коммитов сохраняется)?
- person Steve Chambers; 06.11.2013
A - B - C
на origin/master (зафиксировать R) и делает это, заканчивая P - Q - R - A - B - C
.
- person Cascabel; 06.11.2013
git config --global branch.autosetuprebase always
- person mmjmanders; 16.05.2014
git pull
похоже на бег git fetch
, затем git merge
git pull --rebase
похоже на git fetch
, затем git rebase
git pull
похоже на git fetch
+ git merge
.
«В режиме по умолчанию git pull является сокращением для
git fetch
, за которым следуетgit merge
FETCH_HEAD». Точнее,git pull
запускаетgit fetch
с заданными параметрами, а затем вызываетgit merge
для слияния извлеченных заголовков ветвей с текущей ветвью.
(Ссылка: https://git-scm.com/docs/git-pull)
'Но в чем разница между git pull
и git fetch
+ git rebase
'
Опять же, из того же источника:git pull --rebase
«С --rebase он запускает git rebase вместо git merge».
'разница между merge
и rebase
'
здесь также есть ответ:
https://git-scm.com/book/en/v2/Git-Branching-Rebasing
(разница между изменением способа записи истории версий)
git fetch + git rebase
. Теперь в нашем дереве git больше или меньше конфликтов нет :)
- person Travis Le; 07.11.2019
git rebase
также выполняет эти дополнительные шаги, так как вскоре после того, как был написан этот пост в блоге. См. обсуждение --fork-point
в git help rebase
.
- person Buster; 15.01.2021