因此，在manifest.xml中，您可以为项目指定修订，例如项目foo的修订版本。那你
repo sync
并下载项目foo的主分支。但它实际上并没有检查出那个分支。相反，它让你陷入无头状态，不知何故从主人开始...？如果我打算在同步项目上实际工作，这似乎相当麻烦。
我知道它可以很容易“修复”但是因为它看起来很反直觉我猜他们有一个很好的理由让你默认让你处于无头状态。在我偏离它之前，我想了解预期的工作流程，有人能解释一下吗？
答案 0 :(得分：1)
“无头状态”在Git中称为detached HEAD。
在清单中（例如，.repo/manifest.xml），我们可以看到每个项目都有revision。它可以是提交（40a264de45eb035c67aa32d73c767ed7d9378ba2），标记（refs/tags/v1.0），分支（refs/heads/master或master）或任何有效的git ref（refs/changes/11/22211/1） 。
repo sync克隆只需回复$coderoot/.repo/projects/和$coderoot/.repo/project-objects，在裸仓中调用git rev-parse即可获得revision的提交，然后{{1这个提交在git checkout下的repos中，它总是导致分离的HEAD。请参阅project.py。
请注意，这两个命令在两个repos中调用。假设$coderoot/中有一个分支master，$coderoot/.repo/project/foo.git中还有一个分支master。两个$coderoot/foo/可能指向不同的提交，并记住允许在现有目录中运行masters。 repo sync中的git checkout master将提取错误的代码。分支名称不可信，提交是。这就是$coderoot/foo/总是检查提交而不是分支的原因。
答案 1 :(得分：0)
下载全部回购软件的能力很棒。但是，我发现当前的行为非常有限。想象一下一个包含大量相关存储库的回购林，每个存储库都有其分支名称版本：master-1，master-2等
现在，运行回购同步后，您将拥有所有HEAD分离案例中的回购。是否有一个选项可以检出清单文件中指定的分支，即检查同名的现有分支是否正在跟踪远程分支，或者只是由i.e创建的本地分支不在跟踪远程分支。
例如1：repo-1主分支是master-1，具有跟踪分支master-1 例如2：repo-2主分支是master-2，本地分支master-2，它不跟踪远程分支
在上面的示例中，当repo-2处于HEAD分离状态时，脚本将在master-1分支中显示repo-1。