当上游已经可以到达时，为什么 git-rebase 会遇到冲突？答案

【问题标题】：Why does git-rebase encounter conflicts when upstream is already reachable?当上游已经可以到达时，为什么 git-rebase 会遇到冲突？
【发布时间】：2011-09-16 18:15:52
【问题描述】：

我有一个 git 分支“dev”。可以从 dev 访问分支“master”。在分支“dev”上，如果我输入“git log master..dev --pretty=oneline”，它清楚地表明 master 是可访问的（早前 104 次提交）。但是如果我输入“git rebase master”，它会因冲突而停止。这是为什么？在这种情况下rebase不应该无关吗，因为dev已经基于master？

我问这个的原因是因为我真的很想用 squashes 和 rewords 做一个交互式 rebase 来清理一个漫长的历史。但是，一旦我开始变基，我就不得不解决所有应该已经解决的冲突。

以下是我已经看过的一些相关问题：

Why does git-rebase give me merge conflicts when all I'm doing is squashing commits? Conflicts with `git rebase`

【问题讨论】：

我想我现在看到了问题所在。在分支开发的历史中。有很多合并。师父只是其中之一。所以当然，当我想与上游的 master 进行 rebase 时，会有冲突。我将再次与 master 合并 w/ --strategy "ours" （我是唯一的程序员 - 所以没有其他人会受到我所做的任何事情的影响）。

标签： git-rebase

【解决方案1】：

git rebase master 将您的分支重新设置为基于master 中的最新提交。如果你想更早地建立它，你需要指定确切的提交，即

git rebase `git merge-base master HEAD`

【讨论】：

【解决方案2】：

rebase != 合并

如果你只想快进，使用

git pull --ff-only ...
git merge --ff-only ...

如果您想根据当前上下文和分支的关系“自动变基/快进”，我想这会起作用：

git pull --rebase ...

您可能想准确地阅读手册页，了解它的作用

【讨论】：

谢谢，但我不想从存储库中合并。我只想清理我的 dev 分支的历史记录。