TL; DR;
Podsumowując (jak komentuje Benubird ), kiedy:
git checkout A
git rebase B # rebase A on top of B
local
się B
(przebazować na )
remote
jest A
I:
git checkout A
git merge B # merge B into A
local
jest A
(scal w ),
remote
jest B
Przełącza rebase ours
(bieżąca gałąź przed rozpoczęciem rebase) i theirs
(gałąź, na której ma zostać dokonana rebase).
kutschkem wskazuje, że w kontekście narzędzia scalającego GUI :
- lokalnie odwołuje się do zatwierdzonych częściowo zmian : "
ours
" (gałąź upstream)
- remote odnosi się do nadchodzących zmian : "
theirs
" - bieżąca gałąź przed rebase.
Zobacz ilustracje w ostatniej części tej odpowiedzi.
Inwersja podczas rebase
Zamieszanie może być związane z inwersją ours
i theirs
podczas rebase .
(odpowiednie fragmenty)
git rebase
strona podręcznika :
Zauważ, że scalanie rebase działa poprzez ponowne odtworzenie każdego zatwierdzenia z gałęzi roboczej na wierzchu <upstream>
gałęzi.
Z tego powodu, gdy dochodzi do konfliktu scalania:
- strona zgłaszana jako „
ours
” jest dotychczas zmienionym szeregiem zaczynającym się od <upstream>
,
- a „
theirs
” to gałąź robocza. Innymi słowy, strony są zamieniane.
Zilustrowana inwersja
Na fuzji
x--x--x--x--x(*) <- current branch B ('*'=HEAD)
\
\
\--y--y--y <- other branch to merge
, nie zmieniamy bieżącej gałęzi 'B', więc to, co mamy, to wciąż to, nad czym pracowaliśmy (i łączymy się z inną gałęzią)
x--x--x--x--x---------o(*) MERGE, still on branch B
\ ^ /
\ ours /
\ /
--y--y--y--/
^
their
Na rebase:
Ale w przypadku rebase zmieniamy stronę, ponieważ pierwszą rzeczą, którą robi rebase, jest pobranie gałęzi upstream! (aby odtworzyć aktualne zatwierdzenia na górze)
x--x--x--x--x(*) <- current branch B
\
\
\--y--y--y <- upstream branch
A git rebase upstream
najpierw zmieni HEAD
B na gałąź upstream HEAD
(stąd zmiana „naszego” i „ich” w porównaniu do poprzedniej „bieżącej” gałęzi roboczej).
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
, a następnie rebase odtworzy „swoje” zatwierdzenia w nowej „naszej” gałęzi 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
Uwaga: pojęcie „upstream” to referencyjny zbiór danych (all repo lub, jak tutaj, oddział, który może być oddziałem lokalnym ), z którego odczytywane są dane lub do których są dodawane / tworzone nowe dane.
„ local
” i „ remote
” kontra „ mine
” i „ theirs
”
Pandawood dodaje w komentarzach :
Dla mnie nadal pozostaje pytanie, które jest „lokalne”, a kto jest „zdalny” (ponieważ terminy „nasz” i „ich” nie są używane podczas ponownego bazowania w git, odnoszenie się do nich po prostu wydaje się bardziej zagmatwać odpowiedź) .
GUI git connectetool
Kutschkem dodaje i słusznie:
Podczas rozwiązywania konfliktów git powie coś takiego:
local: modified file and remote: modified file.
Jestem całkiem pewien, że w tym momencie pytanie dotyczy definicji lokalnego i odległego. W tym momencie z mojego doświadczenia wynika, że:
- lokalnie odwołuje się do zatwierdzonych częściowo zmian : "
ours
" (gałąź upstream)
- remote odnosi się do nadchodzących zmian : "
theirs
" - bieżąca gałąź przed rebase.
git mergetool
rzeczywiście wspomina o „lokalnym” i „zdalnym” :
Merging:
f.txt
Normal merge conflict for 'f.txt':
{local}: modified file
{remote}: modified file
Hit return to start merge resolution tool (kdiff3):
Na przykład, KDiff3 by wyświetlać rozdzielczość scalania podobnie jak :
I meld też to wyświetli :
To samo dotyczy VimDiff , który wyświetla :
Wywołaj Vimdiff jako narzędzie do łączenia za pomocą git connectetool -t gvimdiff. Najnowsze wersje Gita wywołują Vimdiff z następującym układem okien:
+--------------------------------+
| LOCAL | BASE | REMOTE |
+--------------------------------+
| MERGED |
+--------------------------------+
LOCAL
:
Plik tymczasowy zawierający zawartość pliku w bieżącej gałęzi.
BASE
:
Plik tymczasowy zawierający wspólną podstawę dla scalenia.
REMOTE
:
Plik tymczasowy zawierający zawartość pliku do scalenia.
MERGED
:
Plik zawierający znaczniki konfliktu.
Git wykonał tyle automatycznego rozwiązywania konfliktów, ile to możliwe, a stan tego pliku jest połączeniem obu LOCAL
i REMOTE
znaczników konfliktów otaczających wszystko, czego Git nie mógł rozwiązać samodzielnie. Powinien zapisać wynik uchwały do tego pliku.
mergetool