命令git clone --depth选项说
--depth <depth>
Create a shallow clone with a history truncated to the specified number of revisions.
A shallow repository has a number of limitations
(you cannot clone or fetch from it, nor push from nor into it),
but is adequate if you are only interested in the recent history of a large project with a long history,
and would want to send in fixes as patches.
为什么浅克隆有这个限制？为什么它只是一个补丁工作流程？
对于某些项目工作流程，我只需将来自单个分支的最新提交传递给编码器，然后让他们能够将push其（快进）开发到主服务器。这部分是为了安全、IP 保护和 repo 大小，部分是为了减少大型 repo 给幼稚的编码人员带来的混乱。是否有允许这样做的 git 工作流程？
更新：根据 Karl Bielefeldt 的回答，git checkout --orphan应该是正确的答案。但是仍然需要将该分支单独“克隆”给新用户，并能够有效地推送它。
手册页指出：
git checkout [-q] [-f] [-m] [[-b|-B|--orphan] <new_branch>] [<start_point>] --orphan创建一个新的孤立分支，命名为
<new_branch>，开始于<start_point>并切换到它。在这个新分支上进行的第一次提交将没有父母，它将成为与所有其他分支和提交完全断开的新历史的根。索引和工作树的调整就像您之前运行过一样
git checkout <start_point>。这允许您开始一个新的历史记录，该历史记录记录一组类似于<start_point>通过轻松运行git commit -a以进行根提交的路径。当您想从提交中发布树而不暴露其完整历史时，这可能很有用。您可能希望这样做以发布一个项目的开源分支，该项目的当前树是“干净的”，但其完整历史记录包含专有或其他受阻的代码位。
如果要开始记录一组与 中的路径完全不同的路径的断开连接的历史记录
<start_point>，则应在创建孤立分支后立即通过git rm -rf .从工作树的顶层运行来清除索引和工作树。之后，您将准备好准备新文件、重新填充工作树、从其他地方复制它们、提取 tarball 等。
VonC 与 Junio 评论的链接很有趣。我认为手册应该在这种情况下提供指导，并允许正确的命令 [eg clone <branch> --options] 仅提取 repo 的相关部分。显然，push通过在历史底部有一些链接的提交和 SHA1 来增加成功的概率，这将锁定 repo 匹配。
更新 Git 1.9.0：发布说明 2014 年 2 月 14 日。
“过去禁止从浅克隆存储库中获取数据，主要是因为所涉及的代码路径没有经过仔细审查，我们也没有费心支持这种用法。此版本试图以更可控的方式允许对象从浅克隆存储库中传输出去（即接收器变成了一个具有截断历史的浅层存储库）。”
这对浅层克隆者来说是个好消息。下一步 - 可能是狭义克隆。