4

昨天我们用 git 遇到了一个非常奇怪的情况：

  1. 我们像往常一样创建了一个功能分支。然后，有人会在该功能分支上工作几天。

  2. 与此同时，主分支上发生了一些重要的事情。功能分支也需要这些更改。

  3. 因此，我们将主分支合并到功能分支中（没有变基，因为我们的功能分支通常会立即推送到远程，因为我们需要在一个功能上进行协作）。此合并仅在本地完成，尚未推送到远程。

  4. 功能分支上的工作继续

  5. 随着 master 的合并 + 继续工作，本地功能分支 new_feature 现在比 origin/new_feature 领先 40 个提交

  6. 现在我们想将这 40 个提交推送到远程功能分支。首先，我们像往常一样在推送之前执行 git pull --rebase ，因为其他人可能在我们之前推送了一些提交。

  7. 现在我们经历了无数的冲突。我们认为不值得修复 40 次提交并执行 git rebase --abort。然后我们尝试 git pull --no-rebase。我们得到：“已经是最新的” - 奇怪

  8. 由于 git status 没有告诉我们本地分支和远程分支有分歧，我们试试 git push

  9. 出乎意料的是， git push 奏效了。如果我们尝试推送到自上次拉取后已更改的远程分支，我们将被拒绝。所以很明显 remote 没有改变，但是 git pull --rebase 做了一些奇怪的事情。

所以这件事的奇怪之处在于

  1. git pull --rebase 没有立即返回“已经是最新的”并且

  2. git pull --rebase 报告了大量冲突，实际上没有一个应该退出（报告的冲突与功能分支上的工作无关）

什么可能导致这种情况？

4

2 回答 2

2

我怀疑即使您启用了 rerere 或者您会解决所有 40 个冲突，您也会得到预期的结果。问题是：你做了一个变基，但你想提交一个合并！通过调用“git pull --rebase”，git 将执行“git rebase origin/featureXY”（假设您的功能分支称为 featureXY）。此外，如果原点没有更改，您可以在当前分支上执行变基到原点分支的状态。当您在合并提交上执行变基时，git 会一如既往地执行。它解决了每个合并并创建了一个平坦的历史记录。这意味着，先前合并到分支中的 master 的每个提交都将应用于您的分支。结果将是没有任何合并提交的直接历史记录。

结论：避免混合变基和合并！在您的工作流程中，直接推送合并是不可避免的，否则您将无法继续使用 pull-rebase。

于 2014-10-02T21:35:28.867 回答
1

不幸的是，a rebaseafter agit merge会导致这种情况，除非您之前启用了 git rerere。在之前的 git merge 之后查看git rebase

于 2013-11-09T23:34:28.743 回答