git rebase，跟踪“本地”和“远程”
在做git rebase的时候，在解决冲突的时候，我经常很难弄清楚“local”和“remote”是怎么回事。 我有时会有这样的印象：他们从一个承诺转到另一个承诺。
这可能（绝对），因为我还没有正确理解。
当重组时，谁是“本地”，谁是“偏远”？
（我用P4Merge来解决冲突）
TL; DR;
总结（如Benubird 评论 ），当：
git checkout A git rebase B # rebase A on top of B
-
local是B（rebase 到 ）， -
remote是A
和：
git checkout A git merge B # merge B into A
-
local是A（并入）， -
remote是B
rebase切换ours （rebase开始之前的当前分支）和theirs （你想要rebase之上的分支）。
kutschkem指出， 在一个GUI mergetool上下文中 ：
- 本地引用部分重新发布的提交 ：“
ours”（上游分支） - 远程指的是传入的变化 ：“
theirs” – 当前分支之前的变调。
请参阅本答复最后部分的插图。
倒置时反转
这个混乱可能与ours和theirs在反转时的倒置有关 。
（相关摘录）
git rebase手册页 ：
请注意，通过在
<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
在rebase上：
但是在一个rebase上 ，我们转换方面，因为rebase做的第一件事是检查上游分支！ （重播当前的提交）
x--x--x--x--x(*) <- current branch B \ \ \--y--y--y <- upstream branch
git rebase upstream的git rebase upstream会首先将B的HEAD更改为上游分支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
，然后这个rebase会在新的'我们的'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
注意： “上游”概念是从其中读取数据或添加/创build新数据的参考数据集（全部回购或像这里的分支，可以是本地分支）。
“ local ”和“ remote ”与“ mine ”和“ theirs ”
Pandawood在评论中补充道：
对于我来说，问题依然存在，那就是“本地化”，谁是“远程化”（因为在重组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会显示合并分辨率，如下所示 ：
而融合也会显示它 ：
同样的VimDiff ， 它显示 ：
用git mergetool -t gvimdiff调用Vimdiff作为mergetool。 最新版本的Git使用以下窗口布局调用Vimdiff：
+--------------------------------+ | LOCAL | BASE | REMOTE | +--------------------------------+ | MERGED | +--------------------------------+
LOCAL：
包含当前分支上文件内容的临时文件。BASE：
包含合并的公共基础的临时文件。REMOTE：
包含要合并的文件内容的临时文件。MERGED：
包含冲突标记的文件。Git已经执行了尽可能多的自动冲突解决scheme，而且这个文件的状态是
LOCAL和REMOTE的组合，它们之间的冲突标记是Git无法自行解决的。
mergetool应该将parsing结果写入这个文件。
底线
git rebase
- LOCAL =你正在重塑的基地
- REMOTE =你正在提交的提交
混帐合并
- LOCAL =你正在合并的原始分支
- REMOTE =你正在合并的其他分支
换句话说， LOCAL总是原来的，而REMOTE总是那些没有提交的人，因为他们被合并或者重新组合
certificate给我看！
当然。 不要拿我的话！ 这是一个简单的实验，你可以做自己看。
首先，确保你已经正确configuration了git mergetool。 （如果你没有，那么你可能不会读这个问题。）然后find一个工作目录。
设置您的存储库：
md LocalRemoteTest cd LocalRemoteTest
创build一个初始提交（一个空文件）：
git init notepad file.txt (use the text editor of your choice) (save the file as an empty file) git add -A git commit -m "Initial commit."
在不是主控的分支上创build一个提交：
git checkout -b notmaster notepad file.txt (add the text: notmaster) (save and exit) git commit -a -m "Add notmaster text."
在主分支上创build一个提交：
git checkout master notepad file.txt (add the text: master) (save and exit) git commit -a -m "Add master text." gitk --all
此时你的仓库应该是这样的：
现在进行rebasetesting：
git checkout notmaster git rebase master (you'll get a conflict message) git mergetool LOCAL: master REMOTE: notmaster
现在合并testing。 closures您的mergetool而不保存任何更改，然后取消rebase：
git rebase --abort
然后：
git checkout master git merge notmaster git mergetool LOCAL: master REMOTE: notmaster git reset --hard (cancels the merge)
你的结果应该和上面显示的一样。
我没有完全确定你的问题，但我认为下面的图解决了你的问题。 （Rebase：远程仓库—>工作区）
来源： 我的Git工作stream程
