查看this示例显示refspecs可以过滤目录/命名空间，如下所示：
+refs/heads/qa/*:refs/remotes/origin/qa/*
但是我正在尝试优化获取和我正在使用的repo具有如下命名的分支：
release-6.0.0
当我试图过滤这些时，我得到：
fatal: Invalid refspec '+refs/heads/release*:refs/remotes/upstream/release*'
有没有办法在获取中过滤这些或者我是否需要获取所有远程头？
答案 0 :(得分：7)
Git 2.6+（2015年第3季度）将允许这种refspec！
commit cd377f4见commit 53a8555，Jacob Keller (jacob-keller)（2015年7月22日）
（由Junio C Hamano -- gitster --合并于commit 8d3981c，2015年8月3日）
的限制
refs：放宽对通配符“*”refspecs通过允许组件中具有“
*”的模式而不是仅作为整个组件，来放宽对refspecs的限制。从
*中删除逻辑以接受单个“check_refname_format()”作为整个组件，并在check_refname_component（）中实现该逻辑的扩展形式。
将指针传递给后者的flags参数，因为它必须在看到“REFNAME_REFSPEC_PATTERN”时清除*位。教导
check_refname_component()函数只有在标志中设置*时才允许使用星号“REFNAME_REFSPEC_PATTERN”，并在看到“*”后删除该位，以确保一侧refspec的最多包含一个星号。这样我们就可以接受
for/bar*:foo/baz*等refspec 以前运行的任何refspec都将继续使用新逻辑。
原始答案（2013）
似乎不可能，因为该限制有助于remote.c完成参考匹配。
这可以追溯到Git 1。5。6。5（2008年8月）和commit b2a5627（Daniel Barkalow），它强制执行“通配符refspec必须以斜线和星号结尾”的规则：
通配符refspec在内部被解析为带有
src和dst字符串的refspec结构。
代码的许多部分假设在将通配符模式与我们在远程处看到的实际引用匹配时，这些部分不包括尾随的“/*”。 这意味着我们不仅要确保前缀匹配，还要确保匹配的部分后面有斜杠。但是从
ls-remote扫描结果并找到匹配引用的代码路径忘记检查“匹配部分必须后跟斜杠”规则。
这导致远程端的“refs / heads / b1”错误地匹配“refs/heads/b/*:refs/remotes/b/*”refspec的源端。更糟糕的是，由“
git-clone”内部精心制作的refspec，以及用于实现“git-fetch --tags”的硬编码的预分析refspec，违反了这个“已解析的widcard refspec并不以斜线结束”规则;只需添加“匹配部分必须后跟斜杠”规则，然后就会破坏使用这些refspecs的代码路径。此提交将规则更改为需要使用尾部斜杠来解析通配符refspec IOW，“
refs/heads/b/*:refs/remotes/b/*”被解析为src = "refs/heads/b/"和dst = "refs/remotes/b/"这允许我们简化匹配逻辑，因为我们只需要执行prefixcmp()请注意“refs/heads/b/one”匹配，而“refs/heads/b1”则不会。
OP Monte Goulding指出commit 46220ca（diff）是此规则的起源（Git 1。5。5，2007年4月）
根据我的建议，我们在之前的commit ef00d15（收紧refspec处理，2008-03-17）收紧了refspec验证码，但这个建议被误导了，并且它打破了这种用法：
$ git push origin HEAD~12:master
push refspecs和fetch refspecs的语法类似，因为它们都是冒号分隔的LHS和RHS（可能以
+为前缀加强），但相似性在那里结束。
例如，push refspec中的LHS可以是在运行时评估为有效对象名称的任何内容（除非冒号和RHS丢失，或者它是一个glob），而它必须是 fetch refspec中有效的refname。
为了正确验证它们，调用者需要能够说出它们是哪种refspec 保持一个单一的界面无法分辨出它正在处理哪种界面并要求它表现得合理是不合理的。这个提交将两者的解析分成不同的函数，并澄清代码以实现正确的解析（即分成两部分，确保双方都是通配符或双方都不是）。