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
rebaseはours（rebaseが開始する前の現在のブランチ）とtheirs（リベースしたいブランチ）を切り替えます。
kutschkem は、GUIのmergetoolコンテキストで次のように指摘しています。
- ローカルは部分的にリベースされたコミットを参照します： "
ours"（上流のブランチ）
- remoteは受信する変更を参照します： "
theirs"-リベースの前の現在のブランチ。
この回答の最後の部分の図を参照してください。
リベース時の反転
混乱は、リベースの反転中oursおよびtheirsリベース中の可能性があります。
（関連抽出物）
git rebasemanページ：
リベースマージは、作業ブランチからの各コミットをブランチの上で再生することで機能することに注意してください<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
A git rebase upstreamは最初HEADにBを上流のブランチに変更しますHEAD（したがって、以前の「現在の」作業ブランチと比較して、「ours」と「theirs」が切り替わります。
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」対「mine」と「theirs」
パンダウッドはコメントに追加します：
私にとっては、「ローカル」で誰が「リモート」であるかという質問がまだ残っています（gitでリベースするときに「ours」と「theirs」という用語は使用されないため、それらを参照すると答えが混乱するようです） 。
GUI git mergetool
kutschkemが追加しました。
競合を解決するとき、gitは次のように言います。
local: modified file and remote: modified file.
この時点での質問は、ローカルとリモートの定義を目的としていると確信しています。その時点で、私には私の経験から次のように思われます。
- ローカルは部分的にリベースされたコミットを参照します： "
ours"（上流のブランチ）
- remoteは受信する変更を参照します： "
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、表示されます：
git mergetool -t gvimdiffを使用して、Vimdiffをmergetoolとして起動します。Gitの最近のバージョンは、次のウィンドウレイアウトでVimdiffを呼び出します。
+--------------------------------+
| LOCAL | BASE | REMOTE |
+--------------------------------+
| MERGED |
+--------------------------------+
LOCAL：
現在のブランチ上のファイルのコンテンツを含む一時ファイル。BASE：
マージの共通ベースを含む一時ファイル。REMOTE：
マージするファイルの内容を含む一時ファイル。MERGED：
競合マーカーを含むファイル。
Gitは可能な限り多くの自動競合解決を実行しており、このファイルの状態は両方の組み合わせと、Gitがそれ自体で解決できなかったものを囲む競合マーカーLOCALとの組み合わせですREMOTE。このファイルへの解決の結果を記述する必要があります。
mergetool
