在执行 git rebase 时什么是“我们的”和“他们的”

Sha*_*han 9 git version-control rebase

我已经应用了以下命令,但在执行 rebase 时几乎没有混淆 - 以下命令中我们的和他们的

git checkout app/dashboard-sprint-5
git rebase app/demandware
Run Code Online (Sandbox Code Playgroud)

我知道当前的分支是app/dashboard-sprint-5当我应用 rebase 时。

app/dashboard-sprint-5将应用于app/demandware.

什么是ourstheirs分支机构的条款。

我检查了链接但不满意

mme*_*nik 9

简而言之,当我们谈论 rebase 时,ours指的是基础分支。

因此,在您的情况下ours将是app/demandware,因为首先 git 将我们移动到那里,然后应用来自 的更改app/dashboard-sprint-5,这将是theirs.

例如,这里有关于 rebase 和word 的文档说明ours

因为 git rebase 使用给定的策略重播来自 <upstream> 分支顶部的工作分支的每个提交,所以使用ours策略只会丢弃 <branch> 中的所有补丁,这没什么意义。

  • 这对我来说是第一次有意义,而且我多年来一直在解决冲突。我总是选择错误的选项,但现在不会了。 (2认同)

kdb*_*kdb 6

为了轻松记住我们他们的方向,请将变基视为将当前分支的每个提交挑选到目标分支上。

\n\n
Before rebasing:\n    A--B--C (master)\n       \'--D--E (devel, HEAD)\n\nReset HEAD to master:\n    A--B--C (master, HEAD)\n       \'--D--E (devel)\n\nCherry-pick D, E.\n    A--B--C (master)\n       |  \'-- D\'--E\' (HEAD)\n       \'--D--E (devel)\nHEAD becomes "ours" and the old devel branch "theirs".\n              ^^^^                            ^^^^^^\n\nOn success, repoint devel to E\':\n    A--B--C (master)\n          \'--D\'--E\' (devel, HEAD)\n
Run Code Online (Sandbox Code Playgroud)\n\n

在没有冲突的非交互式变基中,看起来我们直接从旧的开发分支历史跳转到重新设定的开发分支历史。在这个视图中,我们他们的反转并不明显,导致潜在的混乱,特别是在合并冲突解决 \xe2\x80\x93 期间,这只是有点意外,我们开始的分支可能会突然被称为“远程分支”通过合并工具。

\n\n
\n\n

虽然这个问题已经得到解答,但我添加了这个更直观的解释,因为我发现如果没有这个解释就很难记住结果。

\n