请指定gerrit使用的refname是什么，克隆后将丢失。并会简单地
git clone --origin <gerrit-suitable-origin-name>解决问题吗？
现在是长版。您的问题可能是两个问题加在一起。为什么对和有好处
git init，为什么在初次克隆存储库时没有办法方便地过滤refspec？
gitremote add``git fetch
refspecs- 克隆初始化存储库后，该命令的remote-refspec行为是在.gitconfig中添加概述提取指令的默认部分：
[remote "origin"]url = ssh://host/your.gitfetch = +refs/heads/*:refs/remotes/origin/*
这些是很好的默认设置，提供的refspec用于从远程获取所有内容。如果您需要更改refspec，则只需编辑文件即可手动进行。例如，
[remote "origin"]url = ssh://host/your.gitfetch = +refs/heads/atari:refs/remotes/origin/atarifetch = +refs/heads/vertigo:refs/remotes/origin/vertigo
编辑后，获取将仅涉及来自原始远程服务器的
atari和
vertigo分支
master，例如，通常存在的远程分支以及可能存在于远程数据库上的所有其他分支将被忽略。当然，这类似于
gitfetch在命令行上提供refspec的选项。
总体而言，这不是必须的，我认为这不是一个干净的设计，因为它能够在
gitclone命令行上预先支持多个初始refspecs，其唯一目的是将它们放在.gitconfig中。您甚至可以通过运行
gitclone然后
sed在.gitconfig文件上编写几乎相同的脚本。在给定许多可能的refspec的情况下，在克隆时决定要结帐的初始分支也是有问题的。
init over clone- 假设我们避免讨论更高级的
gitclone设置，例如，利用
--reference，浅深度
--depth或创建裸仓库，init-add-
fetch和clone之间的区别对于您的日常工作来说是很小的。
纯克隆仅复制现有的存储库，并将“源”设置为创建源的远程目录。这带来了一些小麻烦-
强制您使用“原始”远程，创建远程跟踪分支，设置初始分支以及检出HEAD。但是，如果您从开始做起，
gitinit那么您的掌控力会稍微提高一些。您可以开始手动添加遥控器并获取特定分支，而无需检出任何内容。
请注意，尽管
git clone行为的许多方面都可以通过命令行开关来控制-也许
gitinit只是偏爱它们的开发人员还不知道它们吗？问题中没有足够的信息来决定。与其他方法相比，
gitclone可以节省一些键入时间，避免出现宇宙热死并设置合理的上游默认值，例如拥有一个跟踪分支。我投票支持克隆。
