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(гілка, зверху якої ви хочете перезавантажити).
kutschkem вказує, що в контексті графічного інтерфейсу GUI :
- місцеві посилання на частково знижену комісію : "
ours" (гілка вище)
- віддалене посилається на вхідні зміни : "
theirs" - поточна гілка перед ребатом.
Дивіться ілюстрації в останній частині цієї відповіді.
Інверсія при ребазі
Плутанина може бути пов’язана з інверсією oursта theirsпід час ребазування .
(відповідні витяги)
git rebaseсторінка man :
Зауважте, що злиття ребаза працює, відтворюючи кожну комісію з робочої гілки вгорі <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
На ребазі:
Але на ребазі ми переходимо на сторону, тому що перше, що потрібно робити, - це перевірити верхню гілку! (для відтворення поточних комісій поверх нього)
x--x--x--x--x(*) <- current branch B
\
\
\--y--y--y <- upstream branch
git rebase upstreamБуде перша зміна HEADвід B до потоку гілки 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
, і тоді ребаза повторно повторить "свої" нові відділення "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' vs. ' mine' і ' theirs'
Пандавуд додає в коментарях :
Для мене все ще залишається питання, що є "локальним" і хто "віддаленим" (оскільки терміни "наш" і "їхній" не використовуються при перезаписі в git, посилання на них просто здається, що відповідь стає більш заплутаною) .
GUI git mergetool
kutschkem додає, і це правильно:
Під час вирішення конфліктів git скаже щось на кшталт:
local: modified file and remote: modified file.
Я впевнений, що питання має на меті визначення місцевого та віддаленого на даний момент. У цей момент мені здається, що з мого досвіду:
- місцеві посилання на частково знижену комісію : "
ours" (гілка вище)
- віддалене посилається на вхідні зміни : "
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 буде відображати дозвіл злиття як так :
І meld також відобразив би це :
Те саме для VimDiff , який відображає :
Викликайте Vimdiff як mergetool з git mergetool -t gvimdiff. Останні версії Git викликають Vimdiff із наступним макетом вікна:
+--------------------------------+
| LOCAL | BASE | REMOTE |
+--------------------------------+
| MERGED |
+--------------------------------+
LOCAL:
Тимчасовий файл, що містить вміст файла в поточній гілці.BASE:
Тимчасовий файл, що містить загальну базу для злиття.REMOTE:
Тимчасовий файл, що містить вміст файлу, який потрібно об'єднати.MERGED:
Файл, що містить маркери конфлікту.
Git виконав стільки автоматичного вирішення конфліктів , як це можливо , і стан цього файлу є комбінацією обох LOCALі REMOTEз маркерами конфлікту , що оточують нічого , що Git не може вирішити сам.
У mergetoolцей файл слід записати результат резолюції.
