Podejrzewam, że jesteś zdezorientowany, ponieważ jest to zasadniczo mylące. Co gorsza, cała nasza / ich rzeczy zmieniają role (stają się zacofane), kiedy robisz rebase.
Ostatecznie, w czasie git merge, w „nasz” oddział odnosi się do oddziału jesteś łączących się :
git checkout merge-into-ours
a gałąź „ich” odnosi się do (pojedynczej) gałęzi, którą scalasz:
git merge from-theirs
a tutaj „nasz” i „ich” ma jakiś sens, ponieważ mimo że „ich” i tak prawdopodobnie należy do ciebie, „ich” nie jest tym, w którym byłeś podczas biegu git merge.
Chociaż używanie rzeczywistej nazwy oddziału może być całkiem fajne, rozpada się w bardziej złożonych przypadkach. Na przykład zamiast powyższego możesz wykonać:
git checkout ours
git merge 1234567
gdzie scalasz według surowego identyfikatora zatwierdzenia. Gorzej, możesz nawet to zrobić:
git checkout 7777777 # detach HEAD
git merge 1234567 # do a test merge
w takim przypadku nie są zaangażowane żadne nazwy oddziałów!
Wydaje mi się, że jest to mało pomocna, ale w rzeczywistości w gitrevisionsskładni można odwoływać się do indywidualnej ścieżki w indeksie według numeru podczas scalania
git show :1:README
git show :2:README
git show :3:README
Etap nr 1 jest wspólnym przodkiem plików, etap nr 2 to wersja gałęzi docelowej, a etap nr 3 to wersja, z której się łączysz.
Powodem, dla którego zmieniają się pojęcia „nasze” i „ich”, rebasejest to, że rebase działa, wykonując serię wiśniowych wyborów, w anonimowej gałęzi (odłączony tryb HEAD). Oddział docelowy jest oddziałem anonimowym, a oddział scalania z jest oddziałem pierwotnym (przedrebase): więc „--ours” oznacza, że buduje się anonimowy rebase, podczas gdy „--heirs” oznacza „rebasing naszej gałęzi” .
Jeśli chodzi o wpis gitattributes: może to mieć skutek: „nasz” naprawdę oznacza „użyj etapu nr 2” wewnętrznie. Ale, jak zauważysz, nie jest on w tym czasie na miejscu, więc nie powinien mieć tutaj wpływu ... no cóż, chyba że skopiujesz go do drzewa roboczego przed rozpoczęciem.
Nawiasem mówiąc, dotyczy to wszystkich zastosowań naszego i ich, ale niektóre są na poziomie całego pliku ( -s oursdla strategii scalania; git checkout --ourspodczas konfliktu scalania), a niektóre są na zasadzie kawałek po kawałku ( -X ourslub -X theirspodczas -s recursivełączyć). Co prawdopodobnie nie pomaga w żadnym zamieszaniu.
Jednak nigdy nie wymyśliłem dla nich lepszej nazwy. I: zobacz odpowiedź VonC na inne pytanie, gdzie git mergetoolwprowadza jeszcze więcej nazw, nazywając je „lokalnymi” i „zdalnymi”!
