TL; DR;
Подводя итог (как комментарии Benubird ), когда:
git checkout A
git rebase B # rebase A on top of B
localесть B(перебазировать на ),remote является A
И:
git checkout A
git merge B # merge B into A
localесть A(слить в ),remote является B
Переключает ребазу ours(текущая ветвь перед началом ребазинга) и theirs(ветка, поверх которой вы хотите перебазировать).
Кучкем указывает, что в контексте mergetool с графическим интерфейсом :
- локальные ссылки на частично перебазированные коммиты : "
ours" (ветка upstream)
- Удаленный относится к входящим изменениям : "
theirs" - текущая ветвь перед ребазингом.
Смотрите иллюстрации в последней части этого ответа.
Инверсия при ребазе
Путаница может быть связана с инверсией oursи theirsво время ребазинга .
(соответствующие выдержки)
git rebaseсправочная страница :
Обратите внимание, что слияние rebase работает путем воспроизведения каждого коммита из рабочей ветви поверх <upstream>ветви.
Из-за этого, когда возникает конфликт слияния:
- сторона сообщила , как «
ours» это так далеко нормированные серии, начиная с <upstream>,
- и '
theirs' это рабочая ветвь. Другими словами, стороны поменялись местами.
Инверсия проиллюстрирована
На слиянии
x--x--x--x--x(*) <- current branch B ('*'=HEAD)
\
\
\--y--y--y <- other branch to merge
мы не меняем текущую ветвь «B», поэтому то, что у нас есть, это то, над чем мы работали (и мы объединяем из другой ветки)
x--x--x--x--x---------o(*) MERGE, still on branch B
\ ^ /
\ ours /
\ /
--y--y--y--/
^
their
На ребазе:
Но при перебазировании мы переключаемся на сторону, потому что первое, что делает перебазировка, это извлекает ветку upstream! (чтобы воспроизвести текущие коммиты поверх него)
x--x--x--x--x(*) <- current branch B
\
\
\--y--y--y <- upstream branch
A git rebase upstreamсначала изменит HEADB на восходящую ветвь HEAD(следовательно, переключение «наших» и «их» по сравнению с предыдущей «текущей» рабочей ветвью.)
x--x--x--x--x <- former "current" branch, new "theirs"
\
\
\--y--y--y(*) <- upstream branch with B reset on it,
new "ours", to replay x's on it
, а затем rebase воспроизведет «их» коммиты в новой «нашей» ветке B:
x--x..x..x..x <- old "theirs" commits, now "ghosts", available through reflogs
\
\
\--y--y--y--x'--x'--x'(*) <- branch B with HEAD updated ("ours")
^
|
upstream branch
Примечание: понятие «восходящий поток» - это ссылочный набор данных (все репо или, как здесь, ветвь, которая может быть локальной ветвью), из которой считываются данные или в которые добавляются / создаются новые данные.
' local' и ' remote' против ' mine' и ' theirs'
Пандавуд добавляет в комментариях :
Для меня все еще остается вопрос, который является «локальным», а кто «удаленным» (поскольку термины «наш» и «их» не используются при перебазировании в git, обращение к ним просто делает ответ более запутанным) ,
GUI git mergetool
кучкем добавляет, и справедливо так
При разрешении конфликтов git скажет что-то вроде:
local: modified file and remote: modified file.
Я совершенно уверен, что вопрос нацелен на определение локального и удаленного на данный момент. На данный момент, как мне кажется из моего опыта, что:
- локальные ссылки на частично перебазированные коммиты : "
ours" (ветка upstream)
- Удаленный относится к входящим изменениям : "
theirs" - текущая ветвь перед ребазингом.
git mergetoolдействительно упоминает «локальный» и «удаленный» :
Merging:
f.txt
Normal merge conflict for 'f.txt':
{local}: modified file
{remote}: modified file
Hit return to start merge resolution tool (kdiff3):
Например, KDiff3 будет отображать разрешение слияния следующим образом :
И Мельд отобразил бы это тоже :
То же самое для VimDiff , который отображает :
Вызвать Vimdiff как mergetool с помощью git mergetool -t gvimdiff. Последние версии Git вызывают Vimdiff со следующим расположением окна:
+--------------------------------+
| LOCAL | BASE | REMOTE |
+--------------------------------+
| MERGED |
+--------------------------------+
LOCAL:
Временный файл, содержащий содержимое файла в текущей ветви.BASE:
Временный файл, содержащий общую базу для слияния.REMOTE:
Временный файл, содержащий содержимое файла для объединения.MERGED:
Файл, содержащий маркеры конфликта.
Git выполнил максимально возможное автоматическое разрешение конфликтов, и состояние этого файла представляет собой сочетание обоих LOCALи REMOTEмаркеров конфликта, окружающих все, что Git не мог разрешить сам. Должен написать результат решения этого файла.
mergetool
