git rebase“被我们删除”和“被他们删除”

git rebase "deleted by us" and "deleted by them"

提问by Milind Dumbare

Suppose I am rebasing experimentbranch on masterand there are conflicts in files. And of course there are files deleted in both branches. So when I am resolving the conflicts, in git statusI see deleted by usand deleted by them. Its very confusing. Is there any way of understanding what they mean? Who is themand who is us?

假设我在master上重新建立实验分支并且文件中存在冲突。当然，两个分支中都有文件被删除。因此，当我解决冲突时，在I see和. 它非常混乱。有什么方法可以理解它们的意思吗？谁是他们，谁是我们？git statusdeleted by usdeleted by them

Or while rebasing is there another way to know which file was deleted by which branch? Like printing the branch name?

或者在变基时是否有另一种方法可以知道哪个文件被哪个分支删除了？喜欢打印分支名称？

采纳答案by tne

Reference documentation

参考文档

Note that a rebase merge works by replaying each commit from the working branch on top of the <upstream>branch. Because of this, when a merge conflict happens, the side reported as ours is the so-far rebased series, starting with <upstream>, and theirs is the working branch. In other words, the sides are swapped.

请注意，rebase 合并通过在分支顶部重放来自工作分支的每个提交来工作<upstream>。正因为如此，当发生合并冲突时，报告为我们的一方是迄今为止重新调整的系列，以 开头<upstream>，而他们的则是工作分支。换句话说，双方互换。

https://git-scm.com/docs/git-rebase/2.17.0(latest: https://git-scm.com/docs/git-rebase)

https://git-scm.com/docs/git-rebase/2.17.0（最新：https: //git-scm.com/docs/git-rebase）

Hence, files "deleted by us" are those that were deleted on the branch you are rebasing onto(the final branch), and files "deleted by them" are files that were deleted in the branch you are rebasing (the one that will be dropped).

因此，“被我们删除”的文件是指那些在你需要衍合分支删除到“被他们删除”（最后的分支），和文件是被分支删除的文件，你需要衍合（一个将是掉了）。

Demonstration

示范

$ ls
a
$ git log --oneline --graph --decorate --all
* d055cdd (HEAD -> y) Write baz in a-file
| * 487dc8c (x) Write bar in a-file
|/  
* 3fa0da5 (master) Write foo in a-file
$ git rebase x
First, rewinding head to replay your work on top of it...
Applying: Write baz in a-file
Using index info to reconstruct a base tree...
M   a
Falling back to patching base and 3-way merge...
Auto-merging a
CONFLICT (content): Merge conflict in a
error: Failed to merge in the changes.
Patch failed at 0001 Write baz in a-file
The copy of the patch that failed is found in: .git/rebase-apply/patch

When you have resolved this problem, run "git rebase --continue".
If you prefer to skip this patch, run "git rebase --skip" instead.
To check out the original branch and stop rebasing, run "git rebase --abort".
$ cat a
<<<<<<< HEAD
bar
=======
baz
>>>>>>> Write baz in a-file
$ git checkout --ours a
$ cat a
bar
$ git checkout --theirs a
$ cat a
baz

AFAIK there is no switch to display the specific names of the branches explicitly with the official tools. Unless I'm wrong this is just one of those things you need to learn to get through the initial confusion.

AFAIK 没有使用官方工具明确显示分支的特定名称的开关。除非我错了，否则这只是您需要学习以克服最初的困惑之一。

To their credit, it does make a lot of sense if you think about it.

值得称赞的是，如果您考虑一下，这确实很有意义。

More pedantic analysis

更迂腐的分析

The text of the manual page is a little ambiguous as it could be interpreted to be relevant only when using the --mergeoption. This is exacerbated by a second mention of the behavior in --strategy: "Note the reversal of ours and theirs as noted above for the -m option.".

手册页的文本有点含糊不清，因为它只能在使用--merge选项时被解释为相关。中第二次提到的行为加剧了这种情况--strategy：“注意我们和他们的逆转，如上面针对 -m 选项所述。” .

However, I believe this is not contrasting the behavior of git-rebase when --mergeis used with when it isn't; rather I believe it is contrasting the behavior of git-rebase with git-merge. The MERGE STRATEGIES section is clearly ripped from the git-merge manual page, so it's somewhat easy to imagine that the author felt the need to emphasize the swap when using rebase since it's not mentioned in that section. The following sentence, to me, confirms this interpretation: "[...] git rebase replays each commit from the working branch on top of the branch using the given strategy [...]".

但是，我相信这与 git-rebase 在--merge使用时的行为和不使用时的行为没有对比；相反，我认为这是将 git-rebase 与 git-merge 的行为进行对比。MERGE STRATEGIES 部分显然是从 git-merge 手册页中撕下来的，所以很容易想象作者觉得在使用 rebase 时需要强调交换，因为该部分没有提到它。对我来说，以下句子证实了这种解释：“[...] git rebase 使用给定的策略 [...] 重放来自分支顶部的工作分支的每个提交”。

Although we now understand that the merge strategy should have no impact on the sides (only the choice of git-merge vs git-rebase should), I'll note --mergeis implied by the default strategy regardless (making the default behavior completely non-ambiguous).

虽然我们现在明白合并策略应该对双方没有影响（只有 git-merge 与 git-rebase 的选择应该），但我会注意到--merge默认策略隐含了无论如何（使默认行为完全无歧义）。

回答by Maxim Suslov

Below is a copy of SzG's answeron a similar question:

以下是SzG对类似问题的回答的副本：

When you merge, usrefers to the branch you're merging into, as opposed to them, the branch to be merged.

When you rebase, usrefers the upstream branch, and themis the branch you're moving about. It's a bit counter-intuitive in case of a rebase.

The reason is that git uses the same merge-engine for rebase, and it's actually cherry-picking your stuff into the upstream branch. us= into, them= from.

当您合并时，us指的是您要合并到的分支，而不是them要合并的分支。

当您rebase 时，us指的是上游分支，并且them是您要移动的分支。在 rebase 的情况下，这有点违反直觉。

原因是 git 使用相同的合并引擎进行 rebase，它实际上是将你的东西挑选到上游分支中。us= 进入，them= 从。