を実行するとgit rebase、競合を解決するときに「ローカル」と「リモート」で何が起こっているのかを把握するのが難しくなることがよくあります。コミットごとに、ローカルとリモートが入れ替わっているような印象を受けることがあります。
これはおそらく（間違いなく）私がまだパラダイムを適切に理解していないためです。
リベースする場合、誰が「ローカル」で誰が「リモート」ですか?
(競合を解決するために P4Merge を使用します。)
ベストアンサー1
TL;DR;
git checkout A
git rebase B # rebase A on top of B
localB（リベース上に）、remoteはA
そして：
git checkout A
git merge B # merge B into A
localはA（マージの中へ）、remoteはB
リベースはours、(リベース開始前の現在のブランチ) とtheirs(リベースする対象のブランチ) を切り替えます。
クチュケムと指摘している。GUIマージツールのコンテキスト:
- ローカルは部分的にリベースされたコミットを参照します: "
ours" (上流ブランチ) - リモートは受信する変更を指します: "
theirs" - リベース前の現在のブランチ。
この回答の最後の部分にある図を参照してください。
リベース時の反転
この混乱は、リベース中oursの反転theirs（
関連抜粋）
リベース マージは、作業ブランチからの各コミットをブランチ上で再生することによって機能することに注意してください
<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 upstreamHEADまず、 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 でリベースするときには「私たちの」や「彼らの」という用語は使用されないため、それらに言及すると答えがさらに混乱するだけのように思えます)。
GUI git マージツール
クチュケムと付け加えているが、その通りだ。
競合を解決するとき、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):
例えば、翻訳だろうマージ解像度を次のように表示します:
git mergetool -t gvimdiff を使用して、Vimdiff をマージツールとして呼び出します。Git の最近のバージョンでは、次のウィンドウ レイアウトで Vimdiff が呼び出されます。
+--------------------------------+
| LOCAL | BASE | REMOTE |
+--------------------------------+
| MERGED |
+--------------------------------+
LOCAL:
現在のブランチ上のファイルの内容を含む一時ファイル。BASE:
マージの共通ベースを含む一時ファイル。REMOTE:
マージするファイルの内容を含む一時ファイル。MERGED:
競合マーカーを含むファイル。Git は可能な限りの自動競合解決を実行しており、このファイルの状態は両方の組み合わせであり
LOCAL、REMOTEGit が解決できなかったものはすべて競合マーカーで囲まれています。解決の結果をこのファイルに書き込む必要があります
。mergetool