Question

我是GIT的新手，无法理解第二个rebase命令如何导致合并问题：

$ git rebase origin/develop
Current branch feature/featurename is up to date.

$ git fetch
remote: Microsoft (R) Visual Studio (R) Team Services
remote: We noticed you're using an older version of Git. For the best experience, upgrade to a newer version.
remote: Found 50 objects to send. (31 ms)
Unpacking objects: 100% (50/50), done.
From https://.....
   df825005..000000cf  develop          -> origin/develop

$ git rebase origin/develop
First, rewinding head to replay your work on top of it...
Applying: .....
C:/work/.../rebase-apply/patch:61: trailing whitespace
Using index info to reconstruct a base tree...
M       br/br
Falling back to patching base and 3-way merge...
Auto-merging case/TTest.cpp
 CONFLICT (submodule): Merge conflict in br/br

我知道rebase和fetch都会引用origin / develop，但是我的VSTS（构建系统）中有一个'set-upstream'分支 - 所以从VSTS中的功能分支中获取了fetch吗？

Answer 1

Git刚刚在输出中告诉你发生了什么：

Current branch feature/featurename is up to date.

这意味着，此时，在获取之前，您的分支确实基于原点/开发。所以你的历史看起来像这样：

  feature/featurename
      /
-o---o
  \
  origin/development

现在，您调用了git fetch命令，该命令检查是否有新的提交被推送到远程存储库。事实证明，有{，git通知您消息的更改内容：

From https://.....
   df825005..000000cf  develop          -> origin/develop

这意味着远程存储库develop上的分支https://.....已从df825005移至000000cf（很好的哈希，顺便说一句），因此您的远程分支origin/develop相应更新。现在您的历史记录如下：

  feature/featurename
      /
-o---o
  \
    --o <- origin/development

分支feature/featurename不再基于origin/development的顶部，因此当您运行rebase时，您必须完成整个过程（分支不再是最新的，不能快进）

First, rewinding head to replay your work on top of it...

这是执行rebase的准备步骤 - HEAD放在origin/develop分支的顶部，因为它现在会尝试将您的提交放在那里。

Applying: .....

这是提交git现在应用于HEAD的名称。现在它是origin/develop的顶部，但是如果你有更多的提交需要重新定位，那么显然会向前推进。

Falling back to patching base and 3-way merge...

Git无法自动应用您的提交，因为在您的提交和origin/develop分支中都修改了文件。所以现在git将不得不......

Auto-merging case/TTest.cpp

聪明的git alghoritms可以避免此文件中的冲突，因此它会尝试自动注释

CONFLICT (submodule): Merge conflict in br/br

没有运气！不幸的是，git无法对文件进行自动缓存，并让您承担此责任。你要么有一些异国情调的git，要么你已经修剪了输出，但git通常会包含一个非常有用的行：

When you have resolved this problem, run "git rebase --continue".

所以现在你所要做的就是以通常的方式解决冲突，一旦完成，就做git rebase --continue。现在git将尝试应用下一个提交，如果还有剩下的那么。

我强烈建议您阅读有关git的选择教程 - 您似乎对git的基本概念非常困惑，这些概念与svn等版本控制系统非常不同

Answer 2

我知道rebase和fetch都会引用origin/develop ...

这不太对。

git fetch所做的是连接你的 Git（它拥有所有提交的独立副本 - 你自己的提交以及其他所有人的提交，因为你最后一次提交将你的Git连接到你连接到的所有其他Gits-与其他一些Git。

另一个Git可能有你不承诺的承诺。如果是这样，你的Git会向他们的Git询问他们所拥有的提交，而不是你没有。他们交出了他们的承诺 - 他们拥有你没有做过的事情。你的Git会在你的存储库中永久地将这些提交存储在它们的哈希ID下;然后你的Git记录，供你使用，哪些提交是他们的提示提交。也就是说，他们有一个名为develop的分支。你刚刚从他们那里得到了一个列出他们develop名称的哈希的列表。但是你可能有你自己的分支，名为develop，所以你的Git根本不会触及你的 develop。相反，它只会更新您的他们的 develop的内存，Git会将其调用origin/develop。

当您运行git rebase origin/develop时，您的Git 不会调用另一个Git ，它只会在您自己的origin/develop中查看已保存的内存。因此，您的第一个git rebase没有做任何事情，因为您存储在develop中的origin/develop的记忆不需要做任何事情。然后你运行了git fetch，它从Git获得了新的提交，并通过更新你的develop更新了他们origin/develop的记忆。然后你的第二个git rebase查看了你的更新内存，发现有事可做，做了，这个过程导致了你看到的合并冲突。

GIT fecth和rebase

2 个答案: