Question

git checkout -t origin / 5.0

* df957e8 (HEAD, origin/5.0, 5.0) commit A
* 93f3185 commit B
* abd1176 commit C

我使用以下命令检查了gerrit的更改

git fetch gerrit refs / changes / 36/236/1＆amp;＆amp; git checkout FETCH_HEAD

现在它将分离HEAD状态，其中传入提交位于master分支之上而不是5.0

    * bdd7f9c (HEAD) part 3 of 236
    * fa8f60f part 2 of 236
    * bddd168 part 1 of 236
    * ffc7982 (origin/master, origin/HEAD) commit master
    * 415668e 
    * 991d48d

我希望它像

* bdd7f9c (HEAD) part 3 of 236
* fa8f60f part 2 of 236
* bddd168 part 1 of 236
* df957e8 (HEAD, origin/5.0, 5.0) commit A
* 93f3185 commit B
* abd1176 commit C

我尝试使用symbolic-ref更改指向refs / heads / 5.0的HEAD，但在检出FETCH_HEAD后立即显示在master分支上而不是5.0。

我的目标是使用命令

获取来自gerrit change checkout的提交列表

“git log --format =”％H“origin / 5.0..HEAD”

但它在这种情况下不起作用，因为它是在master上检查而不是5.0

如果我遗失任何内容，请告诉我

Answer 1

这里有几件事情要发生。首先，在您想要的结果中，您不能有两个HEAD。总是只有一个HEAD。

当您的当前头部提交未被任何分支名称或标记引用时，您将获得一个分离的头状态。

现在，关于为什么提交被置于master而不是5.0之上。每个提交都引用父提交。即每个提交都有一个由其哈希引用的父代。当您获取更改时，获取的提交也会随其父引用一起提供，并相应地放置。例如，假设以下是远程仓库的状态：

A -> B -> C（C是最新的提交）

您在当地有以下历史记录：

A -> B

现在无论你提取或取出什么分支，当提取C时，它都会在那里寻找提交B set camp。

意思是，在哪里调用fetch并不重要。特定提交将驻留在首先制作它的同一父级上。

如果您仍需要移动这3个提交，我建议您查看rebase。虽然公开承诺的公开肯定会咬你，除非你是回购的唯一贡献者。

git：远程分支和HEAD之间的git日志处于分离的HEAD状态

1 个答案: