Git 与 pull --rebase 在无关文件上发生冲突

Question

我有一个仓库，在那里我看到了我不明白的行为。

我将发生这种情况的存储库称为“坏存储库”，以下所有序列都在该存储库上运行。

我重置为什么提交并不重要，同样的冲突行为。它报告为冲突的文件似乎是在我重置的提交中更改的文件。

1) 序列 2 仅发生在“坏 repo ”上，相同的命令序列不会在新克隆或任何其他克隆上产生冲突。一个人的 repo 可能导致这种情况是什么？

2) 为什么在序列 2 中添加任意文件会导致 pull --rebase 冲突？当没有变化时，它像序列 1 一样工作正常。

3) 基本上，我不明白为什么序列 2 会引起冲突，因为 1,3,4 都可以正常工作。

.git/config 有:

[分支“媒体”]
远程 = 原点
merge =引用/头/媒体

以下是我正在运行的命令序列和结果:

序列1(复位和 pull )

$ git reset --hard 68a170d
HEAD 现在位于 68a170d 修复了嵌套属性站点的问题

$ git 状态
# 在分支媒体上
# 你的分支在 'origin/media' 后面有 7 次提交，并且可以快进。
#
无需提交(工作目录干净)

$ git pull --rebase
首先，倒带头部以在其上重放您的工作......
快进媒体到 4c7d9cf046368d4c7770d3b590bf3c1d1f14d480。

序列2(重置添加文件 pull )

$ git reset --hard 68a170d
HEAD 现在位于 68a170d 修复了嵌套属性站点的问题

$ touch someblahrandomfile
$ git add someblahrandomfile
$ git commit -m '等等'
[媒体 9bf2bfb] 等等
0 个文件更改，0 个插入(+)，0 个删除(-)
创建模式 100644 someblahrandomfile

$ git 状态
# 在分支媒体上
# 你的分支和'origin/media'有分歧，
# 并且分别有 1 个和 7 个不同的提交。
#
无需提交(工作目录干净)

$ git pull --rebase
首先，倒带头部以在其上重放您的工作......
应用:固定验证方法
使用索引信息重建基树...
回到修补基础和 3 路 merge ......
自动 merge 应用程序/ Controller /jet_controller.rb
自动 merge 应用程序/模型/claim.rb
自动 merge app/models/site.rb
自动 merge app/models/user.rb
CONFLICT(内容):在 app/models/user.rb 中 merge 冲突
未能 merge 更改。
补丁在 0001 处失败 固定验证方法

解决此问题后，请运行“git rebase --continue”。
如果您希望跳过此补丁，请运行“git rebase --skip”。
要恢复原始分支并停止重新定位运行“git rebase --abort”。

序列 3(使用额外参数重置添加文件 pull )

$ git reset --hard 68a170d
HEAD 现在位于 68a170d 修复了嵌套属性站点的问题

$触摸zz
$ git add zz
$ git commit -m 'blah4'
[媒体 c79214d] blah4
0 个文件更改，0 个插入(+)，0 个删除(-)
创建模式 100644 zz

$ git 状态
# 在分支媒体上
# 你的分支和'origin/media'有分歧，
# 并且分别有 1 个和 7 个不同的提交。
#
无需提交(工作目录干净)

$ git pull --rebase -- 原始媒体
* 分支媒体 -> FETCH_HEAD
首先，倒带头部以在其上重放您的工作......
申请:blah4

序列 4(重置和 rebase )

$ git reset --hard 68a170d
HEAD 现在位于 68a170d 修复了嵌套属性站点的问题

$触摸vv
$ git add vv
$ git commit -m 'blah7'
[媒体 6c3f42b] blah7
0 个文件更改，0 个插入(+)，0 个删除(-)
创建模式 100644 vv

$ git 状态
# 在分支媒体上
# 你的分支和'origin/media'有分歧，
# 并且分别有 1 个和 7 个不同的提交。
#
无需提交(工作目录干净)

$ git rebase 来源/媒体
首先，倒带头部以在其上重放您的工作......
申请:blah7

附加信息

a) 错误的 repo 在 Mac osx 10.6.4 上
b) Git 1.7.1
C)

color.branch=自动
颜色.diff=自动
颜色.状态=自动
color.branch.current=黄色反向
color.branch.local=黄色
color.branch.remote=绿色
color.diff.meta=黄色粗体
color.diff.frag=洋红色粗体
color.diff.old=红色粗体
color.diff.new=绿色粗体
颜色.状态.添加=黄色
color.status.changed=绿色
color.status.untracked=青色
merge .工具=开放差异
mergetool.tool=opendiff
difftool.difftool=opendiff
gui.recentrepo=/git/MYREPO
用户名=用户
user.email=EMAIL
别名.wtf=git-wtf
alias.lg=log --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr)%Creset' --abbrev-commit --date =相对
core.repositoryformatversion=0
core.filemode=true
核心.裸=假
core.logallrefupdates=true
core.ignorecase=true
remote.origin.fetch=+refs/heads/*:refs/remotes/origin/*
remote.origin.url=URL
branch.master.remote=起源
branch.master.merge=refs/heads/master
branch.media.remote=来源
branch.media.merge=refs/heads/media

更新 2(第一组 >>> 应该指向另一个方向，但无法让它们正确显示)

$ git diff
diff --cc app/models/user.rb
索引 e1c31e2,f4923e6..0000000
--- a/app/models/user.rb
+++ b/app/models/user.rb

has_many :coupon_codes
accepts_nested_attributes_for :coupon_codes

>>>>>>> 头
========
has_many :sites, :dependent => :destroy
accepts_nested_attributes_for :sites, :allow_destroy => true

>>>>>>> 固定验证方法

Answer 1

你为什么要rebase？我认为在你上面的场景中没有必要使用它。 rebase 改写历史 .

场景一:

Your branch is behind 'origin/media' by 7 commits, and can be fast-forwarded.

所以快进吧! git merge origin/media或者干脆 git pull , --rebase是矫枉过正，你没有什么可应用的。

你在这里: A1
来源/媒体在这里: A1-A2-A3-A4-A5-A6-A7-A8 (等等)它是线性的，只是通过 merge 快进。

快进移动指针。重新设置 stash 更改(您没有，如果它说您可以 ff)，然后重新应用您的提交 作为新提交 ，改写历史。但是你没有，所以这只是跳过箍的浪费。

场景2:

再说一遍，你为什么要重新定位？ rebase 改写历史 有新的提交。如果不需要 重新订购历史那么不要 重新订购历史

场景 2 会给您带来问题，因为 git pull --rebase将使用默认远程( origin master )的默认分支重新设置当前分支。在配置中，您有 branch.media.merge设置，但不是 branch.media.rebase .因此， git pull (默认运行 merge )将从 origin media pull ，但是 git pull --rebase将从 origin master pull (默认)。这也解释了为什么场景 3 和 4 起作用:您明确地告诉它要从哪个分支/源 rebase 。

来自 man git-config :

branch.<name>.rebase

       When true, rebase the branch <name> on top of the fetched branch, instead of merging the default branch from the default remote when
       "git pull" is run.  NOTE: this is a possibly dangerous operation; do not use it unless you understand the implications (see git-
       rebase(1) for details).