为什么在某些情况下，"git checkout origin/branch"会导致"分离于"<SHA>而不是"在源站/主站分离"？

Question

我正在做一个足够大的repo，有多个子模块。为了确保我们在CI过程中处于正确的状态，我们初始化子模块

$ git submodule init
$ git submodule sync
$ git submodule update --force

输出类似于

的内容

Synchronizing submodule url for 'android/public'
Synchronizing submodule url for 'ios/public'
...
Submodule path 'android/public': checked out 'asdf1234'
Submodule path 'ios/public': checked out 'bsdf2345'

如果我们检查并检查几个不同的分支，如果我们然后运行

$ for platform in android ios
$ do
$   (cd $platform/public; git fetch --all; git checkout origin/master)
$ done

和git branch检查文件夹，它们都是(HEAD detached at origin/master)。

然而，如果我们在顶部重做子模块初始化，并运行

$ for platform in android ios
$ do
$   (cd $platform/public; git fetch --all; git reset --hard origin/master; git checkout origin/master)
$ done

再用git branch检查一下，它们显示为(HEAD detached at <some SHA>)。

这是我们的CI中的一种遗留过程，所以它可以改变，但我仍然想知道为什么运行git checkout origin/master不会总是导致git branch显示在origin/master分离的HEAD。

Answer 1

"detached at"字符串只是试图提供信息。旧版本的Git只使用作为哈希ID，你只会看到"detached at "。

新版本的Git试图记住git checkout命令中执行分离的项目，如果可以的话，会说"detached at something_more_informative"。在这里你有时会看到detached at origin/master。在各种情况下，它们会丢失详细信息，包括如果你移动了当前的提交(通过将新的提交id写入HEAD，例如，再次被git checkout使用或进行新的提交)。在这种情况下，一些新版本的Git会开始说"detached from"而不是"detached at"，并保留一些额外的信息，无论是散列ID还是名称。虽然所有较新的Git版本都试图做到这一点，但有些版本有一些小错误，并且无法正确区分"detached from"one_answers"detached at"。

在这个特殊的情况下 -尽管它是git版本依赖的-你的最后一个例子进程导致"在哈希分离"的原因是你的git reset --hard origin/master通过ID移动到给定的提交，破坏旧的保留信息，然后你的git checkout origin/master看到这不是一个移动，也就是说，你已经在那个ID，所以它不更新保留的哈希或名称。

如果是这种情况，只需将git reset --hard origin/master替换为git reset --hard，以便后续的git checkout (通常)移动，将保留的信息更改回名称