git rebase"被我们删除"和"被他们删除"

Mil*_*are 48 git git-rebase

假设我在master上重新定义实验分支,文件中存在冲突.当然,两个分支都删除了文件.因此,当我解决冲突时,在我看到和.它非常令人困惑.有什么办法可以理解他们的意思吗?谁是他们,谁是我们git statusdeleted by usdeleted by them

或者在重新定位时有另一种方法可以知道哪个文件被哪个分支删除了?喜欢打印分支名称?

tne*_*tne 49

参考文档

请注意,rebase合并的工作原理是从分支顶部的工作分支重放每个提交<upstream>.正因为如此,当合并冲突发生时,报告为我们的那一方是迄今为止重新定义的系列,首先是<upstream>,并且他们是工作分支.换句话说,双方交换.

https://git-scm.com/docs/git-rebase/2.17.0(最新消息:https://git-scm.com/docs/git-rebase)

因此,"我们删除"的文件是在您正在重新定位的分支上删除的文件(最终分支),"由它们删除"的文件是在您正在变基的分支中删除的文件(将被重新分配的文件)丢弃).

示范

$ 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
Run Code Online (Sandbox Code Playgroud)

AFAIK没有用官方工具明确显示分支的特定名称的开关.除非我错了,否则这只是你需要学习以解决最初困惑的事情之一.

值得赞扬的是,如果你考虑它,它确实很有意义.

更迂腐的分析

手册页的文本有点含糊不清,因为只有在使用该--merge选项时它才能被解释为相关.第二次提到这种行为会加剧这种情况--strategy:"注意我们和他们的反转,如上面提到的-m选项." .

但是,我认为这与git-rebase的行为没有对比--merge,当它不使用时; 相反,我认为它与git-rebase与git-merge的行为形成鲜明对比.MERGE STRATEGIES部分显然是从git-merge手册页中删除的,因此很容易想象作者在使用rebase时需要强调交换,因为在该部分中没有提到.对我来说,下面的句子证实了这种解释:"[...] git rebase使用给定的策略[...]"从分支顶部的工作分支重放每个提交.

虽然我们现在明白合并策略应该对双方没有影响(只有git-merge和git-rebase的选择应该),但我会注意到--merge默认策略所暗示的(使得默认行为完全不含糊) ).

  • "值得赞扬的是,它确实很有意义" - 不应该是"要*我们的*信用......":-) (52认同)
  • "值得赞扬的是,如果他们考虑一下,它确实很有意义." (8认同)
  • "如果你考虑它,它确实很有意义.不,它肯定没有.特别是在重新定位由您创作的分支时.他们是我. (7认同)
  • @Cheeso关键的见解是,rebase就像检查上游分支,然后从当前分支中挑选每个提交到它上面.当你以这种方式看待它时,工作分支(我们的)是上游分支,而另一个(我们从中挑选)是"外来的"(他们的).一旦rebase完成,git会重置新分支上的头并检查它.这是一个非常机械/程序上的理解,但我坚持认为"对我们来说,如果他们考虑它确实很有意义";). (3认同)

Max*_*lov 20

以下是SzG对类似问题的回答:

当你合并,us是指你融入,而不是分支them,分支合并.

当你变基,us是指上游分支,them是你动一下分支.如果出现变异,这有点违反直觉.

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